RE: [business-transaction-comment] Public Comment

["Haugen Robert" <Robert.Haugen@choreology.com>]

Mark Little and Eric Newcomer replied to Boris Lublinsky's message on
the business-transaction-comment list. Their message is archived at:
http://lists.oasis-open.org/archives/business-transaction-comment/200311
/msg00000.html 

I've chosen to reply to one paragraph here, because these are exactly
the issues that some of us have proposed to discuss, and the
public-comments list is an awkward venue.

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

The convergence argument is:
* Generic protocol signals 
* Generic rules for when to emit which signals 
* 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.

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.

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

WS-CAF proliferates yet another group of transaction protocols 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.  There is not much new -
just several sets of different names for the same things.

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.

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.

-Bob Haugen
Choreology Ltd