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?


Folks,
 
I am afraid that this is not really correct from WS-A perspective. The semantics of anonymous is defined by the specific binding. In this case, there is a clear semantics for SOAP/HTTP to be the response channel. You can not assume another connection. If there is a different binding, you can assume a different semantics for anonymous value and use it accordingly.
 
On a related note, this is why anonymous on a request message is so darn hard to pin down because the semantics in a request message is ambiguous at best. Some implementations assume that the address ([destination]) is actually provided by the context (HTTP post), and some do not retain the context and can not use it when anonymous is used as the destination address.
 
--umit
 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, Feb 10, 2006 9:36 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i090 - What is Offer good for anyway?


DougB,
  You're exactly right - the way you described it can work - I was just trying to understand
how Marc saw this working - there are lots of options and the question then becomes
how can you support that in an interoperable way?  Using your solution how can the RMS
know for sure that the reply to msgB will contain the reply for msgA?  How can the RMD know
whether or not "this anonymous connection" is really the same guy as the previous one?
Remember there could be multiple RMS's using the same sequence.  Should the RMS only
support this when it can determine that the RMD can support some kind of polling thing like
you described to get that last message?  Unless you control both side of the wire I don't think you can
know the answers to these (and all of the other) questions given the current level of the specs.
So, bringing this back to Offer...   if Offer remains so that we can support this one use-case
then I think we need to fully explain what is expected by both sides otherwise we will not
get interoperability.  You said you don't think this needs to be described in the spec, but
how can we not add something about it?  Right now I think its valid for the RMS to assume
my solution and the RMD to assume your solution - they are not compatible - is RM
broken? Is one of the two sides broken?  What's a customer going to think?  I doubt they
would care which way it works just as long as it works w/o having to pay a huge service
contract to fix things.  Oh wait, maybe I'm thinking about this all wrong...  :-)
thanks
-DougD


Doug.Bunting@Sun.COM wrote on 02/10/2006 11:21:44 AM:

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