OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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



[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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]