RE: [ebxml-msg] follow-up on message bundling

["Pim van der Eijk" <pvde@sonnenglanz.net>]

To add to the discussion, see some comments inline.

 

---

From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
Sent: 08 April 2009 04:18
To: ebxml-msg@lists.oasis-open.org
Subject: [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?

 

If we support multiple UserMessages, we should probably support response bundles having multiple errors and receipt signal units also.

A response bundle is also useful in cases where a receiving MSH pulls on some MPC that stores an accumulation of messages, submitted to that MPC during the preceding minutes or hours, or receives a lot of messages from a store-and-forward intermediary after some failed network connection is restored. A single response bundle could cover the large set of processed messages.

See below for Pull.

  

 

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?

 

If there are multiple UserMessages in a bundle, with different @mpc values, how would you pull the bundle?  Using the mpc of the first UserMessage, or using any of the MPCs?  Does the client have to be authorized for the first/any/all MPCs?  It may be simpler to require all messages to share the MPC.

 

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)?

 

Yes, the ability to support bundling should probably be an agreement (Pmode) feature, with default settings corresponding to the Core spec and other settings for the more advanced types of bundles we are talking about now.  Once a message is packaged and submitted, the endpoints and any intermediaries should not have to treat bundles differently from regular ebMS messages. It would be very inefficient if the sender should have to (re/un)bundle messages dynamically based on content of the PullRequest. This is one issue with multiple bundled PullRequests.

 

 -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