[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] packaging comments
|
Dale: 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. Regards, Jacques From: Dale Moberg
[mailto:dmoberg@cyclonecommerce.com] 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]