RE: [ws-rx-implement] Notes from todays WS-RM interop call

["Patil, Sanjay" <sanjay.patil@sap.com>]

Agree. I don't see us fully prepared to discuss and resolve these issues
on the call today. However, if time permits, we should at least discuss
--
A> High level approach for addressing the anonymous R/R situation. Is
this a main-stream use case that justifies a fully fleshed out support
in the specification (which may mean lots of changes to the specs)? Or
is it enough to leave the spec open for compliant implementations to
also support anonymous R/R (status quo)?
B> Is support for Offer *required* for anonymous R/R scenarios.
Basically, can we deal with issues i089 and i90 independent of each
other?

-- Sanjay

> -----Original Message-----
> From: Daniel Millwood [mailto:MILLWOOD@uk.ibm.com] 
> Sent: Thursday, Feb 16, 2006 8:52 AM
> To: ws-rx-implement@lists.oasis-open.org
> Cc: wsrx
> Subject: [ws-rx-implement] Notes from todays WS-RM interop call 
> 
> 
> 
> 
> 
> 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
> 
>