| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] An alternative approach to make anon reply-to and sync rm work
- From: Doug Davis <firstname.lastname@example.org>
- To: Paul Fremantle <email@example.com>
- Date: Fri, 10 Mar 2006 11:24:14 -0500
I think we need a ruling from the WSA
But to me anon replyTo means
the response goes back on this http response flow. If this response
flow is closed then you're out of luck. If you want the response
to flow back on some other http response flow then you'd need to use a
new URI. Again, I don't read anon replyTo as 'any response flow',
but rather 'this response flow', or in more specish words, the http response
flow of the http request flow that had this request - not just any request.
Even if there are two relatesTo (like you suggest in your other note)
I don't think it changes the implicit correlation requirements that anon
BTW - in general I do agree that
there can be two relatesTo headers but you need to make sure that the rules
for how responses are generated and where they go are still adhered to.
As I said, if you defined a new URI it could work. For example,
if the replyTo was "anonRM" and the semantics of that meant "same
as WSA anon, when possible, but if the connection isn't there then use
the SeqID (or whatever we choose) as the correlator when a new ackReq comes
in" then it might be able to work w/o bending the WSA rules. In
this case I think the response to your ackReq/poll request might have 2
relatesTo - 1 to indicate its a response to the ackReq and one to indicate
its a response to the original request. The first is valid per WSA
(assuming the ackReq used anon replyTo), and the 2nd is valid per anonRM
|Paul Fremantle <firstname.lastname@example.org>
03/10/2006 11:01 AM
|Re: [ws-rx] An alternative
approach to make anon reply-to and sync rm work|
I'm sure this one is fixable.
I'm not a WS-Addressing expert (but I know we have some). If the
ackrequest message had the same messageId as a previous business
message, I think that would be a problem. But that is not what I'm
proposing. I'm proposing that the response message has the relatesTo
pointing to the original message. It is perfectly acceptable to have
multiple messages that relate as replies to a single message.
Doug Davis wrote:
> That's a whole lot of "ifs" and other conditional terms
> Still pondering your note (lots of "this case but not this case"
> things to keep straight) but something else to worry about.... I'm
> sure you can respond based on just an ackReq coming in. The
> will need to have a wsa:RelatesTo (when wsa is turned on) that points
> to the messageID of the request. In order to comply with WSA the
> ackReq's messageID would have to be the same as the original request
> message - but then you run into the uniqueness issue around
> messageID's. I know at one point WSA may some allowances for
> resending of messages and reusing messageIDs are ok then, but this
> isn't a retransmission, its really a new message so I'm not sure it
> would fall into that category.
> *Paul Fremantle <email@example.com>*
> 03/10/2006 03:21 AM
[ws-rx] An alternative approach to make anon reply-to and sync rm
> I think the important point here is that the use of this model is
> optional for an RMS.
> There are a number of scenarios, some of which work and some don't.
> question is - is the RMS (or the RMD) ever forced to use a scenario
> which doesn't work?
> For an anonymous reply-to case, I think the relevent the scenario
> and issues are:
> A) Is the client completely synchronous? In other words, there is
> of correlating a response message other than the HTTP channel it comes
> back on?
> B) The opposite of A - in other words the client can correlate based
> WSA relatesTo.
> C) Is there an RMS that spans multiple clients (for example a gateway)?
> In the case of A (but not C):
> the RMS cannot use the ackrequested model. It has to rely on the
> replaying of request messages. So either the RMS can support this
> or it should not start the sequence with anonURI+Offer.
> In the case of B (but not C):
> the model works fine. Like any other async client, the correlation
> request messages takes place based on something in the message, and
> nothing new happens here.
> In the case of C and A:
> The only way to make this work is if the gateway "knows"
the MEP. In
> this case the RMS can use the request replay model. In other cases
> RMS should not start the sequence with anonURI+Offer.
> In the case of B and A:
> In general this is not possible and the RMS should not start the
> sequence with anonURI+Offer. On the other hand a smart RMS or gateway
> could correlate the relatesTo and therefore route the requests to
> relevant client.
> However, I think C as a whole is an unlikely scenario. A sufficiently
> complex installation to support a shared RMS or a gateway would also
> have the necessary support to expose ports on firewalls, etc, and
> have no need to initiate anonymousURI+Offer type sequences.
> Doug Davis wrote:
> > Paul,
> > I think there are some problems with this - I still think this
> > violates WSA. There's a reason anon replyTo means, in essence,
> > http response flow of the request message. The connection
> > correlator between the request and the response - meaning if
> > anon requests come in the only way the server knows which client
> > which response is thru the http connection. In your scenario
> > are two anon requests sent to the server using the same sequence
> > no responses sent, when the third connection is made (to carry
> > ackReq) how does the server know which client is initiating the
> > request. It can not simply assume that just because they
> > same sequence that they also share WSA state and that any response
> > be sent to any client. The correlation is now lost.
> > thanks,
> > -Doug
> > The biggest issue with the two way reliable HTTP + anonURI case
> > requirement to replay request messages to get responses.
> > Why is this a problem? Because it means that the client has to
> > requests (if and only if the interaction is two-way) beyond getting
> > ack
> > for that request.
> > This means that the RMS has to "know" if this particular
> > interaction is one-way or two way. This means that for example,
> > gateway can't do it without looking at WSDLs etc.
> > Why do we need to do this: because WSA states:
> > "For instance, the SOAP 1.2
> > HTTP binding puts the reply message in the HTTP response."
> > So I agree we should not put an application reply to message
A in an
> > HTTP response to application message B.
> > However, if we added the following text to our spec:
> > "In the case where an offered sequence is used, the RMS
may send an
> > <wsrm:AckRequested> header together with an empty SOAP
body. A valid
> > response to this message MAY either contain an empty SOAP body,
> > contain a message for the *offered* sequence".
> > The result of this would be that the response message on the
> > would be a valid reply to the request message and therefore would
> > break the
> > WS-Addressing text above. Effectively WSRM would be defining
> > the SOAP request/reply would be, and therefore "making it
> > with respect to the HTTP binding.
> > So, when things are going well the HTTP reply to any given request
> > message would be the
> > correct response message. But in the case that this message got
> > delayed, the RMS would have a choice. If it still had the message,
> and it
> > "knew" that the MEP was two-way, it could choose to
> > original request OR it could send an empty body with an ackRequested
> > header.
> > This also gives the offered sequence a message onto which to
> > piggyback Close and TerminateSequence requests, solving another
> > More importantly it removes the need for
> > the RMS to "know" the MEP, because by the repeated
> > empty-body ackRequests,
> > the RMS can get the offered sequence into a decent state.
> > The only compulsory implementation change I see is that the RMD
> > have to be coded to know what this empty body + ackrequest means.
> > From the RMS I see this as optional. It is completely up to the
> > whether it initiates a CS with Offer+AnonURI. So if an implementation
> > doesn't support this,
> > it will never initiate such a channel. And if the RMS does initiate
> > a channel, it will "know" it is in this mode, that
it needs to send
> > occasional empty ackrequests until it can close down the offered
> > In addition we would have to remove the words that say Offer
> > an optimization,
> > because this usage makes a specific correlation between a sequence
> > offered sequence.
> > Paul
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > http://feeds.feedburner.com/bloglines/pzf
> > firstname.lastname@example.org
> > "Oxygenating the Web Service Platform", www.wso2.com
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> "Oxygenating the Web Service Platform", www.wso2.com
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
"Oxygenating the Web Service Platform", www.wso2.com
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]