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

[Doug Bunting <Doug.Bunting@Sun.COM>]

Doug,

Could you explain why the synchronous response must contain the reply to 
the particular request the AS just told the RMS to make?

I am not sure the current specification or the WS-A specification limits 
use of the anonymous EPR to the immediate synchronous response.  If I 
were implementing one of the scenarios Marc mentions, I would place 
whatever business reply was available in the next available response for 
the same sequence.  Something like:

    msg A ---> RMD
    RMS <--- ack msg A
    msg B ---> RMD
    RMS <--- ack msg B, reply <relates to msg A>

At some point, it may be necessary for the RMS to send an empty request 
to get still-pending replies.  Another alternative would be for the 
business protocol layered above WS-RM to support multiple replies in a 
single response message (with all of the associated wsa:relatesTo 
confusion taken care of at that level).

Yes, this is a more complicated queueing RMD I'm imagining but I think 
such an implementation is possible using the current specifications.  
The RMS need only know the RMD support anonymous wsa:replyTo EPRs 
because the simpler "immediate reply" RMD should appear identical from a 
WS-RM perspective.  That is, an RMS should be depending on wsa:relatesTo 
for correlation and not the request / response transport linkage.

thanx,
    doug

PS. I don't think the above implementation scenario need be described in 
our specification.

On 10/02/06 05:20, Doug Davis wrote:

>
> "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/
> >