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

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

+1

I definitely believe that the text belongs in CF.

Mark.


Greg Pavlik wrote:

> Mark Little wrote:
>
>> 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 ...
>>
> yes, I agree. This has been the one problem point in the discussion so 
> far. To clarify my early statement on WS-CF: I'm in favor of 
> optimizing registration at that level but not in adding any additional 
> semantic implications: my view is that CF  provides the building 
> blocks for organizing the participant graph but nothing more.
>
>>>
>>> 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)