business-transaction message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [business-transaction] Points for tonight's meeting
- From: Alastair Green <alastair.green@choreology.com>
- To: "OASIS BTP (Main List)" <business-transaction@lists.oasis-open.org>
- Date: Wed, 21 Aug 2002 17:15:50 +0100
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 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.
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.
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).
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 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 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.
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.
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.
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?
Best regards,
Alastair
--
Alastair Green
CEO, Choreology Ltd
Cohesions 1.0 (TM)
Business transaction management software for application coordination
+44 207.670.1679
+44 207.670.1785 (fax)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC