[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Multihop and Pull
If we view MPC as the Pull equivalent of a URL for Push, then preserving its value could be just as (un)informative, and since the URLs are rewritten in every hop, the same may be true for MPCs. No strong opinions here, and there may be cases where the MPC names are informative.
Incidentally the @mpc attribute is a User Message attribute in the ebMS 3.0 XSD. Shouldn't it be an attribute on eb:Messaging? If we want to support bundling, an MSH can only pull a complete ebMS message, not selectively some UserMessage in that message. If MPC is used for priorities, then all user messages in a bundle must have the same priority.
Furthermore, when an unadressable MSH pushes a message which generates an error that (for some reason) is not delivered on the back channel, the MSH may want to pull that error from the next MSH. What MPC does it use to pull any such errors from?
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 17 May 2008 04:47
To: Sander Fieten; email@example.com
Subject: RE: [ebxml-msg] Multihop and Pull
Sander summarized well the subchannel proposal: I think it just makes the MPC change a bit cleaner (although more constrained), while enabling the use case Pim talks about.
The concern with an "unrestrained MPC re-assignment" is, if an intermediary can re-assign a message to an MPC that has no relationship at all with @mpc in the message, then there is no assurance anymore (no meaning) attached to this attribute, for a Sender.
That would mean the @mpc semantics will vary depending on the topology:
- for point-to-point transfer (no intermediary) the original @mpc is quite meaninglul. There is some clear contract with a pulling Receiver, and some authorization credential associated.
- for multi-hop transfer, original @mpc becomes meaningless in terms of guarantee for the Sender that the message will remain associated with expected authorization credentials on Receiver side. And if you say that only what is in @mpc counts when authorizing the pull, even if the PullRequest pulls on a different MPC, that becomes quite contrived. (do we allow messages with different @mpc in the same re-assigned MPC? What authorization data should be used by a PullRequest for an MPC? etc)
The subchannel solution allows for the following additional use case:
- a Pulling endpoint MSH (X) pulls messages from a single Hub, and is delivering to several Parties on its application side. It is just one endpoint MSH among several that pull from this Hub.
- Sending MSHs only specify @mpc based on the type of Service used in the header (several To/Parties can provide the same Service) so messages to these different parties still use same @mpc if for the same Service.
- Therefore, the endpoint MSH X is using same authorization data to pull from this MPC.
- Yet some To/Parties must have higher priorities than others, i.e. get their messages sooner.
- The Hub offers as a service to assign sub-channels based on To/Parties and their priority level.
- Then MSH X can pull selectively on these sub-channels, yet uses same authorization credentials that were agreed upon between partners, associated with the common @mpc value set from the beginning.
The "dot" notation I suggest is just an example. We could use a more URI-compliant notation, e.g. fragment identifiers.
That way, the MPC as a resource never formally change: it is only extended on the way with a property fragment that can be used for later selective pulling. In the case of a default MPC (no @mpc) adding the "default MPC" URI is just a convention that does not complcate the reassignment. We could decide that a Puller only needs to specify the fragment in that case.
From: Sander Fieten [mailto:firstname.lastname@example.org]
Sent: Friday, May 16, 2008 12:43 PM
Subject: Re: [ebxml-msg] Multihop and Pull
I do agree with you that reassigning a message to another MPC requires the MUST on line 1046 of the core spec to be changed, otherwise reassigning without modifying the message header will lead to a violation of the core spec. I think there are now two proposals for this change:
(1) [Pim] Change the MUST to a SHOULD. This allows intermediaries to reassign message to an abitrary MPC;
(2) [Jacques] Introduce the concept of subchannels and only allow to reassingments to subchannels.
Option (1) I think is the most easy change as it only requires one word to be changed or could be done in part two of the spec by relaxing the requirement of the core spec. Option (2) will require some more work in describing subchannels and their usage. Should this be done in the core spec or as an extension to the MPC defintions in part two? I would prefer option (2) as an extension to the core spec because I think the restriction on reassigning messages to subchannels is clearer.
Another thing is that on line 795 of the core spec it is stated that "A Sending MSH MUST be able to determine whether a submitted message should be pulled or pushed, and to which Message Partition Channel (MPC) it must be assigned". In the multi-hop situation one of the requirement is just the opposite, that the sending MSH does not need to know whether the message will be pulled by or pushed to the utlimate receiver. I'm not sure if this requires a change to the core spec or can be done by relaxing this requirment in part two in case of a multi-hop situation.
On 15 mei 2008, at 23:12, Sander Fieten wrote: