[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.8 (ebMS3-Multihop V08-JD.doc) uploaded
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]