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?
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Fri, 10 Feb 2006 12:35:40 -0500
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]