ws-rx message
[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
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Fri, 20 Jan 2006 18:40:41 -0500
Eoghan,
I purposely said "the right place"
because I don't like the idea
of using either replyTo or acksTo - nor do I think
that the spec
should choose one. If we examine the initial
CS there is nothing
in the RM spec at all that says where this message
should go. The
RMS just knows "the right place" - it might
be the same EPR as the
AD or it could be some RM manager - we don't know.
I think the
response sequence should be handled the same way -
the RMD should
send any possible CS to "the right place".
It might be the replyTo
from one of the requests, it might be the AcksTo EPR
- we don't
know.
You're statement about the replyTo being short-lived
w.r.t. the
entire sequence (or sequences) is true. However,
the same could
be said about the acksTo EPR - it could live just
for the duration
of the original sequence - once the sequence goes
away so could
the AcksTo EPR. This would mean that the response
sequence could
not use this EPR any more for CS, Close or Terminate.
Remember, the
response sequence could be totally out of sync with
the request one.
It might live quite a bit longer (in most cases it
should since the
responses will be delivered after the requests) and
in some extreme
cases its possible that the response sequence might
not even be
created until after the request sequence is terminated.
This all gets to my general complaint about
offer - it hints at trying
to make some kind of correlation between the request
and response
sequences that the RM spec just does not make. And
by doing so it
leads to all of these questions (valid questions when
those hints
are there) but the RM spec can not offer any answers,
so IMO its
better to remove this confusion by removing offer
all together.
thanks,
-Doug
ps. in the attached note I had to choose between acksTo
and replyTo,
and I chose replyTo for the response sequence CS because
as I
stated above the acksTo EPR could go away before the
response
is sent but the replyTo EPR would need to live at
least long
enough to get the reply, so sending the CS to this
EPR should
always work. Of course, sending a Close or Terminate
to that
EPR might not work but I'd probably choose to send
those to the
last replyTo EPR received since that one might have
the best
chance of still being alive. But this is all
just speculation
and my own opinion and shows, yet again, why offer
is just
a trouble-maker. :-)
"Glynn, Eoghan" <eoghan.glynn@iona.com>
wrote on 01/20/2006 04:27:31 PM:
>
>
> 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]