OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: ebXML Proof of Concept Proposal v0.5

[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:
[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.
Sanjay Patil
Netfish Technologies.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC