5 messages in org.oasis-open.lists.ws-cafRe: [ws-caf] addParticipant optimization| From | Sent On | Attachments |
|---|---|---|
| Green, Alastair J. | Jul 26, 2005 9:30 am | |
| Mark Little | Jul 27, 2005 2:26 am | |
| Green, Alastair J. | Jul 27, 2005 5:14 am | |
| Mark Little | Jul 27, 2005 5:51 am | |
| Newcomer, Eric | Aug 1, 2005 7:36 am |
| Subject: | Re: [ws-caf] addParticipant optimization | |
|---|---|---|
| From: | Mark Little (mark...@arjuna.com) | |
| Date: | Jul 27, 2005 5:51:24 am | |
| List: | org.oasis-open.lists.ws-caf | |
Green, Alastair J. wrote:
I think you'll find that the issues I put forward did relate to both aspects of the current e-mail discussions. The idea was to clarify what the required/desired features actually are, and whether they have any interrelationship, in order to focus the subsequent work on solutions.
OK, like I said I'll take another look.
If I understood your proposal correctly, there was a new message AddParticipants which was a vector of addParticipants?
No. There is a SOAP header element wscf:AddParticipants that contains a vector of the wscf:addParticipant message(s). This flows back in the response.
There is also provision for rejection on grounds of inability to process the optimization, which I take to be the vector.
Yes, that's right.
My point was (irrespective of the details, final proposal shape etc)
a) that the optimization is to send a vector, and
b) why bother to let implementers choose not to process the optimization, it's only a matter of processing a sequence of messages/elements, instead of one, each with the same impact in processing terms. Looping not a big deal. Optional features always trouble.
Because:
a) it requires the implementer to take notice of the reverse context and be able to handle wscf elements within it (something which they may not want to do or be capable of doing - take the simple case of a response handler that is deep within a tree of nodes and the actual coordinator is much higher up in that tree; direct addition of participants by the optimizing node would obviously ignore the node in which the response handler rides and go direct to the coordinator; by enforcing the optimization on both ends, we now require that the response handler must be functionally capable enough to handle registrations of participants).
and
b) it's trivial to handle the optionality.
Maybe we could consider adding a policy to enable the optimizing node to determine whether or not it is worth trying the optimization?
Mark.
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...@arjuna.com] Sent: 27 July 2005 10:27 To: Green, Alastair J. Cc: ws-caf Subject: Re: [ws-caf] addParticipant optimization
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...@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