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

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

Greg Pavlik wrote:

> I'm concerned that we're radically overgeneralizing the discussion.
>
> 1) Alastair, do you agree that we can deal with enlistment independent 
> of checking, ie, without implied graph completion semantics at the CF 
> level? If there's a consensus on that, I'd like us to move forward 
> there so we can close down that issue.

You know my opinion on this question.

>
> 2) Independent of 1), is there a general consensus that checking is 
> something that should be tackled independent of a particular protocol 
> semantic?

I think checking has its place and we COULD support it. However, all 
implementations I know of, and specifications, allow for it to be 
disabled (obviously that tends not to be the default out-of-the-box 
behaviour though).

>
> I have some concerns about this latter point. "Acid" systems do in 
> fact tend to conform to a set of historical constraints, eg 
> assumptions embedded in DTP. My main concern with the acid protocol is 
> that it provide a basis for interoperability with existing systems: I 
> do not think anyone will see it as a general mechanism for "web 
> transactions." From that perspective, I don't have a problem with a 
> simplistic checking solution that are consistent with how things have 
> been done in the past *for the acid protocol*, especially if its known 
> to work well with deployed tp technology.

+1

Mark.

>
> Greg
>
> Green, Alastair J. wrote:
>
>> I don't understand a number of Mark's arguments here.
>>
>>  
>>
>>>> (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.
>>>>     
>>>
>>
>> 1. A context that flows back on a response is not an OTS concept. There
>> is no such concept in OTS. This is a BTP concept, called "context
>> reply". In OTS there is assumed to be application message pairing,
>> equivalent to return of a function call in X/Open DTP's modelling
>> mindset. OTS wrongly applies the X/Open synchronous model to the
>> distributed checking problem.
>>
>> 2. OTS has a concept of "reply checking". This states that one must
>> count back the application responses that match each application
>> request. This is crude and excessive.
>> OTS states that checking in a distributed tree is tantamount to ensuring
>> that all transactional work of all leaf nodes has been completed.
>> In fact:
>> a) an application response may be the first or nth of a conversational
>> stream, and its arrival cannot be construed as equalling completion of
>> anything other than its role in the application's own protocol;
>> b) the danger of unchecked behaviour arises, not from attempting confirm
>> processing until all transaction work has been accomplished, but from
>> attempting confirmation before all participants are enrolled.
>> A one-way message-based transaction completion protocol can begin to
>> pass two-phase requests downtree long before all leaf node work is
>> completed. The key point is that, while a PREPARE downtree may stall
>> waiting for a PREPARED (wait for work to complete), we must not send
>> PREPARE to only some of the required participants. If we do then we risk
>> leaving them in a solitary state of preparedness (a state from which
>> they can never escape short of a brutal backstop timeout on their
>> attempts to retry obtaining a second-phase instruction). The terminator
>> application should be able to leave transaction completion to occur
>> without regard to its own lifecycle.
>>
>> 3. BTP correctly addresses these two problems a) and b). It introduces a
>> signal that means: "all enrolments stemming from an application message
>> have been processed". This signal is a BTP message CONTEXT-REPLY. It can
>> be sent independently of application responses or as part of an
>> application response message (as a header element). This signal
>> logically terminates the stream of 0..n ENROL signals that may arise as
>> a result of a service receiving an inbound CONTEXT message:
>>
>> CONTEXT
>> ENROL/ENROLLED
>> ENROL/ENROLLED ...
>> CONTEXT-REPLY
>>
>> This sequence could be thought of as the "checking sub protocol".
>>
>> (This is a simplification: the reply can be used to communicate failure
>> of required enrolments, and there can be a stream of context replies to
>> indicate to the app that it's in business, but that the protocol level
>> checking hasn't been completed.)
>>
>> 4. The point I have been trying to get across in the last week or so is
>> that the need satisfied by CONTEXT-REPLY is separate from the issue of
>> "boxcarring".
>> BTP has all kinds of (useful) network traffic optimizations. It can
>> concatenate any number of protocol messages together in a wrapper
>> element holding BTP messages ("bundling"). And it can also "group"
>> messages to create compound semantics (e.g. CONTEXT-REPLY & ENROL &
>> PREPARED).
>> Mark says:
>>
>>  
>>
>>>> (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.
>>>>     
>>>
>>
>> Mark then goes on to explain that his approach i) -- so sedulously
>> distinguished from BTP -- is in fact to have a bunch of enlistment
>> messages that accompany a one-way response message called ... a response
>> context, which sounds awfully like approach ii).
>>
>> Without vectorization we cannot group the context reply ("checked") with
>> the enlistments or registrations that must succeed to achieve the
>> checked state. The checked message has no magical power on its own to
>> achieve vectorization.
>>
>> 5. Mark is right to say there are two ways of achieving vectorization:
>> by relying on the infrastructure, and by doing it yourself. I have to
>> smile when I read that the SOAP infrastructure will do it for us. I have
>> been hearing this for four years. In what decade, and through which
>> well-known protocol nearing maturity within the WS architecture will
>> this occur?
>> In BTP we did three wise things as a TC on this kind of question --
>> refused to reference incomplete specs, defined all the facilities we
>> needed abstractly, and defined a "today's technology" binding that
>> concretely expressed them -- while defining how a "tomorrow's
>> technology" binding might be created when the time came. The abstract
>> EPR/WS-A issue. Are these WS-CAF specs to be capable of implementation
>> this or next year? If so then I suggest we need to define how boxcarring
>> is going to be done, or drop the attempt to support it altogether.
>> 6. Which brings me back to Mark's proposed text. Boxcarring is achieved
>> by stating that the context will contain enlistments as extension
>> elements. Mark comments:
>>
>>  
>>
>>> This all presupposes something along the lines of (i) above. [AG:
>>>   
>>
>> having a context reply by using an extended context]  
>>
>>> I'm going to continue to recommend that approach because I think
>>>   
>>
>> general  
>>
>>> boxcarring as outlined in (ii) [BTP boxcarring in a context reply] 
>>> 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.
>>>   
>>
>>
>> I summarize this as:
>>
>> Approach i) [Nothing to do with OTS, original Mark proposed text]
>>
>> = have a context response and put a number of enlistment elements within
>> it.
>>
>> Approach ii) [BTP]
>> = put a number of enlistment elements within a wrapper, and then
>> optionally carry that freestanding or grouped with a context reply.
>>
>> Approach iii) [Mark musing on an alternative]
>>
>> = "have addParticipant (enlistments) messages in a vector".
>> On iii) How, where? As free-standing header elements (which implies they
>> must run alongside application messages (which is not required)? As
>> children of an element specifically for bundling WS-CAF protocol
>> messages -- exactly what <btp:messages/> does in BTP? This would allow
>> transmission alone or piggybacked as a header element on an app message.
>> This leads to a wrapper, and thence straight to approach ii), as in BTP.
>> I think it would be brain-bending to use the context itself as such a
>> wrapper, but someone might come up with that suggestion.
>>
>> [Incidentally I cannot see why one would restrain oneself from using the
>> technique in i) as a technique for *any* bundle of messages. And I also
>> cannot see why you would hold back from allowing a wrapper to contain
>> anything CAFish.]
>>
>> I simply do not understand what "contextualizing all the one-way
>> messages" has to do with this. The one-way messages of the application
>> must *all* be contextualized, even if they have no need? What if the
>> protocol semantics have nothing to do with app messages and are
>> out-of-band to the app? The one-way messages of the protocol(s) must all
>> be contextualized? What would that mean?  
>> 7. WS-CF and transactions: how do they interrelate in this area?
>>
>> Finally, to pull it all together -- WS-CF needs boxcarring to allow
>> vectorized tree-building or graph-painting. WS-TXM (and it won't just be
>> WS-Acid, which raises the need for a general TXM level protocol), needs
>> to have a way of saying "checked, enrolments done".
>> They may or may not be combined in a single message, but they are
>> semantically distinct.
>> If they are combined then they need a bucket to travel in together. An
>> augmented context can be used as the bucket. It needs to have an
>> extension element for checked that belongs to WS-TXM (and undefined
>> message in the current spec). It needs to be able to contain multiple
>> addParticipants for WS-CF.
>> But a context is not usually thought of as a body element, and it is
>> unclear why context is being used just as a bucket, aka a wrapper. And
>> it is unclear why the checked message should have to travel with an app
>> message, as a header etc. And it is unclear why addParticipants should
>> have to travel in something called a context to achieve multiple
>> registrations in one go.
>> This points to a WS-CAF bucket for multiple messages, that can be used
>> as a header element, as a body element, as an extension element of
>> context if need be etc. This is what BTP does. It works. It addresses
>> all use-cases.
>>
>> 8. Checking can also be achieved by counting of identified enrolled
>> inferiors. This can be dealt with separately, but it should not be
>> forgotten. It is a WS-TXM-general need, not specific to WS-Acid.
>> * * *
>>
>> This entire discussion begs the question: why are we trying to reinvent
>> the wheel of BTP in these areas? I venture to suggest that the same
>> unavoidable question will plague most other discussions as we proceed
>> with WS-TXM. This is exactly what I meant by "needless variation".
>> We would perhaps do ourselves and the wider audience a favour if we
>> frankly set out to copy BTP as faithfully and as literally as makes
>> sense given the layering of WS-Context and WS-CF. That way we would end
>> up with a workable and proven solution of equal power, in a short space
>> of time, on this issue, and on many others.
>> 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: Greg Pavlik [mailto:greg.pavlik@oracle.com] Sent: 19 July 2005 
>> 18:44
>> To: Mark Little
>> Cc: ws-caf
>> Subject: Re: [ws-caf] ACTION for optimization of registration
>>
>> 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.
>>>>
>>>>
>>>>
>>>> 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."
>>>
>>>
>>> Mark.
>>>
>>>   
>>
>>
>>
>>  
>>
>

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