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


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/

 



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