[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: addParticipant optimization
In order to try to move this forward, here's another go at some proposed text for optimizing the addParticipant messages. This has been repositioned to be within WS-CF, rather than WS-ACID. I'd like to get to the point where we could have some concerete proposal for vote at the telecon on Monday. "A service that receives a WS-CF context on an application request SHOULD enlist participants with the corresponding activity group if the operation execution semantic for the activity requires enlistment. The Referencing Specification or implementation MAY decide to use the following protocol to optimize remote registration invocations. Rather than register participants directly, the wscf:addParticipants messages MAY be delayed and retained by the Registering Service until the response to the original invocation is sent; in which case a wscf:AddParticipants SOAP header element, which contains the individual wscf:addParticipants messages is propagated back with the response. [Editor's note: this element MUST have SOAP:mustUnderstand defined to be true.] If a receiver of a response obtains this SOAP header it MUST be able to perform the enlistments or, if it does not support this optimization, send back a wscf:CannotOptimizeEnlistment fault code message. In the case of failures (e.g., delivery failure of the application response), it is up to Referencing Specifications as to the appropriate action to take, e.g., in the case of an ACID transaction implementation, any associated transaction MUST be forced to roll back. An implementation MAY retry transient registration failures. When using this optimization, the Registering Service MUST still see a wscf:participantAdded message in order to be compliant with WS-CF. How that message is produced is up to the Referencing Specification or implementation. For example, when used in conjunction with ACID transactions, an implementation MAY require this to be tied into the notion of checked transaction semantics." Mark. -- Mark Little Chief Architect Arjuna Technologies Ltd www.arjuna.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]