Re: [business-transaction] Points for tonight's meeting

[Mark Little <mark_little@hp.com>]

 

Dear colleagues,

Unfortunately I won't be able to attend the phone meeting tonight. As Peter and Tony are out on holiday, one of our colleagues Mike Leznar would like to attend the meeting as an observer, if that is OK. He may be a little late in dialling in, as he is travelling at the moment.

I have some points I'd like to contribute to the discussion. Some of what I say may not be fully agreed by all concerned within Choreology, as others are away from work at the moment.

Our overall stance is contained in our press release of 14 August

http://www.choreology.com/news/140802_webservices.html

On the technical comparison between BTP and WS-C+T:

If we leave aside the multi-protocol support for enrollment/registration in WS-C, then functionally WS-C+T is a large subset of BTP (slight proviso of some indications on security integration).

 

I think one of the important points we need to make sure we don't get embroiled in is that of BTP vs WS-C. As a representative of the company that actually started the WSCF effort (from which WS-C and WS-T were spawned) I can say that there is an important difference between coordination and transactionality that makes WS-C an important effort in its own right. It would be relatively easy for us to get dragged into an argument that should not (IMO) be fought and could detract from the main effort: what is the difference between WS-Tx and BTP? So, I'd recommend that from the outset we just talk about WS-Tx and not WS-C - let's not give people more rope than we have to!

I am trying to persuade the more conservative elements in Choreology to let me announce a

"Choreology Convergence Challenge: £10,000 (cash or specie, ~$15,000) to anyone who can come up with a use case or application scenario that the combination of WS-C+T can support, but that BTP cannot support". I hasten to add that they have not let me do this yet, so this is a conceptual challenge only at this point.

The purpose of this challenge would not be to launch a BTP vs WS-C+T war (which I think would be a truly futile business), but to highlight the need for convergence to provide a single interoperable means of delivering business functionality to customers.

It's an interesting idea, much like the Amazing Randi's attempts to prove (or disprove) paranormal "powers". However, I think it would be all too easy for it to be perverted to become what you say you don't want. Obviously there's nothing that the TC (or anyone outside of Choreology) can do to prevent this, but IMO it's treading a very fine line.

My view is that it makes little sense to have one standard (a) and another standard (square root of a, squared), which express much the same things but in different ways.

I think there is definitely a requirement for a single standard and there just might be one Web Services transactions protocol. However, I'm extremely wary of trying to make WS-Tx look like BTP (or vice versa): if IBM and MSFT wanted to have a BTP protocol then they would have been in at the start. They weren't and refused to participate over the last 12 months. That has to say something (quite loudly) as to their stance on BTP. So any attempt to make WS-Tx look like BTP will probably fail. I personally think our best approach is to look at the core concepts behind WS-C/Tx: that of a generic coordination framework on which (in this case) specific transaction models can be implemented. So, if we can implement BTP on WS-C and have it adopted as *one* of the transaction protocols in the WS-Tx specification (or whatever some amalgam spec. is called), what have we lost?

There are several things about BTP which should not be lost in a convergence effort. Some have already been touched upon: e.g. high respect for participant autonomy, expressed in anticipation of and forewarning of pre- and post-prepare withdrawals. Others are quite useful and important: heavy optimization possibilities through compounding, "one-wire" capability; control capability for a cohesions hub (WS-T BAs lack interoperable control capability, tho' they do, in a rather awkward way, permit cohesions-like capability); ability to bind to multiple carriers and alternate representations (I think you could actually create a WS-T binding of BTP, tho' it would be an oddity).

We need to be very careful about how we approach the "BTP does this and WS-Tx doesn't or does but not very elegantly"! The TC needs to remember that both IBM and MSFT have large customer bases for (long running) transactions, workflow and business-to-business transactions. I presume that what they have produced in WS-Tx fits pretty closely with their existing non-Web Services implementations, making interoperation trivial for them. Any effort to make that interoperation less trivial (despite what we may believe are the merits) will probably fail. I keep coming back to the notion of these domain-specific transaction models and, in the long run, the user market: if we can get BTP into WS-Tx as is and leave the IBM/MSFT Tx protocol in too, then we let the users decide which transaction semantics they want. (The original idea was also that if these transaction protocols didn't suffice, it should be possible for others to implement their own on WSCF.)

WS-C+T is infelicitous in its complexity, particularly the unnecessary separation between AT and BA, and the similarly unnecessary distinctions between styles of BA.

The TC's been pulled up on BTP's complexity on more than one occassion, so I don't think we can push that argument ;-)

The complexity leads to excessively tight coupling. Applications being coordinated should not be aware of the technical means or mechanisms whereby business contracts are delivered upon. This reduces their composability. A key conceptual gain of BTP was the generalization that any effect can be countered or finalized in a manner decided by the service provider, only subject to overarching business agreements.

I agree, but I keep coming back to why these companies have produced what they have: existing implementations. You know yourself, there was exactly the same issue when the OTS specification was developed: each company had its own interests to look after so the specification wasn't as perfect as it could have been had they started from scratch. However, it didn't make it any less valid a specification.

I believe that Microsoft and IBM should be formally invited to join in creating a new OASIS TC, taking BTP 1.0 and WS-C+T as inputs, to work on a unified standard.

I believe that too.

If this cannot be accomplished then vendors and customers will have to make their choices. Our product can and will support WS-C+T because, broadly speaking, they are a subset of BTP, as we had expected.

I think that this has to go to a standards body, but where IBM and MSFT are concerned (and particularly in the area of Web Services [cf UDDI/SOAP]) nothing is guaranteed. I cannot say at this point what HPs position on this is in respect of standards or implementations.

My final comment is on IPR. I would welcome clarification from BEA, as the only WS-C+T signatory active in the BTP TC, on the actual status of the jointly published documents, and the plans and timetable for standardization, if any.

Yes, I'd like to hear that too.

Specifically: are WS-C+T implementable for commercial product development and marketing purposes by non-author companies? If so, on what terms or bases? If not, then when can it be expected that they will become implementable? What are the IPR policies of the author companies in respect of these specifications? Does BEA support a royalty-free policy for WS-C+T as they progress?

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250