[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]