RE: [business-transaction] RE: [business-transaction-comment] Public Comment

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

>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>The Mark-and-Peter thread - hope everyone did get Mark's reply to me.

Yes, maybe we should change the title ;-)

>
>> -----Original Message-----
>> From: Mark Little [mailto:mark.little@arjuna.com]
>> Sent: 07 November 2003 11:05
>> To: Furniss, Peter; business-transaction@lists.oasis-open.org
>> Cc: Newcomer, Eric; Lublinsky,Boris S.
>> Subject: Re: [business-transaction-comment] Public Comment
>>
>>
>> > The general approach, of small core and extra features as
>> needed, is
>> > appropriate, but the application of the principle to the problem is
>> > completely wrong.
>> >
>> > What we are all seeking is a protocol (or protocols) - a set of
>> > messages with defined semantics - for communicating
>> transactionality
>> > between fairly loosely-coupled systems using webservices.  Applying
>> > the micro-kernel paradigm means we should be looking to
>> abstract the
>> > variations in the semantics in different use cases to their
>> > fundamentals, and have a protocol that transmits the fundamentals.
>> > Don't even think of implementation or engines yet; just define what
>> > the messages must mean, assuming no greater knowledge of
>> the internal
>> > behaviour of the opposite end than is mandated by the use of the
>> > protocol.
>>
>> Factoring where factoring makes sense is always a good idea.
>> However, just because two protocols have messages that have
>> the same name doesn't mean that they can be factored!
>
>Same name ? The portfolio approach gives different names to messages
>that turn out to have effectively the same meaning. We want to factorise
>on semantics, then choose the name.

But the fact is that they *don't* have the same semantics. Forward 
compensation and backward compensation are different things and have different 
guarantees. If I use an XAResource then I know that when I tell it to 
rollback, the work will be undone when rollback returns. If I use a 
compensation resource with a compensation transaction (e.g., Sagas) then the 
guarantees are different and could result in cascade-abort, which could take 
hours, days, weeks (or never) to complete. From a service composition 
approach, I want to know what those guarantees are when I create my 
application because it'll affect what I can do. Just because somethings called 
"cancel" and you map it to "rollback" and "compensate" at a higher level 
doesn't let me see that the side-effects are different. And this isn't even 
getting into the discussion about isolation, durability etc. which come into 
play when you look at interoperability between TP implementations.

>
>> > We should, in the first instance, further limit the scope
>> to the true
>> > inter-party exchanges - what btp calls the outcome protocol, but
>> > including the propagation and registration mechanisms. The control
>> > mechanisms, by which an entity creates a transaction and
>> controls its
>> > lifecycle, are secondary - they will frequently be more "intimate"
>> > than the outcome protocol (in-process api v inter-process messages;
>> > intra-company transaction server v inter-company b2b
>> exchanges), and
>> > the control mechanism is meaningless without a standardised outcome
>> > protocol, but not vice versa.
>> >
>> > But WS-CAF/TXM, and to a lesser extent, WS-C/Tx apply the
>> micro-kernel
>> > approach to the engine that supports the control mechanism (which
>> > doesn't need to follow a service-oriented
>> > architecture)
>>
>> Why do you say this doesn't need to be SOA based? We're
>> working in a Web services environment for a start. I know
>> well the argument that BTP isn't just Web services based, but
>> in the world of Web services transactions that's not an
>> argument at all.
>
>I should have emphasized the word "need". How the application
>software communicates with its immediate ws transaction support doesn't
>*have* to be WS - one could use the JTA interface or something based
>on it, for example. Of course, defining the control interactions in
>wsdl makes it easier to have a separate hub-style coordination
>service, but that's not an essential for getting coordination
>between application services.  Whereas the outcome protocol *does*
>have to be web-services (otherwise it would just be TIP)

OK, I understand your original point now. WS-CF/TXM build on Context, which 
affects the interaction style, though it's not mandated.

