RE: ebXML - Transport etc

["Rik Drummond" <drummond@onramp.net>]

Thanks for the comments and the detailed reading of the document. Because of the obvious complexity of the issues we are releasing it as a "strawman" to make sure we get these type of comments from a wider audience. So you are just the first of many. I think we are much closer to what your very exacting comments and concerns indicate than what you might believe. i will make comments in the text below.

 

we have already voted this out for review by the larger ebxml community... this phase will propagate a lot of comments.... yours are just the the first of many..

 

thanks for the effort and time, i really appreciate it.... rik

-----Original Message-----
From: Keith L. Musser [mailto:kmusser@idisys.com]
Sent: Tuesday, May 23, 2000 7:31 PM
To: drummond@onramp.net
Subject: ebXML - Transport etc

Hi Rik,

 

I have read the draft "Overview and Requirements" doument for "ebXML Transport Routing and Packaging", and wanted to pass back a few comments.  I don't see a newsgroup or discussion forum, so I will simply give my comments to you.  If you will go to ebxml.com and look under the team transport and routing you will find how to sign up for the workgroup's e-list....  we will release this for the wider group and take comments over the next three months along the line you have indicated

 

I believe you are still in the open comments phase for this document.  If not, please forgive me if my comments are badly timed. 

 

These comments refer to "ebXML TR&P Overview & Requirements (v 0-91).doc"

 

General

(1) In general, I think the set of requirements is too complicated.  It will take a long time to create a standard which addresses all the issues and combinations of options which you list.  Simplify - focus on what's required for interoperability.

(2) Suppose we are talking about Party A interacting with Party B.

As it stands, this document sounds like a requirement spec that the person writing software for Party A might use to design their messaging system.   However, in my opinion the framework should instead be about functionality that Party A has to guarantee for Party B to be able to work.

That is, what does Party B need to know about Party A?   Don't include anything about Party A that is not important to Party B.

Missing some "fundamental" requirements

A very fundamental requirement, it seems to me, is what is the scaliability of the ebXML framework.  that is assumed and we continue to worry about in in the meeting. 

For example, what is the minimal configuration a compliant customer must have?  For widest applicability, you want this framework to scale down so small clients can participate.  http and a very depreciated ebxml transport package. 

I think it should be possible for a small business to interoperate with big businesses using an e-mail client.  That is, the small business could work without having servers on-site.  They may have a dial-up ISDN connection to an ISP  (i.e. not a fixed IP address, so they cannot implement a web-server on their own computer systems.)  At a minimum, however, they should be able to send and receive e-mail messages within the ebXML framework.

This would mean they may not have a message queuing system installed (e.g. MSMQ, etc).  this does not require mqseries or anything for the conveyance mechanism. it could run over soap or http. 

And the framework should scale up to systems supporting millions of transactions per hour, as is possible using today's application server technology.  we are prototyping the transport stuff as we go to handle this issue.  

You can decide what the minimum configuration is -- but I think it should be in the requirements document.  maybe don't know yet. you obviously need to be involved in the workgroup. 

Requirements too broad

In some places your requirements document appears very wide open.  You seem to want to be able to use every method that currently exists.  Example:  Section 4.1 - "transported over many protocols: HTTP, SMTP, CORBA, JMQ, MQSeries, MSMQ, etc."  the design is independent of the underlying conveyance mechanism. so http and smtp are the current defaults even though that is not clear in the document. 

 

I would prefer to see one or two methods.  Perhaps require HTTP and SMTP mappings, and don't do anything known to prevent working with a message queuing system.  But no need to require mappings to all these systems.

 

The World Wide Web is so successful because there is one protocol:  HTTP.

 

In my opinion, you achieve the best interoperability by focusing on a simple method which works for 90% of the people, with built-in extensibility to work for the remaining 10%.  are thoughts are to let the market decide on the prevalent implementations. 

Don't assume a Messaging Queuing system

It appears that a message queuing system is assumed in your architecture.  (references to MSMQ, MQSeries, JMQ)  our architecture should support your concerns in this section. 

I think this is too restrictive.  People want to publish their e-services using a web server.  Whatever you come up with must have a web-server incarnation, and probably also an e-mail incarnation.

Build on top of SOAP

It seems to me the W3C's SOAP protocol does much of what you have in mind, in terms of giving a mechanism for transporting XML documents, in a contextualized way.  Plus they appear to be considerably further along in their standardization efforts.  our discussions show they are at least three to six months behind us in the standards arena... so we are in dialogue with them 

Would be reasonable to consider using SOAP as your foundation?  it may be,  but we intend to make it conveyance independent..  

You could work with them to address security requirements - which they need to do anyway.  You can examine their structure to ensure that all your requirements are met in both the HTTP and SMTP incarnations of SOAP.  that is being done in the next phase several of us on the team have worked for years with s/mime, pgp and pki issues and believe they will fall out of our current architecture direction. 

Messaging policy repository unnecessary

You don't define the "messaging policy respository", so for this comment I am guessing at what it is.

I don't see that the "Messaging Policy Repository" is necessary for interoperability.  That is, if I am Party B, why do I care whether there is a "Messaging Policy Repository" at Party A?  From my perspective, Party A can hard code their messaging policy if they like.  for trade to happen between smes one should not assume a policy needs to be in place... however for large enterprises they must be to ensure business takes place properly we will support the sme and the le using the proper mix of policy repositories. 

Message Routing

(Section 4.3) Don't require "Publish and Subscribe".  The "Publish and Subscribe" framework should not be excluded, but neither should it be prescribed as part of the ebXML framework.  rik - we need to implement a push functionality and a pull functionality... that is why p/s is in here. 

Audit Trail

(Section 4.5) The Audit Trail feature is something most implementations will want to include, but is should not be prescribed in the ebXML framework.  It is the job of each of the parties to keep track of the transactions they use, not the job of the B2B framework.  often trusted third parties are involved in audit trails...... that is why this is part of the requirements. 

If I'm creating Party B's audit trail, I don't want to be dependent on Party A's Audit Trail for me to know that mine will work.

 

Therefore, "Audit Trail" should be left up to the vendors who implement an ebXML compliant system; it should not be part of the ebXML specification.

Service Discovery

(Section 4.6) The service discovery requirement does not sound to me like it belongs in "Transport, Routing, and Packaging".  That sounds more like an application-level capability.  The service discovery is things like what transport is preferable, what version of ebxml is supported, what choreographies are supported, what level of QoS is assumed.... so at this level it is a transport and routing issues... you are correct though there are other levels which are not transport issues and belong to the application level. 

Restart and Recovery

(Section 4.8)  This is worded like it is the requirement specification for a particular software product.  However, it is my understanding that ebXML is an interaction framework, not a product.

The wording should be from the "requestor's" perspective, not from the "service provider's" perspective.  For example, what should I do if I make a request and don't hear a response or appropriate acknowledgement?

If I do hear back, what is the guarantee?  That is, if my request is acknowledged, then the service provider should guarantee that they received the message and will process it properly.  (If their server crashed in the meantime, that's their problem.)

I hope my comments are helpful; I would be happy to discuss them further if they are of interest.  nice job... we need you on our team.... rik 817 239 1320 

 

- Keith M.

 

Keith L. Musser
Integrated Dynamics, Inc.
812-371-7777
email:  kmusser@idisys.com