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

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

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
>