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

[Greg Pavlik <greg.pavlik@oracle.com>]

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.
>