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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: [ebxml-msg] packaging comments



Only the renaming proposals (1-4) have to do with aligning with the notion of "message unit". The rest are unrelated comments.


Actually, "bundling" is as much about ability to piggyback signals onto user messages, as it is about batching many user messages.

With such piggybacking, we would have both an eb:UserMessage element and an eb:SignalMessage element under an eb:Message element, while we still want to say that this is a single ebMS Message (i.e. SOAP message with an ebMS header) , with two message units inside (e.g. a PullRequest with a user message unit, or an Error with any message unit - each of these units has its own ID and ref-to-ID).

The goal was more to avoid confusion between "message" and "message unit" from the start.


Batching needs more investigation - but on the requirement side: the SWA option (as opposed to several SOAP envelopes in a MIME multipart) has clear benefits: (1)  it is the MIME packaging that so far is already adopted by ebMS and is well supported as a standard, (2) is handled without much unpackaging legwork by SOAP processors, and still leads to the processing of a single SOAP envelope, meaning single reliability header as well as security header. So the idea is to leverage the SWA infrastructure, while reducing the SOAP processing overhead for the entire batch. A batching solution on top of SWA is still TBD, but would look like a single aggregated SOAP root part (precisely allowed by message units), referencing a combined set of MIME payload parts.  To achieve this, the batching needs to be "deep" inside the ebMS header, not done in lower protocol layers.





From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, November 15, 2005 2:09 PM
To: Jacques Durand; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] packaging comments


I would like to see the specific model of batching  that is probably behind all these proposed XML changes explained in much more detail before buying into all these XML changes.

For example, why not just approach batching by using MIME multiparts with each part its own SOAP envelope? Or multiparts of SOAP with attachments? Or use the transport to send multiples on a single connection? And so on...


There are probably a lot of ways to batch, and I would like to understand requirements and use cases before jumping into these changes.


1)       eb:UserMessage element to be renamed eb:UserMsgUnit. To avoid confusion with ebMS User Message, now that we have the notion of "message unit". (In a future release, bundling could allow several units within an ebMS Message.)



2)       eb:SignalMessage element to be renamed eb:SignalMsgUnit.




3)       eb:MessageId element is renamed to eb:UnitId. (only message units are really identified and referenced in  MEPs, not SOAP messages)




4)       eb:RefToMessageId element is renamed to eb:UnitRef.



5)       The attribute eb:Partref/@eb:id is removed (no different from an XML Id).


6)       The attribute eb:Partref/@eb:idref is renamed to eb:Partref/eb:cid. The absence of the attribute eb:cid in the element eb:Partref should indicate that the payload being referenced is nothing but the SOAP body element itself. For example, a declaration like the following would simply be referencing the contents of the SOAP body: <eb:PayloadInfo> <eb:Partref/> </eb:PayloadInfo>


7)       The element eb:property has two new optional attributes added to it: xsi:type and eb:cid. The attribute xsi:type indicates the XML type for the value of the property, while the attribute eb:cid indicates the content ID of a possible property attachment (when the value of a property is an attachment).


8)       It must be clearly stated in the spec that the value for the element eb:cid (whether in the attribute eb:property/@eb:cid, or in the attribute eb:PayloadInfo/eb:Partref/@eb:cid) should be the exact value of the "Content-ID" mime header element of an attachment. In other words, if the Content-ID mime header has a value like the following:


                    Content-ID: <someId@domain.com>


             then the value of the attribute eb:cid should be <someId@domain.com>,  not someId@domain.com or #someId@domain.com.



9)       Suggest that eb:Message element be renamed eb:Messaging. This reflects the name of the spec and avoid possible confusion with both ebMS Message (denotes the entire SOAP message containing this header) and with message unit.


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