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 - What is Offer good for anyway?


Marc

I agree that Offer is very useful. However, your rule doesn't allow me 
to do a synchronous CreateSequence, unless all further messages are 
synchronous (i.e. if the CS replyto is anon, then all following messages 
must be anonymous).

I would like to suggest a different rule:

The Offered sequence is directly correlated with the inbound sequence 
and it is the responsibility of the RMS to ensure that the ReplyTo EPRs 
of all messages sent on the inbound sequence share the same (outbound) 
RMD, and therefore the offered sequence is valid for all response messages.

[If you don't like that I have an alternative idea, but its less neat]

Paul

Marc Goodner wrote:
>
> The use of Offer is quite often referred to as “just an optimization” 
> which is the principal grounds that it is being argued that it should 
> be removed from the spec. While we agree it can be viewed as just an 
> optimization if you are looking at this from the perspective of having 
> long living RM sequences established between the client and server, 
> there is another view that makes it more useful and one use case that 
> can not be realized without it.
>
> First let me describe the two principal scenarios that we see for 
> using WS-RM.
>
>    1. Synchronous messaging resilient to communications failures.
>    2. Asynchronous messaging resilient to various kinds of failures.
>       AKA Queues.
>
> (1) Essentially this is about extending reliability to traditional 
> synchronous web service interactions be they one-way or request-reply. 
> Here synchronous means that both apps, the client and server, are 
> running at the same time and interacting with very low latency.
>
> (2) In the asynchronous, or queued, case the apps at the client and 
> server are running independently of each other. In this case the apps 
> at either side can potentially be subject to high latencies and can 
> tolerate failure conditions beyond just communication, i.e. the apps 
> may survive reboots. Applications may use a variety of mechanisms to 
> indicate where to send reply messages and how or whether those need to 
> be over a reliable channel.
>
> A straightforward implementation of (1) would be one where the AS and 
> the AD own the RM sequences they use to exchange messages. Logically, 
> this means the AS hosts its RMS in-proc and the AD hosts it RMD 
> in-proc. If the WSDL of the service includes two-way operations then 
> Offer makes establishing the back sequence easier and less-costly. 
> More importantly when one looks at the case of anonymous clients, 
> particularly on HTTP, there is one case where you need Offer. In this 
> case if you want to establish a reliable path back to the client, for 
> acks or responses, the service can not invoke a CS on the client. 
> Instead the client provides the Offer which is accepted by the 
> service. Subsequent messages using the Offered sequence are carried on 
> the HTTP response flow to the anonymous client.
>
> I do think that given the above we should not just cut Offer out of 
> the spec. From our perspective it would compromise our ability to use 
> the eventual OASIS standard of RM in comparison to how we are using it 
> today.
>
> I’m open to working with others to clarify the above points. In 
> particular the spec needs to convey the following:
>
>     * If Offer is present in the CS and it is accepted then the all
>       messages in the Offered sequence should be addressed at the
>       ReplyTo EPR of the CS message.
>
>     * That is the only rule. If an RMS can work with this (e.g. it is
>       a #1 above) then it can add the Offer and if not then it won’t.
>
> 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://bloglines.com/blog/paulfremantle
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]