Re: [ws-caf] ACTION for optimization of registration

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

Conscious of the telecon today, I'd like to keep this rolling.

I think the original issue of optimizing registration calls should be 
orthogonal to checked transactions. As was discussed at the f2f, this 
issue is only concerned with reducing the number of cross-domain 
registration calls. With that in mind ...

>
> Actually I think that we have two different ways of approaching the 
> same problem.
>
> (i) a WS-Context context that flows back on the response; none of our 
> specifications actually restrict context flows on "outbound" messages, 
> since we're in a one-way domain, and this is conceptually appealing as 
> it continues to tie together message exchanges within the same 
> activity because the messages are all contextualised. Put it another 
> way: all one-way messages are contextualised and we are simply 
> providing another specific element within the extension capability we 
> already support, to address this. The precedent for this is the OTS 
> and various commercial implementations.
>
> (ii) a "boxcar" (a la BTP) of enlistment messages that accompany the 
> one-way "response" message. The precedent for this is BTP.
>
> Now it seems to me that (ii) could be dealt with by the underlying 
> SOAP infrastructure - that's always been the argument against putting 
> boxcarring into the protocol. Whereas (i) is a specific approach for a 
> very specific problem.
>
> Pros and cons both ways.

We have to make a choice. Fairly obviously, there's an implied (iii) in 
the above, which is "do nothing", i.e., drop the issue. Assuming we 
don't want to go that route just yet (afterall, we're still in the 
discussion phase), let's return to the original text which I had the AI 
for generating:

"A service that receives a transaction context on an application 
request  SHOULD enlist participants with the corresponding activity 
group. The transaction service implementation associated with the 
service MAY decide to use the following protocol to optimize remote 
registration invocations: this optimization MAY occur transparently to 
the service. Rather than register participants directly, the EPRs of the 
participants (and the protocols they should be enlisted with) are 
retained by the service-side transaction service component until the 
response to the original invocation is sent; in which case a context 
containing these EPRs and associated data is propagated back with the 
response.

If a receiver of a response obtains this context it MUST either be able 
to perform the enlistment itself or, if it does not support this 
optimization, send back a wsacid:CannotOptimizeEnlistment fault code 
message and mark the transaction so that its only outcome is to 
rollback. If enlistment fails then the transaction MUST be rolled back; 
an implementation MAY retry transient registration failures.
 
If the sender of the response receives an indication that there was a 
non-recoverable failure (e.g., in delivery of the message or 
registration of the participant EPRs) then it MUST rollback the work it 
has performed in the scope of that transaction. When using this 
optimization, the service MUST still see a wscf:participantAdded message 
in order to be compliant with WS-CF. However, this message SHOULD be 
generated by the service-side transaction component for this 
optimization to work."

This all presupposes something along the lines of (i) above. I'm going 
to continue to recommend that approach because I think general 
boxcarring as outlined in (ii) is something that the runtime 
infrastructure will take care of. However, that still leaves open the 
issue of what is meant by "context" in the provided text. Is is a) a 
WS-Context as I original indicated, or is it b) the specific 
addParticipant messages, i.e., a very specific form of boxcarring for 
this very specific problem? As I've already said, I prefer the 
conceptual model of contextualising all of the one-way messages, so a) 
probably edges out b) for me, but at the moment I can't think of any 
technical reasons for one over the other. I think how the information is 
conveyed is less important than agreeing to convey that information in 
the first place.

Mark.

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com