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

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

> >> 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.
>
> Null-op, yes.  Overloaded on semantics, no.
> (Unless you consider the difference between compensation and some other
> method of cancellation to be semantic.  I don't, I think it's an
> implementation decision.)

Yes, I do and no it isn't :-)

>
> > This is a similar argument to saying
> > "let's standardise on sendmsg and recvmsg
> > and leave everything up to the higher levels".
>
> Argument by parody or exaggeration?

Taking the argument to the extreme and illustrating that it buys us nothing.
We're not defining a communications (carrier) protocol, which collapsing
things down to a send/receive of arbitrary data would give us.

> Actually, mine is the same as the argument for a limited set of protocol
> methods in HTTP and Web-DAV.

Web Services transactions is not concerned solely with the sending and
receiving of abstract messages. There's only so much can be hidden behind a
service facade, especially when you want to do interoperability (which WS-T
and WS-TXM are also about).

>
> > I know from experience that what you have said is possible,
> > but it's not necessarily the only route to achieving protocol
> implementation.
>
> Of course not.  There's never only one way.  But again, I'm allowing for
> multiple implementations.

Not unless I misunderstood your argument, which seems to be (and please
correct me if I'm wrong): let's define (yet another) Web Services
transaction protocol that only talks in terms of two-phase completion and
cast everything else onto that. If you've seen my response to Peter you'll
see the arguments against that approach, so I won't restate them here.

>
> >> 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?
>
> The fact that *all* existing protocols can fit quite comfortably into
> one common set of signals.

This depends on your definition of "comfortable". It doesn't match mine or
others, I'm afraid.

>
> >> 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.
>
> 1. WS-CAF went way farther down the road to proliferation than
> IBM/MSFT/BEA (with WS-T).

In what way? Because we defined 3 protocols compared to 2? Again, that was
based on interactions with end users, some of them extremely big users of
Web services.

>
> 2. How much experience with this stuff has there actually been?
> I suspect RosettaNet has processed more actual business transactions
> than WS-CAF, and they standardized *everything* including message
> contents.  (Note:  I'm not arguing for that extreme.)

Not all experiences are based on standards. Many companies have been using
ad hoc (in house) "Web Services transactions" and extended transactions for
many years and it's their experiences that count as much as others. We saw
time and again requests to be able to leverage existing infrastructure
investments and expose them as well-defined services, not as some abstract
message consumer.

>
> > 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.
>
> More argument by exaggeration.

Not quite. It is a comment based on the work we did on precisely this in the
OMG and JSR (the Activity Service), which did standardise on "foo". Let's
try to keep the facts straight here, OK? We standardised on a signal message
and rules on when it could be sent and implementations then narrowed that
signal to specific protocol messages. So there wasn't even a prepare message
at the base level.

One of the protocols we considered (and which there was discussion on at
HPTS) was the old favourite: three phase commit. There wasn't a lot of
immediate requirement for it, hence the fact that it didn't make it into
WS-T/WS-TXM but it does go to show that there's scope of protocols that
don't fit into 2PC, even with null operations. Despite the fact that we all
have experiences in this area, it's still evolving and we're still seeing
requirements for other "niche" protocols. That's the reason the WS-T/WS-TXM
are live documents intended to be updated with new protocols as and when
they arise. I certainly couldn't say at this stage that what we've got
currently will cover all uses cases in the future. Can you?

> The messages are much more specific:
> prepare, confirm work, cancel work.  "Compensate" is one implementation
> of cancel, but which implementation I use is not anybody else's
> business.

Well this isn't what we've seen. Please see the comments to Peter's email
for reasons. It's certainly one possible way of doing things, but it isn't
the only way and doesn't necessarily buy you any advantage. You've got to
agree on the semantics that the service will provide to its users
constrained by the protocol. I for one wouldn't want to be assuming that a
service will give me strict serializability simply because it can be driven
via 2PC to completion.

>
> >> 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.
>
> What is the public semantic difference between (for example):
> * commit, complete, and confirm?
> * rollback, compensate, and cancel?

In order to answer that question, take a look at the difference between
extended transaction models like Sagas and ACID transactions. There is real
semantic meaning to saying "this service is an ACID participant that is
driven via 2PC" and that's different to saying "this service is a BTP
participant that's driven by 2PC".

>
> > 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.
>
> The problem with a suite of protocols in B2B ecommerce will be that each
> trading partner may pick a different protocol.  Which is why I say that
> companies with many trading partners will be forced to implement many
> protocols.  If they want to eliminate development projects for new
> trading partners, they will need to implement all.

With any luck they'll pick the right protocol for the right job and not
something that tries to be everything to everyone! If we just look at WS-T
only one of the protocols is really meant to run in a loosely coupled Web
Services environment: Business Activities. So we would expect that trading
partners would interact only via this. Atomic Transaction is for
interoperability in the main.

>
> > 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.
>
> But you say your argument is based on all this experience.
> For me to believe it, I need *some* details.  Doesn't need to name
> names.

I understand and hopefully that'll happen.

>
> >  Everyone wants well defined semantics at the protocol level
> > (e.g., prepare for WS-T AtomicTransaction is different
> > from prepare for BTP cohesion).
>
> It's different for the coordinator, but not for the participant.

Not true. The semantics for providing forward or backward compensation for a
participant are significantly different. Just because the operation may be
called cancel doesn't mean that in a forward compensation scheme you can
guarantee to cancel in any finite period of time, whereas well behaved ACID
participants will (heuristics aren't that common and good implementations,
such as Oracle, strive hard to prevent that sort of thing happening).

>
> I differ somewhat from my colleagues at Choreology, in that I don't
> think there is any justification for a participant to care whether the
> transaction is atomic or cohesive or whatever.  If you bake compensation
> into the transaction protocol, you force an implementation decision on
> the participants, which I think is wrong from an elementary software
> engineering public-private standpoint.

I understand, but it just doesn't work in practice. To be able to compensate
I really need to understand the semantics of what the business has done in
order to do that. For example, generic compensation participants are most
likely never going to happen. To be able to rollback in a traditional
transaction system, the participant (resource) doesn't need to understand
anything about the work - typically there's a before-transaction "blob" and
an after-transaction "blob" and the participant just works on these "blobs".
That's why it's possible to have generic participants (the same participant
can drive Oracle, SequelServer, Cloudscape, ...)

Every single customer/user we've talked to has already wanted to make a
clear differentiation between a service that is implemented using
compensation and one that isn't. And that's even before we get down to
protocol specifics!

> But I appreciate the energetic discussion.

Ditto.

However, we're only discussion technologically different approaches to the
same problem. In the original response email we deliberately broke this down
into two statements, based on technical and political aspects. Irrespective
of the technical merits of one approach over another, the political reality
is that the major players in this arena are backing either WS-C/T or WS-CAF
and both of those (sets of) specifications are close enough to allow for
real interoperability even if we can't get everyone together under the same
banner.

Mark.

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

www.arjuna.com