RE: [ebxml-msg] Groups - End-to-end CreateSequence and pulling (ebMS-lastpull-v1.doc) uploaded

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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