Re: [ws-caf] addParticipant optimization

[Mark Little <mark.little@arjuna.com>]

Green, Alastair J. wrote:

>I'd like to see (some at least) of my issues A to I in a previous mail
>voted on by the TC to clarify what it is we're actually trying to
>achieve (the requirements), before reaching for a particular solution.
>  
>
I thought that those issues were strictly related to checked 
transactions? I'll certainly go back and double check.

>This proposal includes several implicit decisions about the way this
>will be approached, and I think we need to get those decisions dealt
>with explicitly. My lettered issues are designed to triage the reqs in a
>very clear way. 
>
>If we are to do this kind of optimization, I still believe that there is
>no need to allow rejection of the vector. It is not an onerous
>implementation requirement at all.
>  
>
Which vector? I thought that we would now be supporting a vector of 
addParticipant messages within the proposed wscf:addParticipants SOAP 
header element.

Mark.

>Alastair
>
>Alastair J. Green
>CEO and CTO 
>Choreology Ltd
>68 Lombard Street
>London EC3V 9LJ
>www.choreology.com
>
>+44 870 739 0050
>+44 870 739 0051 (fax)
>+44 795 841 2107 (mobile)
>
>
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: 26 July 2005 15:37
>To: ws-caf
>Subject: [ws-caf] 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