To add to the discussion, see some comments inline.
From: Jacques R. Durand
[mailto:]
Sent: 08 April 2009
04:18
To:
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:]
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
