[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] [NEW ISSUE] Use of offered sequences unclear in current spec
I think there's ambiguity around the endpoint that an RMD should use for
RM protocol messages other than the CreateSequenceResponse.
Putting it as a question, what precisely is the scope of the endpoint
specified in the <wsa:ReplyTo> of the original CreateSequence message
sent by the RMS?
Under my reading of WS-Addressing, the wsa:ReplyTo is intended only as
the endpoint for the response message of the SOAP request/response MEP
(the CreateSequenceResponse in this case), not also as the endpoint for
an arbitrary set of "related" messages.
By related messages in this context, I'm referring to other RM protocol
messages that flow from RMD to RMS, e.g.:
- outbound CreateSequence if the original inbound CreateSequence doesn't
contain an offer, and the RMD needs a new sequence for application
response messages
- even if the original CreateSequence did contain an offer, and this is
accepted by the RMD, a TerminateSequence message for the outbound
sequence will need to be eventually sent by the RMD
It seems to me that of the two addresses specified in the CreateSequence
message (wsa:ReplyTo and wsrm:AcksTo), assuming these are different and
both non-anonymous, it's only the AcksTo that should be assumed to be
long-lived. Obviously an non-anonymous AcksTo endpoint must have
lifecycle comparable to that of the sequence, as it must be capable of
receiving ACKs throughout. The ReplyTo endpoint on the other hand, may
only exist for the extent of the CS/CSR request/response MEP and
thereafter the underlying transport resource (e.g. HTTP listener, JMS
destination etc.) may be released or put to some other use.
The reason this is a concern is that a client transport could be
designed to create client-side endpoints on demand, and to associate
these explicitly with a single request/response MEP. These lightweight
endpoints would obviously need simpler lifecycle management, e.g. they
could be pooled transiently, but wouldn't necessarily need to be
reconstituted after a client application crash & restart. The AcksTo
endpoint on the other hand would need be managed differently by such a
transport, specifically to exist for at least the lifetime of the RM
sequence, potentially encompassing client restarts.
There's also the question of where non-ACK RM protocol messages may be
sent by the RMD if the RMS specifies different ReplyTos in the
application messages within a single sequence. May the RMD send for
example to TerminateSequence to any of the ReplyTos specified by the RMS
within the sequence or just the ReplyTo specified in the original
CreateSequence?
In the mail trail of the internal IBM discussion on this subject, the
argument is made that since the RMS just sends the original
CreateSequence to "the right place" (i.e. the server-side endpoint that
it will be invoking on), then the RMD should also just send non-ACK
protocol messages to the "right place" (i.e. the client-side endpoint
specified in the CreateSequence ReplyTo). However I'd argue that from a
transport lifecycle management point of view, the cases are not
symmetric. The server-side endpoint must be long-lived as it forms part
of the Service contract. However there's no such implication that
client-side endpoint specified in the ReplyTo is part of contract that
persists after the initial request/response MEP is complete.
So my view would be to take a broad interpretation of AcksTo, as the
endpoint for all destination->source RM protocol messages (i.e.
SequenceAcknowledgement for the inbound sequence, CreateSequence,
TerminateSequence for the corresponding outbound sequence etc.)
Comments?
Regards,
Eoghan Glynn
Principal Engineer, IONA Technologies.
-----Original Message-----
From: Daniel Millwood [mailto:MILLWOOD@uk.ibm.com]
Sent: 16 January 2006 15:05
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] [NEW ISSUE] Use of offered sequences unclear in current
spec
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]