Re: [business-transaction-comment] Public Comment

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

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

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

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

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

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

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

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

> There should be a
> single outcome protocol, with the ability to take
> qualifiers/policy statements, and as many control
> mechanisms and patterns as are found useful. Defining
> web-services for the control mechanisms is reasonable,
> but secondary.

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com