>
>> > and forces the inter-party exchanges (which are
>> > definitely SOA) to be rich and varied.
>> >
>> > Given a common outcome protocol, with the fundamental
>> promise/decision
>> > (two-phase) pattern, the separate parties do not need to agree
>> > beforehand which kind of transaction they are involved in this time.
>>
>> That's not true. It may be the case with the people you're
>> talking to, but certainly for the users of the other
>> specifications that isn't the case. Services want to know
>> precisely what kind of transaction they are involved in, what
>> the semantics associated with it are and (at some stage)
>> whether they can actually be involved in that transaction.
>
>This really is the crux of the matter - how often do the services
>in a transaction *really* need to know what is going on elsewhere ?

That may be the crux of some problem, but it's not what I meant in the above 
paragraph! Basically it comes back to the different guarantees that each 
extended transaction model (and I class ACID transactions as just a model on 
this sliding spectrum) provides. Each protocol makes different assumptions 
(rules) about the characteristics services/participants have in terms of 
atomicity, isolation etc. and those services/participants must obey those 
rules.

>How will it affect their internal behaviour ?

Well, like I said, if we just take ACID semantics then I'd like 
serializability from my services for a start, which is something not all 
models require. It wouldn't be good practice for me to glue together my 
application from some services that did provide serializability and some that 
didn't.

> How would differences
>in the internal mechanism affect the rest of the transaction ?  If we
>are
>service-oriented, or even just trying to keep the different elements of
>an application appropriately separated, it is only the service
>behaviour that is of interest.

I'm not sure if we are in conflict here, but I'll assume we are ;-)

How the service behaves is mandated by the transaction model is participates 
within. The overall behaviour of the service with respect to the transaction 
is a combination of the business logic embedded in that service and the 
participant(s) that interacts with the transaction.

> Within a service, one needs to decide
>how *different* transactions affect each other (or how to stop them
>doing
>so), but what does it actually need to know about each, except when
>two bits of the same transaction come into the same service, and what
>the
>timescales are.
>
>An excellent statement of service-orientation as it applies to these
>protocols is
>found in the short statement on WS-AtomicTransaction in the paper
>"Secure, Reliable,
> Transacted Web Services: Architecture and Composition" from IBM and
>Microsoft
>(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebs
>rv/html/wsOverView.asp among other places)
>
>Section 3.7.2 of that is:
>
>WS-AtomicTransaction defines a specific set of protocols that plug into
>the WS-Coordination model to implement traditional two-phase atomic
>transaction
>protocols. It is important to note that the atomic, two-phase model is
>only with
>respect to the services involved. Sites or infrastructure offering
>services may
>advertise two-phase commit, but use some other intra-enterprise model
>like
>compensation or versioning. This freedom makes a simple two-phase commit
>model
>more useful for long-running Internet computations.
>
>which I entirely agree with. Of course, the statement completely
>sabotages the
>need to have a separate BA.

Well let's just say that there's a difference of opinion within large 
organisations like IBM and MSFT on everything and if you talk to different 
people you'll get different answers. C'est la vie!

>
>
>>   A
>> service that supports Atomic Transaction (taking the
>> IBM/MSFT/BEA specs to be even handed) is written entirely
>> differently from one that supports Business Activity. And the
>> user of that service had better know before hand that it
>> can't be invoked using Business Activity because it can't
>> provide the necessary service-side semantics to obey the protocol.
>
>what exactly can't it do ?  The reader of the BA spec will think the
>service
>is going to do perform,/compensate-if-told-to - but the work is still
>tentative in some way until compensate|close and, since this is
>a service, it isn't really meaningful to ask if the "partial results
>are accessible".

Hopefully previous answers answer this. If not, let me know.

>
>> > Each participant is concerend only with establishing (via the
>> > application exchanges) what the content of its promise will
>> be, making
>> > the promise, and applying the decision.
>>
>> But you ignore what it means to make the promise, or even
>> what that promise is. There are occassions where such a
>> promise can be pushed to the back-end and not affected by the
>> type of protocol. But there are many more where it can't.
>> Maybe I'm missing something here (perhaps reading too much
>> between the lines) because I'm sure you can't believe that
>> abstract "promises" and signals are all that's required.
>>
>> > It
>> > generally doesn't need to know what else is going on in the
>> > transaction, and the rest of the transaction doesn't need
>> to know how
>> > it is delivering on its promises.  That's service-oriented
>> > transactionality.
>>
>> That is definitely one specific model, and Business
>> Activities/Long Running Actions do epitomise that behaviour
>> precisely because they've been designed with that in mind.
>> However, the Atomic Transaction models (from both specs.) are
>> intended for *interoperability* between existing TP systems.
>> Please remember that Web services are as much about
>> interoperability as they are about the internet. And in which
>> case, the semantic differences between these types of
>> protocol are significant and can't be ignored, especially at
>> setup (bind) time or (importantly) at implementation time.
>
>I'm quite certain you can use BTP to interoperate with other TP systems.
>In
>fact isn't that what the JOTM implementation effectively does, treating
>BTP as just another transaction protocol.

Well the JOTM implementation only implements close-top atoms as far as I'm 
aware.

>  BTP lacks the synchronization
>mechanism (which is we've suggested sync should be stirred into the
>convergence pot). What else is special ? We've got an atomic flag

