[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] follow-up on message bundling
Follow-up on bundling:
Here is a short list of issues to be discussed before we start drafting anything on bundling:
1. Agree on the packaging of bundles:
- several UserMessages units in same eb:Messaging?
- what other SignalMessage unit(s) can go with it?
<SF>
If bundling of messages should be possible on the I-Cloud hops, i.e. on hop between intermediaries, wouldn’t it be easier if complete SOAP message could be bundled? That would prevent a lot of problems regarding question 2 below because in that case the messages themselves don’t have to have common attributes, the only requirement is that the outcome of the routing function is the same for all messages.
I don’t know if this is a viable use case and as it probably requires a new message structure / type I think we shouldn’t include it now. But maybe something to add later?
</SF>
2. What is expected to be common to all messages in the same bundle? Here is a list, by decreasing "obviousness":
- security and reliability.
- the destination. (However: in case of multihop: could a bundle be broken down by the last intermediary, and forwarded to multiple final destinations?)
- other QoS parameters? (how errors are supposed to be reported, Receipts...)
- the MEP? (could some message units belong to one-way and some to two-way? do we expect two-way responses to be bundled too? what if both parties do not have same bundling capability?)
- the MPC?
Should there be some "profiles" of bundles depending on what is common to their messages?
<SF>
I would think the most obvious property of bundled messages is the destination. Couldn’t it for example be possible that some user messages in the bundle are secured while others are not? I also think that security and reliability are applied with a destination in mind and therefore the destination comes first.
Isn’t this similar to the effective routing input topic in the multi hop context and can’t we use a similar approach here?
</SF>
3. Can we pull a bundle?
- should the PullRequests themselves be bundled to indicate intent and ability to get bundles? SHould PullRequest signal be extended? Or could a single, normal PullRequest get a bundled (PMode config)?
<SF>
Yes, it should be possible to pull bundles. But I doubt whether it’s useful to bundle PullRequests. What would the semantics be of such a bundle of PullRequests ? Dynamic bundling based on the MPC referred by the individual PullRequests ? That might raise security and reliability issues. So I wouldn’t favor bundling PullRequests.
</SF>
-jacques
From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, March 11, 2009 4:29 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] an outline of message bundling
Definition:
-------------
Message bundling / chuncking:
(a) ability to group several User Message units in a single ebMS envelope, representing
several logical message units to be delivered separately on reception.
(b) ability to split a large payload over several ebMS envelopes and SOAP messages,
and to deliver by Receiving MSH side as a single unit.
Reminder of bundling cases defined in Core Spec:
-----------------------------------------------------------------------
The following is a non-exhaustive list of valid bundling cases:
(a) eb:Messaging element with the following children:
an eb:UserMessage element
an eb:SignalMessage element with an eb:PullRequest child
(b) eb:Messaging element with the following children:
an eb:UserMessage element
an eb:SignalMessage element with one or more eb:Error children
(c) eb:Messaging element with the following children:
an eb:UserMessage element 1840 an eb:SignalMessage element with an eb:PullRequest child
an eb:SignalMessage element (distinct from the previous one) with one or more
eb:Error children
(d) eb:Messaging element with the following children:
an eb:SignalMessage element with an eb:PullRequest child
an eb:SignalMessage element (distinct from the previous one) with an eb:Receipt child
Bundling of ebMS Messages
-----------------------------------------
1- Rationale
- performance, simpler QoS processing
2- Packaging of bundles
- Bundling definition
(several UserMessages units - and SignalMessage units - in same eb:Messaging, NOT several eb:Messaging headers)
- processing model
(idea: semantic equivalent to a sequence of User Messages)
(sending side: before RM and Security, receiver side: unbundle after Security and RM)
- bundling of payloads
(SOAP Body, attachments)
3- Controlling bundling
- constraints or recommendation on what message units can be bundled together.
(e.g. same MPC? same security credentials? reliability level? MEP and channel binding?..)
- PMode parameters
(bundling based on qty, based on time)
- Bundling of Receipts.
- Bundling of Errors.
4- Transfer Considerations
- The case of pulled messages
(need to handle this: in a multihop config, a message can be pushed then pulled)
(such bundles must all be assigned to same MPC...)
- Routing bundled messages
(routing info: which UserMessage unit to use?)
Jacques
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]