RE: [business-transaction-comment] Public Comment

["Furniss, Peter" <Peter.Furniss@choreology.com>]

The Mark-and-Peter thread - hope everyone did get Mark's reply to me.

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

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

> > 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 ?
How will it affect their internal behaviour ? 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. 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.


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

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

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

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


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.


> >
> > 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 :-). Perhaps the industry hasn't thought through for
transactionality
the implications of service-orientation.  (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.


Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 870 739 0066  <-- new, from 4 August 2003
mobile: +44 7951 536168