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

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

I've cc-ed Eric since I don't think he is on the public comments list.

> <Mark Little & Eric Newcomer>
> It has been said that BTP is a two-phase completion protocol and that
> most
> of the protocols in WS-T and WS-TXM can be mapped onto a two-phase
> protocol
> as well. However, this glosses over an important point. Although you
> could
> implement WS-T and WS-TXM using a sufficiently flexible two-phase commit
> engine, this is purely an implementation choice. In some of the
> protocols,
> the first phase or second phase might be a null-op, for example. So, if
> you
> were to design an implementation of these protocols from scratch would
> you
> really do that by implementing a two-phase engine first and then casting
> aside portions of that engine simply because they don't need to be there
> for
> some protocols? Probably not. But again, that's an implementation
> choice.
> </Mark Little & Eric Newcomer>
>
> But the proponents of protocol convergence are not talking about
> implementations, and Mark should know that.  He was present when
> Alastair Green made the same arguments at the recent High Performance
> Transaction Processing conference.

Yes, I was there and Alastair's presentation didn't convince many in the
audience.

>
> The convergence argument is:
> * Generic protocol signals
> * Generic rules for when to emit which signals

We've been there before with the CORBA Activity Service, which did precisely
this: standard protocol signals and rules about when to emit them. It works
and in fact doesn't contradict what we're done in WS-CAF (if you look
closely at the specifications you'll see that there are similarities).
However, what it does rely on is higher-level "services" imposing semantic
meaning on the generic "blob" signals that get communicated. The WS-CF spec.
defines the generic layer, and WS-TXM provides a specific set of mappings.

> * Specific implementations
>
> For example, I've mapped all of the control protocols in WS-T and WS-TXM
> to the BTP set of signals:
> * prepare-prepared
> * confirm-confirmed
> * cancel-cancelled.

Yes, and as was said in our email, some of them will be null-ops or
overloaded on the semantics. This is a similar argument to saying "let's
standardise on sendmsg and recvmsg and leave everything up to the higher
levels". I know from experience that what you have said is possible, but
it's not necessarily the only route to achieving protocol implementation.

>
> If all of the "-ed" signals can be volunteered, that accounts for all
> the variations in WS-T and WS-TXM.
>
> My point is not that BTP should *be* the unified standard protocol, just
> that a unified standard protocol is well within reach.

Based on what? The fact that *some* protocols can be shoe-horned into a
two-phase model?

>
> There's a time for proliferation and a time for convergence.

I'm sure you'll agree that convergence based on experiences is useful and
both the IBM/MSFT/BEA camp and the WS-CAF consortium appear to have had
similar experiences in this regard. And they aren't based on trying to come
up with a single low-level protocol that can be cast into different variants
at the higher level. Ignorning names, what's the advantage in a protocol
that has "foo1, foo2 and foo3" messages and then these must be manipulated
somewhere "higher up" to map to "do work, compensate, prepare to do work" or
whatever. That's a step backwards IMO. Taking what I believe is your
argument to the extreme, let's standarise on foo and leave foo1, foo2 and
foo3 up to the higher levels.

> WS-CAF proliferates yet another group of transaction protocols

Yes, where each protocol has well defined semantics that are associated with
the individual messages on the wire.

> with a
> framework in which multiple protocols can interoperate, with an
> unspecified set of mappings between them.  But all of those protocols
> can fit within one standard set of signals.

Take a look at the WS-CF schema and you'll see that they do to a degree that
makes more sense IMO.

> There is not much new -
> just several sets of different names for the same things.

I can certainly understand what you are driving at, but unfortunately it
goes against what we've seen from customers and users (both end-user and
embedded systems developers). Simply saying that everything is two-phase (or
can be mapped to two-phase) is short-sighted and is an implementation
choice.

But, I'm sure we'll continue to disagree.

> My personal focus on convergence is for economic exchanges between
> trading partners, that is, business transaction as business agreement
> protocol.
>
> The goal of most companies who have done or are contemplating electronic
> commerce is to eliminate setup negotiation, to get as close to zero
> configuration as possible.  This is in contrast to EDI where new trading
> partner relationships usually cost lots of time and money to get up and
> running, and then often leave users calling each other on the phone
> about problems.
>
> Transacting across companies using multiple protocols will require all
> trading partners to implement all protocols, or an EDI-style protocol
> negotiation and implementation project for any new protocol.  Moreover,
> with multiple protocols, the chance of misunderstanding is greater.

That's not quite accurate. None of the specifications that we've seen so far
mandate the implementation of all protocols. Just taking WS-CAF for instance
(actually WS-TXM), you are free to pick and choose whichever protocol you
want to implement that best suits your needs. An in fact the BP protocol in
that spec. is explicitly intended to be used for protocol bridging, again
based on experiences of (many large) users.

>
> I've worked a lot with the RosettaNet-ebXML BPSS-UNCEFACT BCF style of
> business transaction.  Tony Fletcher and I mapped that style to the BTP
> signal set last year. It's a little more of a reach, but it is at least
> technically possible to unify all the existing approaches to business
> transactions for economic exchanges.
>
> While multiple protocols may be tolerable in internal development
> projects, I can't think of a good argument for them even there.  If the
> proponents of multiple protocols have some real-world use cases, I'd be
> interested.

I'm sure they'll come out (where possible) as we progress things.

However, the reality of the matter is that to the best of my knowledge none
of the big players are going to standardise on a two-phase message protocol
that is mapped to protocol specific semantics by some higher level. Everyone
wants well defined semantics at the protocol level (e.g., prepare for WS-T
AtomicTransaction is different from prepare for BTP cohesion). To remove
that is definitely a backward step and is almost akin to standardising on a
meta-carrier protocol.

Mark.

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

www.arjuna.com