RE: ebXML Proof of Concept Proposal v0.5

["Patil, Sanjay" <Spatil@netfish.com>]

[Marc]   This does bring up a larger issue on maintaining the separation of the ebXML Message Envelope from the transport envelope.  For example, if we truly maintained the spearation of the ebXML MIME message envelope from the transport envelope, an HTTP transport ebXML message would look like the following:

 <snip>

 

[Patil, Sanjay]  This is an interesting point, Marc. I was myself thinking about this issue last

couple of days trying to find any convincing reasons for mixing the transport envelope and

the  ebXML message envelope. Does anyone on the mailing list know the rationale behind

this decision. If it's not too late, may be we should consider a change as the mix of the

headers from the two unrelated envelopes is going to cause issues ...

1>Difficulty in using MIME and HTTP APIs together. Service implementers will have tough

    time creating valid ebXML message. Typically

    APIs which make the HTTP request available to applications have separate set of APIs

    for accessing headers and the body. This will make it difficult to use MIME APIs which

    in their simplest form would like to suck in the whole MIME message including headers

    and body from a stream. Also, a valid MIME message needs to have the mandatory

    header "MIME-Version: 1.0". Service implementers will have to hand code insertion of this

    header while instantiating the MIME message.

2> Any future wrappers for ebXML message can not be accommodated. ex. Rosettanet has

     the concept of RosettaNet object in which the Rosettanet MIME message is nicely

    encased along with detached signature, etc. The RosettaNet object is then considered

    as the body of the HTTP message. With this next version of RosettaNet are free to modify

    the structure of the RN Object without breaking transport level processing in the services.

3> There might be cases of conflicting headers between transport and ebXML message

     headers. Or simply put, we are leaving ebXML message at the mercy of the HTTP engine

     which may modify or alter the sequence, etc of the ebXML message headers.

4> Transport independence, which will affect the processing flexibility at hubs.

 

 

May be it's still not too late.

 

thanks,

Sanjay Patil

Netfish Technologies.