ebms multicasting

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:    [mailto:]  On Behalf Of  Jacques  Durand  Sent:  20 November 2011 21:50
To:

Subject:  [ebxml-msg] ebms  multicasting
A  “multicasting” requirement has come up from time to time, and lately  a  t  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