[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; ebxml-msg@lists.oasis-open.org 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.
Jacques
From: Sander Fieten [mailto:sander@fieten-it.com] Sent: Friday, May 16, 2008 12:43 PM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Multihop and Pull Pim,
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.
Sander
On 15 mei 2008, at 23:12, Sander Fieten wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]