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

Jacques,

my comments inline in red.

On 4 jun 2008, at 02:48, Durand, Jacques R. wrote:

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.

I agree that the sender has to set the address information on the message so that the I-Cloud can route it and knows that the message will be pulled by the receiver. I'm not sure if the mpc that will be used for pulling by the receiver is already in the address information when the message is sent and when it is if there're equal. For example the sender may not know about the pulling and thus setting no mpc or the default one even if the receiver wants to pull the message from a different mpc. This is also related to the subchannel discussion. I think the requirement here is that the intermediary can determine, based on the address information on the message whether it being pulled or not and when it is pulled on which 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.

I agree, but as you say this is different from the Pull as described and requires different behavior from the endpoints. Consequence is that when you want to use pulling in a multi-hop situation you need to have an MSH implementation that is capable of more than Core V3.

I would however favor this solution!

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.

Agree, but see comment above on Core V3 conformance.

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.

Agree.

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.

I think the issue of addressing the CSR is now in a separate thread.

<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.

I would indeed assume such a mapping

Jacques

-----Original Message-----
From:  [mailto:] 
Sent: Tuesday, June 03, 2008 2:06 PM
To: 
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?document_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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php