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


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.


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


"Oxygenating the Web Service Platform", www.wso2.com

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