The semantics! There is no implied semantic for isolation or cancel or 
durability (as examples) with BTP - and that's fine: that's not a problem for 
certain types of application (i.e., this isn't a criticism of the protocol). 
However, because of that very fact an application provider can't determine 
purely from the fact that a service is BTP-compliant that it's also going to 
fully support ACID semantics (again, as an example). Despite what the above 
IBM paper may say, the Atomic Transaction model in WS-T is meant purely for 
inter-organisational TP-to-TP interactions where the ACID semantics are 
mandated and must be known a priori.

Now, you could do this with BTP with suitable Qualifiers and maybe publishing 
the service in a special way in UDDI, for example. But the fact is that it's 
not part of the protocol. You have to go outside the protocol to do this.

>
>
>> > Of course, there are cases where it is appropriate to pass more
>> > information about the transactional behaviour between the
>> parties. But
>> > those are refinements of the basic exchange, and
>> appropriately passed
>> > as qualifiers, policy declarations etc.  For example, informing all
>> > receivers of a context that any participant enrolled with
>> it will get
>> > the same decision allows said receivers to share work between
>> > participants, if they so wish, in a way that would be unsound
>> > without that assurance. Announcing time limits and time
>> > scales, allows other parties (if they have the flexibility)
>> > to choose an appropriate internal mechanism for how they will
>> > work in this case - but a service that lacks the
>> > flexibility doesn't have to be told about a completely
>> > different protocol just because some transactions it is
>> > involved in will take longer than others.
>>
>> Qualifiers are a useful extension to protocols but must be
>> used with care and have to be agreed upon by all sides in any
>> "negotiation". So if I have to define Qualifiers that take a
>> base BTP protocol (say) to the level of ACID transactions (no
>> forward compensation, isolation levels, etc.) then all
>> parties are going to have to agree on the precise meaning of
>> those Qualifiers, I'm going to have to make sure that
>> MustUnderstand (or whatever) is set to true so no one can
>> break the protocol, my services are going to have to
>> publicise the fact that they understand these Qualifiers (it
>> could be done dynamically, but in our experience that's not
>> the way people work at the moment), ...
>
>Unless we take as a starting axiom that everyone must know what kind of
>transaction it is, it is difficult to see why *all* the players
>MustUnderstand.

That is precisely my starting axiom - remember, interoperability is pretty 
important!

> The qualifier stuff is useful to some, but may not
>be to all. Why can't that service do forward compensation if it delivers
>the right results to me and to everybody else. ?

Because forward compensation doesn't give me the same guarantees for "undo" as 
rollback (timeliness for a start) and neither does it say anything about 
isolation or durability. BTP defines just the termination protocol, leaving 
everything else (such as isolation) up to the service or protocol extensions 
via Qualifiers. However, WS-T/WS-TXM have implied or explicit semantics for 
more than termination associated with each model.

>
>> There's a lot of work there to take a basic protocol and
>> narrow it to a more specific protocol. It's all possible and
>> I'm sure you've as much experience in doing it as we have.
>> But what's to be gained from going that route as opposed to
>> making those agreements explicit in the protocol messages and
>> the WSDL to start with? From the experiences and feedback
>> we've had, the latter approach is what people in Web services
>> are after (whether they want Web services for the internet or
>> for interoperability).
>
>Except they won't actually be explicit.

Sorry, who won't be explicit about what?

> The attraction of the portfolio
>approach is indeed that everything is declared up-front - "this
>transaction is being run under the WS-LRA agreement - if you can't
>cope with that, don't join in". However, in practice, if there is, in
>a particular case a genuine need for distributed understanding of the
>internal behaviour of the parties, the general protocol-defined
>agreement
>is probably not going to be enough.

What do you call the general protocol? In my definition I'd say that "2PC as 
unifying approach" is the general protocol and WS-T/WS-TXM define specific 
protocols. Is that consistent with your meaning?

>  Compare with XA - although XA
>semantics are fairly tightly-defined, you still have to dig into the
>database manual for sophisticated cases, and if you are into tight
>or loose coupling (in the XA sense), you need a further agreement
>(between
>your program and the database configuration, in that case)
>
>So, how big is the portfolio going to get ?  Will there be any chance of
>interoperation if every service has to choose which of the 3, 5, 10, 60
>transaction protocols it can cope with ?

Who knows? At last count there were well over a dozen extended transaction 
models some for very specific niche cases and many that were multi-phased 
(more than 2). But we're not saying that every service has to support every 
protocol. Where did that come from?

>
>
>There's a further point - it's claimed that WS-TXM supports
>interoperation
>between transaction protocols. From the ws-caf faq on the Arjuna
>website:
>
>WS-TXM's transaction model supports interoperability across multiple
>transaction
>protocols, including BTP, WS-TXM itself, and other proprietary protocols
>such as WS-Transaction.
>
>(I thought I'd seen a wider list claimed, but I can't find it)
>
>Now it's possible I've misunderstood that, and the "interoperability" is
>that
>you can use a BTP atom (say) to deliver the promises of WS-TXM LRA (say)
>- but
>that doesn't seem to be so from context (and would make it a very
>misleading
>statement). That's certainly possible, but no different from saying any
>of the
>protocols (except those wedded to acid and xa) could "interoperate"
>between local
>database transactions using a compensation approach (say).
>
>But if it means what it seems to, that it is possible to use ws-txm as a
>transaction bridge,
>with one transaction spanning multiple protocols and mechanisms, then I
>think
>you've made my argument. That can only be true if it *doesn't* matter
>what the internal
>mechanisms are and the protocols *are* semantically equivalent.

If memory serves, it refers to the BP model which is specifically about 
interoperability across different models and enterprise domains. The 
assumptions that that model makes are much more in the area of what you might 
traditionally consider SOA because it's intended for loosely-coupled 
environments. But that doesn't make it BTP.

>
>
>> >
>> > The WS-CAF/TXM and WS-C/Tx "portfolio" architectural paradigm is
>> > inappropriate for web-service transactions.
>>
>> Based on whose experiences? I hate to keep sounding like a
>> broken record, but as far as Web services are concerned, the
>> paradigms being proposed by IBM, Microsoft, BEA, Oracle, Sun,
>> IONA, Fujitsu and many others (who make up the Web services
>> "heavy-weights") are appropriate.
>
>ok, so I'm heretic :-).

I'm saying nothing ;-)

> Perhaps the industry hasn't thought through for
>transactionality
>the implications of service-orientation.

Or perhaps it has. Don't you think that's worth considering?

>  (though actually some of this
>goes right back to OSI CCR and TP - where the open systems
>interconnection paradigm
>(identical to the contemporary internet paradigm) was rather similar to
>SOA). And
>as you pointed out, they didn't implement those much either.

Let's meet back on this discussion in 2010 and see what happened ;-)

Mark.