Sander:
I don't think there is any need to alter the "core spec" or make an
errata.
The behavior that is described in:
8.3.2. Reliability of the One-Way/Pull MEP
Consists of sending PullRequest itself as a reliable message so that in
case the response (pulled message) was sent but lost on its way along
with the Ack for the PullRequest, then the resending of (exact same)
PullRequest will be followed by resending of (exact same) pulled message
that was persisted.
That behavior was the only way (except for the use of MakeConnection) to
get this pulled message (also sent reliably) as it had to travel over an
HTTP response.
Now we are in a multihop context, and I claim that this is no longer a
"One-Way/Pull MEP" that we are talking about. It is in fact something
like a "One-Way/Push-then-last-Pull", yet to be described. One-Way/Pull
MEP is only for point-to-point.
In that case, what is described in 8.3.2 does not apply ! And rightly
does not need to, as the pulled message, if lost, will actually be
resend not by the pulled Intermediary but by the original endpoint (a
pusher). So yes, PulRequest does not need be sent reliably in a
multi-hop context, and the receiving endpoint knows that it is dealing
with a multihop case based on the P-Mode associated with the pulled MPC.
Now you could contend that it is inefficient to have the message resent
all the way through, even if it made it so far up to the intermediary
where it is pulled from.
But in that case I'd say if you want this behavior, you will configure
an Intermediary so that it is RM-enabled, and separate the multi-hop
path in two reliable but distinct sections (and sequences). We could
describe this option, and in that case indeed the PullRequest would
comply with what is described in 8.3.2 as what we would have is a
chaining of "One-way/multipush MEP" + "One-Way/Pull MEP" for the same
message. But this is different from the initial case we were concerned
about.
So I think in both cases we comply with core spec.
Does that address your concern?
Jacques
Original Message-----
From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Tuesday, July 29, 2008 1:47 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.8
(ebMS3-Multihop V08-JD.doc) uploaded
Jacques,
as mentioned during the call last week I think the solution as described
in the current proposal requires behaviour from pulling endpoint
different than specified in the Core V3. In an earlier document I posted
(http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/284
71/ebMS-lastpull-v1.doc
) I tried to show the problem is that the pulling endpoint will try to
initiate the reliable exchange in both ways by sending a CreateSequence
that includes an sequence offer. This offer however conflicts with the
CreateSequence that is already sent by the initiating endpoint and is
now waiting on the intermediary to be delivered.
The option I showed in the earlier document tries to stay close to the
Core V3 behaviour on behalf of the endpoint, but it has some issues
because of undefined behaviour. The scenario from the current proposal
doesn't differ to much from the one I described, it only seems to leave
out the reliable sequence for sending PullRequest messages. This means
there is no reliablity available for these messages, question is if this
is acceptable? If yes, should we alter the Core spec accordingly and
remove it there as well (otherwise multihop and point-2-point seem
inconsistent)?
Regards,
Sander
On 23 jul 2008, at 20:54, jdurand@us.fujitsu.com wrote:
> The document revision named Multi-hop Section Draft 0.8 (ebMS3-
> Multihop
> V08-JD.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
> Messaging Services TC document repository. This document is revision
> #6 of ebMS3-Multihop.doc.
>
> Document Description:
> Draft of the multi-hop section.
> V0.3:
> - a few updates in the definition section (editorial)
> - added a commented Flow diagram (section 1.7.1) on RM sequence
> establishment. To review.
> V0.4:
> - section 1.5 (Intermediary Role) rewritten, though not complete yet.
> (diff with 0.3 visible)
> V0,5:
> - section 1.5 updated based on feedback and extended for response
> messages.
> V0.6:
> - Added text to section 1.5 on streaming and store-and-forward models
> for implementing intermediaries
> V0.7:
> - Changed the text describing the streaming model to include two sub
> cases, asynchronous and synchronous streaming.
> V0.8:
> - a few updates / corrections (diffs visible)
> - fleshed out the "routing of Acks" multihop subsection at the end.
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?do
> cument_id=28918
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28
> 918/ebMS3-Multihop%20V08-JD.doc
>
> Revision:
> This document is revision #6 of ebMS3-Multihop.doc. The document
> details page referenced above will show the complete revision history.
>
>
> PLEASE NOTE: If the above links do not work for you, your email
> application may be breaking the link into two pieces. You may be able
> to copy and paste the entire link address into the address field of
> your web browser.
>
> -OASIS Open Administration
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php