[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?
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/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]