Re: [ws-rx] i090 - What is Offer good for anyway?

[Doug Davis <dug@us.ibm.com>]

"Marc Goodner" <mgoodner@microsoft.com>
wrote on 02/09/2006 02:06:06 PM:

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

How does the RMS know this is the case? Or are you
assuming that the
application knows that this MUST be the case by choosing
to use the
anonymous uri?
  
> (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.

Without additional semantics that are agreed to by
both parties,
which would typically mean they are written down in
the spec,
how does the RMD resend replies?
One possible solution is to assume that as long as
the socket is
still open then the RMD/AD must still be working on
the request
and therefore the RMS will not resend (on a new socket).
 If the
connection is broken then a new connection can be
used to resend
and the RMS will wait, again, on this socket.  When
something does
flow back on the http response flow then it will not
only contain
the reply but also the Ack. Is this the approach you'd
like to see
specified in the spec?
I have two concerns about this:
1 - the Ack will not flow back until the response
is 
generated - which could be a while - and if the socket
does go 
down the RMS could potentially resend a
message that it normally would not have.  With
an ExactlyOnce DA
it might not be an issue, but in a non-ExactlyOnce
DA we could
end up processing the message more times than we would
if we 
followed a more traditional RM usage pattern.
2 - this links the RM processing with the application
processing.
Or put another way, it links the RM processing with
the RMD->AD
processing and makes an assumption that this RMD->AD
processing
will happen in a timely fashion.  While the scenario
you claim
this will be used for assumes this to be true, is
this really
something the RM spec should count on - or even allow?
 Up to now
the RM spec has tried (thru long painful discussions
of DAs) to
avoid pulling in anything outside of the RMS->RMD
interaction.
This walks the line on violating that rule.  While
I'm very
sensitive to the desire to support anonymous replyTo
I believe
there are better solutions that do not require this
type of
special-casing of the RM code.

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

Given that I believe the CS replyTo will probably
be anonymous while
the replyTo on the app messages may not be, if we
did accept this
approach I'd much prefer a wording that said something
like:
If Offer is present in the CS and it is accepted then
all the messages
sent to the various wsa:ReplyTo EPRs used in the messages
of the original
sequence should use the offered sequence.

> Marc Goodner
> Technical Diplomat
> Microsoft Corporation
> Tel: (425) 703-1903
> Blog: http://spaces.msn.com/mrgoodner/ 
>