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

["Haugen Robert" <Robert.Haugen@choreology.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.)

> 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?
Actually, mine is the same as the argument for a limited set of protocol
methods in HTTP and Web-DAV.

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

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

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

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

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

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

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

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

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

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.

But I appreciate the energetic discussion.

Thanks,
Bob Haugen