[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] [i090] Use of offered sequences unclear in current spec
Paul,
Without offer, when an RMS wants to send a message reliably, it needs to
make a decision as to which RMD to send the message to, in order to get the
message reliably delivered to the AD. It then establishes a sequence with
the RMD if it needs to and assigns the message to it. The RMS now knows
that it has a sequence to a particular RMD, because it chose the RMD to
establish the sequence with. The behaviour to establish a sequence in the
reverse direction should be exactly the same IMO.
With offer, the RMS is in the same position. It has a message it wants to
send reliably and it makes a decision as to which RMD it needs to send the
message to. Now lets say the RMS has an offered sequence that it could
use. How does the RMS know that the offered sequence goes to the RMD it
needs to send the message to? It doesnt have that information.
I agree that an RMS needs to decide which sequence to use for a particular
message and that that is out of scope of the specification, but without
offer it does at least know which RMD each sequence goes to, because it
established them in the first place.
I think an implementation that ignores any WS-Addressing information as to
where to send a reply and chooses an outbound sequence based solely on the
inbound sequence that the request came in on will cause interop problems
with RMS implementations that do not expect that behaviour, so stating that
this is outside the scope of the specification concerns me.
Thanks, Dan
WS-Reliable Messaging Architect and Team Lead
IBM WebSphere Messaging Design and Development
MP 211
Hursley
Tel. Internal 248617
Tel. External +44 1962 818617
Email. millwood@uk.ibm.com
Paul Fremantle
<paul@wso2.com>
To
23/01/2006 16:10 Daniel Millwood/UK/IBM@IBMGB
cc
ws-rx@lists.oasis-open.org
Subject
Re: [ws-rx] [i090] Use of offered
sequences unclear in current spec
Daniel
The assignment of messages to sequences is an application level concern,
and one that neither the submitted specification nor the latest work of
the TC covers. This seems to be making assumptions about the mapping
between messages and sequences that are not in the specification.
In particular you seem to be assuming that the return sequence is
decided based on the ReplyTo address. Another different assumption would
be that the return sequence is decided based on the incoming sequence or
a combination of the incoming sequence plus the ReplyTo address. I don't
believe it is part of role of this specification to decide this. I think
that that is an implementation specific issue.
In fact, one implementation (Apache Sandesha) will treat the scenario
you describe below as you desire. In other words two sequences are used
for responses. For messages to A the initial offered sequence will be
used and for messages to B a new sequence will be created.
I think Offer is a useful feature and I do not believe that removing it
helps make the semantics of your scenario any simpler. In either case
the responding agent has to make decisions about which sequence to use
for each message, and there are multiple options.
Paul
Daniel Millwood wrote:
>
>
> Title: Use of offered sequences unclear in current spec
>
> Description/Justification:
> When an RMS sends a CreateSequence that includes an offer, the offer is
> meant to be an optimisation for creating a sequence back from the RMD to
> the RMS. Closer inspection highlights issues with this approach.
>
> The RMS knows the endpoint of the RMD and sends it the CreateSequence
> message with the Offer, but the RMD is not informed of the endpoint it
> should use to send protocol messages back to the RMS for the offered
> sequence, or which AD endpoints the sequence can be used for.
> Now, the RMD could assume that
> a) It should send protocol messages to the same endpoint that it
> sends the CreateSequenceResponse message to for the inbound sequence.
> b) It should send protocol messages to the same endpoint that it
> sends Acks to for the inbound sequence
> c) It should send protocol messages to the same endpoint that it
> would have done if it had created the outbound sequence itself, which
could
> be a, or b, or another endpoint as yet unknown to it.
>
> but assumptions break interoperability and the RMD still doesnt know
which
> application messages can use the sequence.
>
> As an optimisation, the offer should not change the behaviour that would
be
> observed without the optimisation.
>
> Lets take an example. Two applications A and B use reliable messaging to
> query addresses from an address book application at endpoint X. They
both
> use the same RMS and share the same sequence, and the RMD at endpoint X
> passes the messages onto the address book app where addresses are queried
> and need to be sent back. Application A sets a wsa:ReplyTo of Endpoint A
> for its replies. Application B sets a wsa:ReplyTo of Endpoint B for its
> replies. Both these endpoints support WSRM. When the replies are sent
> back, two sequences are established. One to endpoint A and one to
endpoint
> B.
>
> Now try and do the same with offer. The RMS creates the outbound
sequence
> and offers a sequence the other way. Its accepted by the RMD. Now the
> application messages arrive at the RMD, are processed by the address book
> app and the replies need to be sent back to Endpoint A and Endpoint B.
> Which endpoint does the offered sequence service? None, A, B, or both?
>
> Further more, since the spec doesn't limit the offered sequence to just
> replies (it can be used for any msg going from the RMD to the RMS) this
> problem is made even worse. Even before the first application message
from
> the RMS to the RMD is sent, the RMD could have a message for the RMS. How
> does the RMD know whether or not the wsa:To EPR in this message matches
one
> of the possibly many RMS EPRs that the offered sequence is for?
>
> The result is the creation of an offered sequence where its not clear
which
> application messages can use it, or where to send the protocol messages.
>
> Target: core
>
> Type: design
>
> Proposal:
>
> Whilst there may be a subset of WSRM usecases where offer could make
sense,
> I believe it is too open to interpretation to be interoperable. For the
> benefit of interoperability, it should be removed from the spec.
>
> Delete from <wsrm:CreateSequence> in line 274, through to 277
> Delete lines 309 through to 330
> Delete lines 369 through to 384
> Delete line 1043
> Delete line 1060
> Delete lines 1090 through to 1106
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
> IBM WebSphere Messaging Design and Development
> MP 211
> Hursley
> Tel. Internal 248617
> Tel. External +44 1962 818617
> Email. millwood@uk.ibm.com
>
>
>
>
> Doug
> Davis/Raleigh/IBM
> @IBMUS
To
> Christopher B
> 12/01/2006 14:04 Ferris/Waltham/IBM@IBMUS
>
cc
> Daniel Millwood/UK/IBM@IBMGB,
> Matthew Lovett/UK/IBM@IBMGB, Peter
> Niblett/UK/IBM@IBMGB
>
Subject
> Re: Spec review comments(Document
> link: Daniel Millwood)
>
>
>
>
>
>
>
>
>
> It might be worth trying to kill it :-) Dan, would you like to write
up
> the issue for it? I think just listing out all of the various issues and
> questions raise by this thread could convince the TC that it might be
> better to just remove it.
> -Doug
>
>
>
>
> Christopher B
> Ferris/Waltham/IB
> M
To
> Doug Davis/Raleigh/IBM
> 01/12/2006 08:57
cc
> AM Daniel Millwood/UK/IBM@IBMGB,
> Matthew Lovett/UK/IBM@IBMGB, Peter
> Niblett/UK/IBM@IBMGB
>
Subject
> Re: Spec review comments(Document
> link: Doug Davis)
>
>
>
>
>
>
>
>
>
> Offer is, as I argued many a time, a premature optimization. I say nuke
it,
> but 4 may be the
> most likely course of action to be agreed by the TC.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
>
>
> Doug
> Davis/Raleigh/IBM
>
To
> 01/12/2006 08:39 Daniel Millwood/UK/IBM@IBMGB
> AM
cc
> Christopher B
> Ferris/Waltham/IBM@IBMUS, Matthew
> Lovett/UK/IBM@IBMGB, Peter
> Niblett/UK/IBM@IBMGB
>
Subject
> Re: Spec review comments(Document
> link: Christopher B Ferris)
>
>
>
>
>
>
>
>
>
> Dan,
> In that case I would assume that even though the two wsa:ReplyTo EPRs
are
> different they would both use the same sequence for their responses - so
I
> think its 'b'. This is one the problems I have with offer - it tries to
> make some kind of associations that are not really there. In this case
its
> trying to associate ALL responses with one particular sequence (the
offered
> sequence). While this may be the desired result at times, look at the
pain
> its causing you :-) I have a feeling you don't like the choice of 'b'
-
> I suspect you'd prefer that the offered sequence only be used when the
> wsa:ReplyTo matched some specific EPR (like maybe the AcksTo -
personally,
> if I were to try to make some kind of statement of matching I think it
> should be the wsa:ReplyTo of the CS and not the AcksTo - but we shouldn't
> be doing either).
> Hmmm, here's something interesting..I just checked and the spec doesn't
> actually say that offer is for replies. It says that offer is for
messages
> going from the RMD to the RMS. Since both the RMS and RMD can span
> multiple endpoints I think trying to scope the offer down to just one EPR
> would be a mistake. So then the question is "what is the RMS?" Since we
> don't require a wsa:From (and WSA might even get rid of it), can we
really
> treat the AcksTo EPR or even the wsa:ReplyTo EPR as "the EPR of the RMS"?
I
> don't think so. The AcksTo EPR might be just for RM specific messages
> (like Acks) which means no app-level messages would ever be targetted for
> it; sending just messages that targeted to it would mean the offered
> sequence would never be used. sigh
> It seems like we need to clear this up a bit. I see a couple of
options:
> 1 - add text to offer to say that it is just for replies (in the WSA
sense)
> to messages sent on the original sequence
> 2 - add text to help the RMD determine when the it is sending messages to
> the RMS
> 3 - kill offer all together
> 4 - leave it as is - ambiguous
>
> I think '1' might be a bit too restrictive but it would definately solve
> the problem.
> '2' sounds nice but it gets close to EPR comparision and since an RMS can
> span multiple endpoints how can we ever really say anything
> I like 3 or 4. Killing it removes the issue. While leaving it as is
might
> leave things vague perhaps that the best way to go since depending on how
> things are setup and implemented there are just too many options to be
more
> clear in the spec - and I do like the idea of saving a message exchange.
> If I had to vote right now I'd probably choose '4' but I'm not thrilled
> with it.
>
> thanks
> -Doug
>
>
>
>
> Daniel
> Millwood/UK/IBM@I
> BMGB
To
> Doug Davis/Raleigh/IBM@IBMUS
> 01/12/2006 06:54
cc
> AM Christopher B
> Ferris/Waltham/IBM@IBMUS, Matthew
> Lovett/UK/IBM@IBMGB, Peter
> Niblett/UK/IBM@IBMGB
>
Subject
> Re: Spec review comments(Document
> link: Doug Davis)
>
>
>
>
>
>
>
>
>
> Doug,
>
> I a bit confused by your response on offer.
>
> Lets take an example that assumes no special out of band agreements as to
> where to send WSRM protocol messages.
>
> I have two applications running in WAS, that both access a remote address
> book webservice using WSRM. The RM Source implementation uses a single
> sequence to send the messages from both applications to the webservice at
> the RM Destination. App1 sets wsa:ReplyTo of its messages to Endpoint1.
> App2 sets wsa:ReplyTo of its messages to Endpoint2.
>
> If I dont use offer, then when the addresses are returned, I would expect
> the RM Destination to use two sequences to send them:- One sequence to
> endpoint1, the second sequence to endpoint2.
> If I do use offer, then what happens? The RMD accepts an offered
sequence
> but does not know where to send the messages to. So does it
> a) not use it
> b) send both lots of messages down it assuming that as they came
down
> the same sequence, the responses can be sent down the offered sequence.
> c) something else?
>
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
> IBM WebSphere Messaging Design and Development
> MP 211
> Hursley
> Tel. Internal 248617
> Tel. External +44 1962 818617
> Email. millwood@uk.ibm.com
>
>
>
>
> Doug
> Davis/Raleigh/IBM
> @IBMUS
To
> Daniel Millwood/UK/IBM@IBMGB
> 11/01/2006 18:27
cc
> Christopher B
> Ferris/Waltham/IBM@IBMUS, Matthew
> Lovett/UK/IBM@IBMGB
>
Subject
> Re: Spec review comments(Document
> link: Daniel Millwood)
>
>
>
>
>
>
>
>
>
> Comments in this pen.
> -Doug
>
>
>
>
> Daniel
> Millwood/UK/IBM@I
> BMGB
To
> Doug Davis/Raleigh/IBM@IBMUS,
> 01/11/2006 07:49 Christopher B
> AM Ferris/Waltham/IBM@IBMUS, Matthew
> Lovett/UK/IBM@IBMGB
>
cc
>
>
Subject
> Spec review comments
>
>
>
>
>
>
>
>
>
> Having read through the latest spec level, there are a couple of things I
> wanted to discuss.
>
>
> Offer
>
> >From discussions with Matt, we thought that messages in an offered
inbound
> sequence would be sent to the AcksTo EPR of the outbound sequence. I
cant
> find in the spec where this is stated and wanted to confirm it. <dug> I
> don't believe this is true. the AcksTo EPR is just where Acks are sent -
> there is no statement in the spec that says where the offered inbound
> sequence messages (either replies or RM ops) should go - nor should it.
> Replies go to the wsa:ReplyTo of each individual message. RM messages go
> to "the right place" :-) Just like the RM spec doesn't say where the
> CreateSequence or the TerminateSequence should go for the outbound
sequence
> it shouldn't say where they should go for the reverse. </dug> Without an
> offered sequence, the CreateSequence needed to establish a sequence for
> response msg A would be sent to the ReplyTo EPR of the request msg A.
> <dug> and it won't be established (probably) until the response is
actually
> ready to be sent </dug> But with the offer, request msg A has not been
sent
> yet, so is the assumption that the sequence is only used for response
> messages that need to be targetted to the same EPR that acks will be sent
> too, or the same EPR that the initial CreateSequenceResponse message
uses?
> <dug> When the replies need to be sent (and there was no offered
sequence)
> then a CreateSequence would need to be sent to "the right place". In
most
> cases I would assume that it would be the wsa:ReplyTo EPR but this isn't
> required if there's some out of band agreement that it should go some
place
> else. If there was an offered sequence then there is no correlation that
> can be made between the offered sequence and the AcksTo EPR. The RM spec
> says that the AcksTo EPR is there for Acks - nothing else. Whether or
not
> it happens to match some other wsa:ReplyTo EPR is just a coincidence and
> should not be used to determine whether or not the offered sequence
should
> be used. </dug>
>
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
> IBM WebSphere Messaging Design and Development
> MP 211
> Hursley
> Tel. Internal 248617
> Tel. External +44 1962 818617
> Email. millwood@uk.ibm.com
>
>
>
>
>
>
>
>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]