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?

 

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?

 

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

 

-jacques

 

From: Jacques R. Durand 
[mailto:] 
Sent: Wednesday, March 11, 2009 4:29 
PM
To: 
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