RE: [ebxml-msg] ebms multicasting

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

 

A Pmode also includes the PMode[].Protocol.Address parameter that covers the HTTP address that a message is sent to (for push exchanges),  and a receiver specific PMode[].Security.X509.Encryption.Certificate parameter that is used to encrypt the message.  In a multicast, these must be among the various receiver specific parameters that are set for each message separately, it is just not the PMode.Responder.Party.  How would MessageId, RefToMessageId (or is this AS4 and limited to One Way Exchanges) and ConversationId be set? 

 

A more general approach than allowing a list of Party Ids might be to redefine the "Submit" operation as possibly taking (in addition to payloads, variable data like conversation ID or properties) a list of PModes as a parameter, instead of just a single PMode. This would instructs an MSH to send the message multiple times, once for each PMode.  It is not much different from having a "Submit" for a single PMode in a "foreach" loop over the multicast destination list, but if the interface to the MSH has a certain overhead or needs to be transactional (as in transactional message queuing), a sending application can at least send a message to multiple destinations using a single transaction.  The MSH then has to send the individual messages separately, but at least the application interface is simplified. 

 

Yet another idea would be to consider a concept of "virtual" PModes.  A virtual PMode only has an identifier and no parameter values. An application can Submit a message to a virtual PMode based on its identifier. A virtual PMode is mapped to one or multiple other PModes.   The MSH internally handles a Submit to a virtual PMode as a Submit to the PModes it is mapped to. This is like the "group" concept in an email clients, or like queue propagation in message queuing products.  In this case the application interface is not changed, just as the mapping of group names to individual destination names in an email client, or the rule-based propagation from one queue to one or multiple other queues in a queuing product does not change. 

 

Submit and Deliver are abstract operations in the ebMS 3.0 spec, implementations have their own APIs which we do not standardize, so we can only describe this mechanism in a general way ..

 

 

---

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand
Sent: 20 November 2011 21:50
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] ebms multicasting

A “multicasting” requirement has come up from time to time, and lately at the OAGI meeting, contrasted with too restrictive “point-to-point” in some applications. At the ebMS F2F the next day we suspected that it may not take much to support multicasting feature in AS4.

Here is a short analysis of what multicasting could mean in a V3 context, while leveraging as much as possible Part 2 features:

 

-          Multicasting can be defined as nothing more than an enhanced “message submission process”, i.e. the Producer application submits a message once to the MSH, for a particular MPC. This MPC is associated with an (enhanced) Pmode that has been defined with a “multicasting” parameter, and is providing a list of “To” parties. From there, the MSH creates as many messages as the PMode requires, and sends them as usual.

-          It should not be confused with something that could be called “multi-delivery”, which is an [implementation]  feature beyond V3 scope where a receiving MSH delivers multiple times (to Consumer applications) a message received once.

-          So in a multihop context, multicasting is NOT about sending once a message that will be duplicated along the way by an intermediary while setting different “To” parties (that would go beyond the definition of intermediary, cause issues with security / reliability, etc.).

-          At the same time, item#10 in Pim’s list of AS4 issues seems to require something like sub-channels (generalized for a non-multi-hop environment). An enhanced sub-channel feature would also help multicasting.

 

One way to approach this feature addition, is to put it in V3 Part 2, and refer to it from AS4 as we did for multihop AS4 conf clause.  V3 Part 2 can go through a new PR + CS as  it is not in a hurry to move to OASIS standard due to need for implementations. AS4 could refer to the feature in one of its conformance clauses.

 

Possible upgrade plan for Part 2:

 

(a)    Extract the definition of sub-channels from the Multi-hop section, and make it a standalone new feature that is not just for intermediaries but can also apply to the case where messages are directly submitted to an [sending] MSH from which the receiving endpoint MSHs are pulling (i.e., single-hops – One-Way/Pull - sharing the same sender) . The benefit is, the Producer application only needs to use/know a single Pmode when submitting. (of course, the *usage* of subchannels remains described as today in the multihop context. Only its definition is moved out). That would help issue #10 reported by Pim.

(b)   Define the multicast feature independently from multihop, by adding a “multicast” parameter to a Pmode in the sending endpoint MSH and by associating a list of “To” parties to the Pmode. In other words, define multicasting as a particular “submission process” only affecting Pmode definition in our spec. Everything else remains as done currently once all messages are generated for a particular multicast group. So multicasting is always done over same MPC for a group.

(c)    Define how the multicast feature leverages sub-channels in case (a) above where a message is submitted to a Sending MSH, from which a set of Receiving MSHs are pulling.

(d)   In an AS4 context, as many Receipts will be received for messages in the multicast group, for a single message submitted. This seems the right behavior.

(e)   Add or modify a conformance clause in Part 2 that defines support for multicast, as well as sub-channels.

 

The Part 2 could be reorganized to move the existing (extended to endpoint) subchannel feature and the new multicast feature, under Section 5:

 

5 Variants in Message Exchange Patterns Execution

5.1 Selective message pulling

5.2 Alternate MEP bindings

5.3 Sub-channels

5.4 Multicasting

Note: in a multihop context – like in single-hop - , the multicasting must always take place in the initial sending MSH (i.e. just after submission from the Producer application), not later as messages should never be altered in the iCloud – yet multicasting means a different “To” party for each message.

SO far I do not see much trouble doing this upgrade. The design seems straightforward - mostly a Pmode upgrade, and editorial work…

-jacques