[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] ebms multicasting
Pim: Inline <JD>. Thanks, Jacques From: Pim van der Eijk [mailto: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? <JD> You are right when we consider multicasting in a single hop context (I was more thinking in a multihop context, where the Address is the iCloud URI). So indeed, a “multicast PMode” . It seems that we may need to add a “multicastGroup” parameter to a PMOde, that will be an array of structures. Each one of these structures is called a “differentiator “ and will tell what is specific to each message of the group. A differentiator instance lists a set of existing PMode parameters that will override corresponding parameters in the hosting PMOde, and gives them a value specific to a message. All differentiators in a multicastGroup have same set of parameters – could include Address, Certificate, Party, etc.. So that should accommodate your cases. We could also restrict the use of multicasting to some MEPs / QoS. For MessageId and RefToMessageId, I do not see an issue: once the submission process is complete, each message is given a MessageId by the MSH as for anyother message. Everything works as usual. 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. <JD> that could be a list of differentiators, in addition to a ref to the base (or hosting) PMode. It is more convenient than a list of PModes, most of which will be empty? 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. <JD> Right – multicasting is nothing more than an enhanced submission mode – and a PMode grouping technique. 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. <JD> That is indeed an alternative. I have a slight preference for “differentiators” as it allows to define variations attached to a single existing PMOde (it is a “diff” mechanism), while with virtual, you would have to define and deploy a potentially large number of real PModes that actually will duplicate a lot of data (with potential mistakes). Also when doing the grouping “at submission time” – by passing the group PMode info, if you pass a virtual “set” of real PMode refs it is easy to make mistakes as you have to refer to PModes by their IDs, while if you pass a set of differentiators, you only deal with the diff values. Also, I can do grouping on the fly by providing differentiators at submission time, for an existing “base” PMode, but with virtual you still need to have all PMode copies in place in the a MSH before defining the group at submission time (e.g. by defining the virtual group when doing submission). There might be an advantage to virtual PMode when you have to define several groups that are slight variants of the same set of real PModes, though. 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 .. <JD> we can only define PMode support for it, and define the behavior of MSH for such pmodes. That is sufficient to declare support for multicasting I think. Thanks Jacques From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand 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.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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]