OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-caf] addParticipant optimization


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.

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.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]