RE: [ws-rx] Minimalist GetMessage proposal: the anon use case

[Matthew Lovett <MLOVETT@uk.ibm.com>]

Hi Jacques,

As Doug has already replied, I think
that you may have misunderstood the purpose of wsrm:Offer/wsrm:Endpoint.
The text describing that EPR is talking about protocol messages, not application
messages that are assigned to the sequence.

Consider the case where a client has
made an offer to a server, and everything is addressable (no need to worry
about anon here!). The client sends request messages within the outbound
sequence, and reply messages are: a) directed to a reply EPR as per WS-Addressing;
b) assigned to any sequence that the server chooses (probably the offered
sequence, but is has freedom here).
Ack messages for the outbound sequence
go to the wsrm:CreateSequence/wsrm:AcksTo, and ack messages for the offered
sequence go to wsrm:Accept/wsrm:AcksTo.

So far so good. If the client wants
to send a Close or Terminate message for the outbound sequence then they
send it to the same EPR that they used for the Create (it seems reasonable
to assume that this EPR will still be there). However, before we introduced
the wsrm:Offer/wsrm:Endpoint, the server didn't have an EPR to send a Close
or Terminate for the offered sequence. As Doug said, we could have assumed
that the replyTo from the Create was stable, but that seemed a stretch
too far, so we added the wsrm:Endpoint EPR instead.

Perhaps the text needs some more elaboration,
or the name 'Endpoint' is not intuitive enough? If anyone has suggestions
for clarification then I'm sure it would improve the spec.

Cheers,

Matt


"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 05/05/2006 00:39:36:

> That crossed my mind too…
> But then the spec seems to rule that case out
in case of offered 
> sequences, given the exclusive scoping to one endpoint assumed by:
> wsrm:Offer/wsrm:Endpoint (WD12, Line283)
>  
> Jacques
>  
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, May 04, 2006 3:53 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
>  
> 
> I'm a bit lost - too much email on this today :-)  but even if
there
> as a wsrm:Identifier 
> in a message that doesn't tell you which client it is since a 
> sequence can span 
> multiple endpoints. 
> -Doug 
> 

> 
> "Durand, Jacques R." <JDurand@us.fujitsu.com> 
> 05/04/2006 03:17 PM 
> 
> To
> 
> "Paul Fremantle" <paul@wso2.com> 
> 
> cc
> 
> "wsrx" <ws-rx@lists.oasis-open.org> 
> 
> Subject
> 
> RE: [ws-rx] Minimalist GetMessage proposal: the anon use case
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> - The case reliable-in/reliable-out works quite well, provided the
RMS
> does the correlation between initial sequence and offered seq, as
> recommended in 4.2.
> - The case unreliable-in/reliable-out seems to need the "hint"
you
> mention in 4.2., plus some other way to offer a sequence than the
CS
> carrier.
> 
> In any case, the many-anonymous(RMD)clients- to-one-(RMS)server appears
> to be quite a common case (many users of the same WS instance), to
> justify adding back 4.2 in your proposal...
> 
> Jacques
> 
> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com] 
> Sent: Wednesday, May 03, 2006 11:15 PM
> To: Durand, Jacques R.
> Cc: wsrx
> Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use
case
> 
> Jacques
> 
> You are quite right. This is an interesting situation. One of the
> problems is that we do not in this spec define how messages are 
> allocated to sequences. The IBM proposal simply shifts this problem
to 
> the EPRId as you point out.
> 
> In one of my own early drafts of the proposal I had these words in
> section 4.2, but I removed them for simplicity. However, if they are
> useful they could be added back.
> 
> "The WSRM specification does not define the allocation of messages
to a 
> sequence. In the case of reliable request-response with an anonymous
> client, the server MAY make a correlation between an incoming sequence
> and an offered sequence. In the case where the request message is
> unreliable, and the client is anonymous, there might not be a clear
> basis to allocate messages to a given sequence. In this scenario the
> client MAY add the <wsrm:Identifier> of the offered sequence
as a SOAP 
> Header element or elsewhere in the message as a hint to the server."
> 
> Paul
> 
> Durand, Jacques R. wrote:
> > Paul:
> >
> > Are you sure this works when two different (un-addressable) clients
> are
> > sending an anonymous wsrm:Offer/wsrm:Endpoint to the same RMS-to-be
> > endpoint, say for offering sequences S1 and S2? 
> > The offered sequences S1 and S2 have to be clearly associated
from the
> > start with the right client-RMD, by the server-RMS.
> > With an in/out pattern where the in message is not sent reliably,
how
> > would the server-RMS know if it should use S1 or S2 when sending
the
> out
> > message for an in  message of one of the two initiators?
> > Don't we still face the same issue of distinguishing anonymous
> endpoints
> > that IBM proposal tries to address ( with wsrm:EPRid) ?
> > (Do I miss something?)
> >
> > Jacques
> >
> > -----Original Message-----
> > From: Paul Fremantle [mailto:paul@wso2.com] 
> > Sent: Wednesday, May 03, 2006 12:05 PM
> > To: wsrx
> > Subject: [ws-rx] Minimalist GetMessage proposal
> >
> > Based on some of the discussions it seemed to me that it could
be 
> > valuable to produce a completely "minimalist" GetMessage
proposal.
> >
> > This is a new proposal that is based on the previous WSO2 proposal.
> >
> > The proposal removes the MessageID selector in the GetMessage
-
> relying 
> > on simply getting whatever message the server sends back next.
> >
> > Also it removes the section 4.2. Effectively section 4.2 is an
> > optimisation: for example to support unreliable-in/reliable-out
a
> client
> >
> > could do a createsequence+offer and never use the outgoing sequence.
> In 
> > this case there is an overhead, which 4.2 aimed to remove, but
this 
> > simplifies the proposal by focussing on the bare minimum required
to 
> > support the most common use cases, but still allowing the other
use
> case
> >
> > with a slight overhead.
> >
> > I've also included a sample message flow which I hope helps understand
> 
> > the proposal and show the general usage.
> >
> > Paul
> >
> >   
> 
> -- 
> 
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> 
> http://feeds.feedburner.com/bloglines/pzf
> paul@wso2.com
> 
> "Oxygenating the Web Service Platform", www.wso2.com