[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Multihop and Pull
Pim: inline From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] Sent: Tuesday, May 20, 2008 2:20 PM To: Durand, Jacques R.; 'Sander Fieten'; ebxml-msg@lists.oasis-open.org 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.
<JD> a major difference for "transparency" is that @mpc is
part of headers, but the URL(s) are not so can be changed without altering
the message..
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.
<JD> The main reason why MPCs are assigned to [User] message
units and not to ebMS messages as a whole (eb:Messaging) is that the notion of
MEP is defined at User message unit level (i.e. for a single User message
unit)(see 2.2.2), and is orthogonal to any bundling. So a PullRequest is
targeting User Message units over a particular MPC. What is being queued for
pulling, is in fact message units.
But I see your point. I
think we have a problem with eb:signals: if @mpc must be added somewhere it
should probably be on signal Message units (Receipts, errors...) so that these
can be pulled independently , on some MPC.
As for making @mpc an
attribute of eb:Messaging, I wouldn't go as
far.
We have yet
to specify the bundling in a multi-hop context. Also we have not yet
deciced that all User Messages bundled together should be for the same MPC.
E.g. we might want to support "bulk" sending across the
I-cloud to some Hub, where the bundle will be broken down at this Hub for
detail pulling by many endpoint MSHs (based on different MPCs). (Conversely,
could a Hub getting many messages for the same destination - or that it knows
will be routed to teh same other Hub - perform bundling ?
So to sum up, I think if there is an errata to consider
it is to add @mpc for eb:signal messages.
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]