Notes from todays WS-RM interop call

[Daniel Millwood <MILLWOOD@uk.ibm.com>]

Sanjay,

On todays interop call, a lot of the discussion centred around a new
proposed scenario for 2-way synchronous WS-RM proposed by MSFT.  This
raised a number of questions which need to be worked through and the
results could impact some of the issues up for discussion on tonights call,
such as issue i090.  We feel that resolution of these impacted issues
should be deferred until the questions have been worked through, so we
could either move them from tonights call, or discuss the issues without
resolving them.

I took the following notes from the call.  Marc Goodner has taken the
action to send the new scenario to the main list to aid discussion.

Paul F:  Main aim is to make sure scenarios doc is at a state that we can
all go ahead and implement for interop in March.  There are some open
issues around synchronous case.
Doug D : Do we need to update doc to include TerminateSequenceResponse and
update to CloseSequence?
Marc Gr.  yes if we can get a working draft.  interop doc should be to a
particular working draft or cd.  hopefully that doc will have a new
namespace
Doug D:  talk about new scenario added to the doc.  like to understand how
the TerminateSequence is supposed to work now we have a
TerminateSequenceResponse
Marc G.  MSFT will have to look at that
Doug D: Other concern is that client is going to be expected to resend
messages it may have already received acks for.  Very important that that
type of stuff is stated in the spec.
Marc G, are you saying thats true at RMS or RMD?
Doug D: Definitely at RMS,  once responding RMS receives acknowledgement
that its response gets there can it remove the message?  What happens if
the replayed request comes in again
Ondrej :  RMD can forget about reply once its got an ACK.  If it gets the
request again something else could be returned.
Doug D Think that needs to be stated at least in the scenarios doc and
preferably in the spec.  Changes semantics for implementing RM in that one
scenario
Sumit :   If we send a response back its not really the response the client
expects anymore.  The client could be trying to deserialze the message and
if its not the right one it could cause an error.
Ondrej :- It could send an http 202 back
Doug D: Is it wrong for someone to have 2 sockets open both sending same
request
Ondrej - thats up to the implementation.
Doug D: If you have more than one connection open you never know which will
get back if one has real response and one has 202, how do you know which to
use?
Ondrej:  The response will always be the real response as long as the RMS
hasnt acked it.  Once the RMS has acked it, it wouldnt look at any more
responses for the message.  It would just ignore it.
Paul F:  A 202 is better than a fault
Doug D.  Could some of these details be spelled out in more detail.  Also
how this might work with the CloseSequence message exchange.  Think this
might work if close is initiated from the client side, but not sure about
the server side.
Ondrej.  We can address those.
Paul F:   If we're going to have these scenarios in we need to raise some
issues against the main spec.  Lot of assumptions that arent spelled out.
Concerned about that from an interop point of view.
Doug D: First step is to write down the questions & possible answers and
work through solutions
Marc G:  I agree thats the right way to go
Doug D.  Can we defer resolution of issues like 90
Marc G  That makes sense.  MSFT will write up.

Action:  Marc Goodner will send 2-way synchronous scenario to main list
Action: Marc Goodner will update interop doc with new scenario.
Action: Marc Goodner will later update interop doc with
TerminateSequenceResponse and other changes such as the change to Close.

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