Re: [ws-rx] i090 - Offer, let's get back to the original question

[Paul Fremantle <paul@wso2.com>]

Matt
+1 to this proposal.

Paul

Matthew Lovett wrote:
>
> Hi folks,
>
> I think that Paul and Marc are doing good stuff here to try and 
> address the original question in i090, without attempting to solve 
> i089. However, I think that the proposals below don't quite adress 
> that point - if we are not considering the anon cases then there is 
> really no need to link the sequences. [1]
>
> i090 asks 2 core questions, quoting from the issue "... the RMD is not 
> informed of the endpoint it should use to send protocol messages back 
> to the RMS for the offered sequence, or which AD endpoints the 
> sequence can be used for."
>
> Taking the 2 in turn:
>
> a) Where should protocol messages for the offered Sequence be sent?
>
> I think this is something we can solve, and I don't like the idea of 
> assuming that the replyTo from the create sequence is the right place. 
> Nor do I think that the acksTo for the outbound sequence is a good 
> match. I think it's better to allow the RMS and RMD to be as cleanly 
> seperated as possible. To that end I propose adding a EPR into the 
> Offer element:
>
> Line 247 Insert:
> <wsrm:Endpoint> wsa:EndpointReferenceType </wsrm:Endpoint>
>
> Line 282 Insert
> /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint
> This REQUIRED element, of type wsa:EndpointReferenceType as specified 
> by WS-Addressing [WSAddressing] specifies the endpoint reference to 
> which WS-RM protocol messages and faults related to the offered 
> Sequence are to be sent.
>
>
> b) Which endpoints can the sequence can be used for?
>
> I think the spec should be silent on this. We left it up to the 
> implementation to work out which sequence to use on the outbound side, 
> and I think it's best to follow the precident on the reply side. All 
> we really know is that the reply should go to the endpoint dictated by 
> WS-A, and it's up to the replying system to choose an appropriate system.
>
> I don't think that any spec changes are required to make that clear, 
> though I'm open to suggestions for clarification.
>
> I'd like this proposal to replace the existing proposal 1 (removal of 
> offer), if possible.
>
> Thanks,
>
> Matt
>
> [1] And, yes, I think the outcome of i089 may well need to link the 
> sequences, but I'm trying to stay on topic here ;)
>
>
> Paul Fremantle <paul@wso2.com> wrote on 14/03/2006 18:07:35:
>
> > Marc
> >
> > What you are saying here supports clarifying the definition of offer.
> >
> > If we think that "Offer is not for the establishment of long running
> > sequences that service multiple applications" (which by the way I agree
> > with) then I think we should be clear in the spec.
> >
> > My proposal is that we clearly state that an offered sequence is 
> coupled
> > to the sequence with which it was offered for. Specifically I believe
> > that the lifecycles of the sequences should be tied together. If you
> > close one then the other should be closed. If you terminate one then 
> the
> > other should be terminated. And I believe that we should recommend that
> > the Offered sequence is used for replies to messages sent on the
> > outbound sequence.
> >
> > Paul
> >
> >
> > Marc Goodner wrote:
> > >
> > > Let’s get back to discussing the original issue i090. The discussion
> > > has been entirely hijacked by issue i089 at this point which isn’t
> > > helping us. I’ll take my share of the blame here since I offered a
> > > compelling use case for Offer that involved an anonymous uri in the
> > > ReplyTo, but that isn’t the only use. So let’s leave that completely
> > > to the side and see if this still makes sense. I think it does.
> > >
> > > The original issue i090 noted that the RMD does not know where to 
> send
> > > protocol messages and has to make assumptions (which is bad). 
> Proposal
> > > 2, which I made, was that the protocol messages for the accepted 
> Offer
> > > should go to the ReplyTo. I accept that this proposal may need to be
> > > revised, but I do stand by the direction there. That is, if an Offer
> > > is included in a CS then the Offered sequence MUST be associated to a
> > > well-known EPR; the ReplyTo of the CS in my proposal. This provides
> > > for simple usage of Offer in non-multiplexing scenarios.
> > >
> > > The example given in the issue is not a good one for the use of 
> Offer.
> > > This example has two applications are sharing a presumably long
> > > running sequence to a common endpoint. It then asks in this scenario
> > > if when the RMS were to Offer the reverse long running sequence, 
> which
> > > endpoints would that sequence be used for? I would suggest that Offer
> > > is not for the establishment of long running sequences that service
> > > multiple applications. Offer could easily be used here if each
> > > application had its own sequence. It is the multiplexing of multiple
> > > apps over the same sequence that confuses the proper use of Offer and
> > > deserves further clarification in the spec beyond what has been
> > > proposed to date.
> > >
> > > Let’s turn this around for a second. How did the RMS in this example
> > > establish a sequence to the RMD, possibly even absent an application
> > > request to do so, and the RMD establish a reverse sequence back to 
> the
> > > RMS (now acting as an RMD)? How did the RMS know the two apps should
> > > share the sequence to the RMD? How does the RMD know that it has a
> > > reverse sequence back to the RMS that it can use for application
> > > replies? Does it have a catalog of the many possible EPRs that
> > > possibly pertain to the reverse sequence? What if an EPR is 
> related to
> > > more than one sequence established with one or more RMS(s)? These are
> > > all implementation details that are not spelled out in the spec. Does
> > > that mean that we should prohibit multiplexing multiple apps over a
> > > single sequence? Not in my opinion. It seems useful. It will take a
> > > clever implementation to do it right though. Especially to do this
> > > securely if all those apps are sharing the same sequences.
> > >
> > > Let’s imagine we have an application that wants to invoke a service
> > > one or more times over a short period of time over an unreliable
> > > network and get its responses reliably. Say the address book query
> > > program described in issue i090 running on a notebook tethered via
> > > Bluetooth to a handi connected to the internet over GSM. Not
> > > unreliable enough? Let’s add a VPN connection to the corpnet where 
> the
> > > address book app is running. In this scenario providing an Offer
> > > removes a full req/resp leg. Whether you want to call it an
> > > optimization or not I don’t care, this seems of some benefit.
> > >
> > > Marc Goodner
> > >
> > > Technical Diplomat
> > >
> > > Microsoft Corporation
> > >
> > > Tel: (425) 703-1903
> > >
> > > Blog: http://spaces.msn.com/mrgoodner/
> > >
> >
> > --
> >
> > 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
> >

-- 

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