[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - End-to-end CreateSequence and pulling (ebMS-lastpull-v1.doc) uploaded
Sander: Overall that seems to work. But some of the problems you are trying to overcome may not exist after all, see below. >[section 1.3] In the multi-hop situation the setup of the RM-sequence starts at the sending endpoint which >pushes a CreateSequence signal into the I-Cloud. This signal will be transferred through >the I-Cloud to the last intermediary where it is stored until the ultimate receiver >starts pulling messages (step 1). <JD> Yes. The CreateSequence signal has "routing info" piggybacked on it (either wsa parameters or dummy eb:Header), that includes MPC id. The Intermediary knows it has a "Pull contract" for this mpc. >When the ultimate receiver wants to pull messages it first has to establish a RM-sequence >for sending the PullRequest signal. When acting according to the Core spec the CreateSequence >will contain an offer to establish a RM-sequence for sending messages to the >ultimate receiver (step 2). <JD> Reading Core V3 again, I believe that the obligation to use RM for PullRequest only exists for the "Reliable One-way / Pull MEP (section 8.3.2)". But in our new multi-hop context, we have something new: this is still a One-way, but Pushed half-way and Pulled half way, something not described in the core spec. Something we could call: "One-way / Push-then-Pulled". For this, Core V3 does not say anything in Section 8.3 or in appendix B.2.3: it is not your regular "One-way / Pull MEP". In particular, the destination of the PullRequest (from endpoint B to last Intermediary) is not supposed to have any RM capability. So I consider we are relieved from the necessity to send PullRequest "reliably". In that case, your steps #1 and #2 may not be necessary. In fact, the reason to use RM for PullRequest (for reliable One-way / Pull in Core V3) was to provide a way for the pulled side to resend the User Message, for each PullRequest duplicate received. This mechanism does not exist in our multi-hop topology: the only endpoint able to do resending of the (exact) same UserMessage, is the initial sender A. And as soon as the last intermediary has sent the UserMessage (over the backchannel of a PullRequest for this MPC) then if the message is lost there is no use for PullRequest resending: only the original sender will do the resending, which can then be relayed by a NEW PullRequest later on. >1. Will the endpoint react as expected on the denial of the offered sequence? I.e. will it send a PullRequest without having established a RM-sequence on which user message can be sent? It seems illogical it would do so because there is no reliability assurance for these message; <JD> that would indeed be a concern if the contract was of a "reliable One-way / Pull". A conforming endpoint should NOT proceed further if it cannot extablish a RM sequence for the UserMessage. But precisely I claim we are not doing "reliable One-way / Pull" here. So I believe your problem disappear if you remove Steps #1 and #2. 2. Is it allowed to combine a CreateSequence and Acknowledgement signal in one SOAP message? As both signals are for different sequences and in different parts of the message it seems that this is allowed; <JD> same as above: you seem to assume the Last Intermediary has RM capability: we don't have to. 3. Will the endpoint push the CreateSequenceResponse to the I-Cloud? <JD> yes, and the question is where its routing data comes from. I believe it comes either from (a) the Pmode, or from (b) the AcksTo EPR that was inside the CreateSequence. I would prefer (b). As discussed at F2F, we can decide that AcksTo value is where all RM response signals (Acks, CSR...) should go to. This AcksTo contains ref parameters associated with the EPR, that can be all the reverse routing function needs. <JD> Another problem that I think we have to address carefully: today, an MSH is not supposed to respond anything to a PullRequest other than either (a) a UserMessage, or (b) an EBMS-0006 error. Only in case (b) you'd be able to piggyback an RM CS as you do in step #5. That means, if this MPC is used for other messages / other RM sequences, there might always be some UserMessage to pull and you would never be able to piggyback the awaiting CS. For your step #5 to work, we need to require a 1-to-1 mapping between MPC and RM sequence "timewise" i.e. at any point in time, only one RM sequence at most is active for each MPC. Jacques -----Original Message----- From: sander@fieten-it.com [mailto:sander@fieten-it.com] Sent: Tuesday, June 03, 2008 2:06 PM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Groups - End-to-end CreateSequence and pulling (ebMS-lastpull-v1.doc) uploaded Another option for transferring the end-to-end CreateSequence to the ultimate receiver in case the receiver uses pulling. This option doesn't require dummy ebMS headers or messages. -- Mr. Sander Fieten The document named End-to-end CreateSequence and pulling (ebMS-lastpull-v1.doc) has been submitted by Mr. Sander Fieten to the OASIS ebXML Messaging Services TC document repository. Document Description: This document looks at another option for transferring the end-to-end CreateSequence signal from the last intermediary to the ultimate receiver that uses pulling. The proposed solution does not require dummy ebMS headers or messages to be used. View Document Details: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?docu ment_id=28471 Download Document: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/2847 1/ebMS-lastpull-v1.doc 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]