ws-rx message
[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
- From: Matthew Lovett <MLOVETT@uk.ibm.com>
- To: Paul Fremantle <paul@wso2.com>
- Date: Tue, 24 Jan 2006 14:23:32 +0000
Hi Paul,
I'm not sure that I agree with all of
your reasoning. You said:
"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."
Here, you seem to be stating that A
is aware of the sequence, and that B is not. What if the messages were
assigned to the sequence in the other order? (Perfectly possible given
Dan's original scenario.) I assume you would then state that B was aware
of the sequence, and A is not. That's a bit of a contradiction.
I see 3 useful ways out:
a) State that both A and B are aware
of the sequence, in which case you don't need to establish new Sequences,
though you are free to if you choose. To aid interop we should say something
like "When using a wsa:replyTo for application messages assigned to
a Sequence, the RMD accessible at the replyTo endpoint MUST be aware of
any Offered sequence". I don't like that much, and perhaps a SHOULD
works better than a MUST, but equally, it damages interoperation. We seem
to be making the RM layer care about the interaction pattern (e.g. WS-Addressing
options) more than it has to. Yuck!
b) Assume that neither A or B are aware
of the sequence, which reduces the applicability of Offered sequences to
the anonymous replyTo.
c) Leave the spec as is, or possibly
add prose to warn implementations that there is more than one interpretation
here and give some guidance. With or without new text, the interop scenarios
that we are building then become a de facto standard.
Talking to Dan's original issue, I agree
that there are different interpretations of the current spec, and that
some clarification would aid interop. At the same time, I really don't
want to start getting into meta-issues about message exchange patterns,
or documenting the expected composition of WS-A and WS-RM.
Matt
| Paul Fremantle <paul@wso2.com>
23/01/2006 16:10
|
|
To
| 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.
>
> Sequence Expiry
>
> I dont like the fact that expiry could cause a sequence to end without
both
> the RMS and RMD knowing the state of the sequence. If the RMD
expires a
> sequence before the RMS, then the RMS cant always know the final sequence
> state. The RMS cant always proactively close the sequence, as
there could
> be a network failure stopping them communicating. Id prefer
the spec
> without expires in it.. I can see why messages might have a
lifetime, but
> not the transport. (I realise we can always use PT0S and that
was the
> proposal in the current SDD - not exposing expiry at all).
> <dug> this is a good point but I'm at a loss at how we can fix
it. Even if
> we say that when a sequence expires what it really means is that its
just
> Closed so that the RMS can still ask for the ack state - how long
should it
> remain like that? seems like we still have the same problem
that at some
> point the RMD will need to forget about the sequence and at that point
the
> RMS is stuck. </dug>
>
> 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>
>
> Secure Conversation
>
> Whats happening with this missing token? We need a fix to this
and it
> could provoke a lot of discussion so its probably best to address
it soon.
> <dug> I think my proposal to remove the optionality of extensions
should
> fix this </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]