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

ebxml-msg message