[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
Ian Robinson wrote: > > >Regarding WS-RM, the "scope of work" section of the charter states: > >"As general principles, these protocols ... must not depend on the >availability of reliable message delivery mechanisms outside of these >specifications." > > +1 > > >This issue proposes a change to the semantic of the Register request but I >believe that none is needed. Retrying a Register request because of network >failures is not the only scenario in which a Participant can be registered >multiple times for the same transaction. The important consideration is >whether or not the multiple participant instances will behave properly when >they are directed to complete according to the specific agreement protocol >(e.g. AT or BA). And the state tables ensure that they can. > > > >If the TC believes clarification is required then I would suggest the >following text: > >A Coordinator is not required to detect duplicate Register messages, but >MAY attempt to do so by means that are out of the scope of this >specifiction. A registration requester MAY send multiple Register messages >to a Coordinator that does not detect duplicates - for example because it >retried a Register request following a lost RegisterResponse. If a >registration requester registers multiple times for the same activity then >the registered Participants MUST be prepared to handle multiple protocol >messages from a Coordinator that treats the multiple Register requests as >distinct Participants. There are a number of simple strategies for >accomplishing this. For example, the registration requester can generate a >unique ReferenceParameter for each Participant EPR that is passed in a >Register request. > > I would agree with this under the following assumption (or maybe clarifications are needed): I assume you're implicitly talking about removing the fault on multiple participant registrations? Mark. > >Regards, >Ian Robinson >STSM, WebSphere Messaging and Transactions Architect >IBM Hursley Lab, UK >ian_robinson@uk.ibm.com > > > > Alastair Green > <alastair.green@c > horeology.com> To > Doug Davis <dug@us.ibm.com> > 13/12/2005 17:19 cc > ws-tx@lists.oasis-open.org > Subject > Re: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse retriable > > > > > > > > > > >+1. > >Either we do it at the coord protocol level, or we start to mandate >something like WS-RM, which I would not favour, and would create some >pretty major ripple effects in specs and implementations. > >Alastair > >Doug Davis wrote: > > And what is that transport mechanism? By default neither WSA nor > SOAP will do > retries. > -Doug > > > > Kevin Conner > <Kevin.Conner@jboss.co > m> > To > Doug Davis/Raleigh/IBM@IBMUS > 12/13/2005 04:31 AM cc > Christopher B > Ferris/Waltham/IBM@IBMUS, Mark Little > <mark.little@arjuna.com>, > ws-tx@lists.oasis-open.org > Subject > Re: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse retriable > > > > > > > > > > > > > Doug Davis wrote: > > One thing that concerns me about using the wsa:MessagID is the > assumption > > that you'll use the same messageID on each retry. Can the Tx spec > really > > require this? Other specs (like WSA) which are infrastructural can > > > probably make > > this kind of requirement (if they need to), but I always viewed Tx > as > > sitting on top > > of these infrastructural layers and not so much as being part of > them. > > Implementations > > will vary on this view but I wouldn't think Tx would want to > mandate this > > kind of choice. > > thanks, > > -Doug > > This really came out of the description of the original problem. A > request/response conversations was initiated and the initiator > crashed > before receiving the response. The replay of a message at this > level, > especially as we are using WS-Addressing, would surely become the > domain > of a reliable transport. My suggestion was therefore to defer this > to > the transport mechanism to replay the conversations and not the > higher > level protocols. > > Kev > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]