I think we should be a little more cautious about the maturity of all these
specs, and have more of an eye to product completeness and maturity, including
ability to protect users from standards variation and flux.

The WS-Coordination and WS-Transaction (later WS-AT and WS-BA) specs have in
fact been out since August 2002 (we implemented them in Cohesions 2.0 in the
ensuing six months, alongside BTP). The specs were revised in September 2003,
and then again in November 2004. They have not changed vastly over these last
two years.

They are therefore not that new, and they unfortunately add very little to the
thinking or functionality of OASIS BTP, which was completed in June 2002 (and
which has the advantage of being a single spec, not two).

We therefore have (including the latest contender, WS-CAF) three families and
six protocols, to do one job: distributed service coordination using a two-phase
outcome approach. This is a symptom of how the standards need to settle down if
we are to see any level of genuine interoperability at work. They are useful
work, but customers need to be protected from this flux to make use of product
in this area.

Another manifestation of the earliness of *interoperable* loosely-coupled
transactions is the status of the specs. Unlike BTP, which has been through an
open standards process to become an OASIS Committee Draft 1.1, and reflects
product implementation experience, the WS-C+Tx specs are still in a proprietary
workshop process, and will have to go through a standards body to stabilize.
Don't expect stable output earlier than twelve or eighteen months from now. The
WS-CAF process also grinds slow, and the specs are changing a lot as they go.

The fact that IBM, Microsoft, IONA, Choreology and Arjuna demonstrated a pretty
reasonable degree of interoperability at a workshop is good, but it's only a
first step.

In fact the issue of interoperability is probably not the main issue when it
comes to useful product.

When looking at vendor offerings I recommend asking a few key questions that
will help evaluate maturity and utility:

0) Does the product look like a literal-minded translation of particular
interoperability specs or does it have a single API that shields the user from
the underlying coordination protocol, thereby insuring the user against
movement, flux and fashion in the immature world of such specs?

1) Does the product easily allow users to define recoverable participant
services, where the application defines how it "prepares" and how it confirms or
cancels? This facility allows the use of compensating underlying transactions,
and should support three models of use: do-compensate, validate-do, and most
generally -- provisional-final.

2) Does it support the concurrent use of predefined XA-compliant resources such
as JDBC drivers or JMS clients, along with app-defined participants within a
single transaction?

3) Does the product seamlessly integrate both single-phase and two-phase capable
resource managers (databases, queues) as persistence mechanisms for
application-defined recoverable participants in such a way as to ensure
application/resource manager synchronization, and therefore end-to-end
integrity.

4) Does the product allow checkpointing, to permit involvement of legacy or
non-transactional services (zero-phase resources), with maximum possible safety
and consistency?

5) Does the product treat atomic transactions and business
activities/transactions as two hermetically sealed worlds, or does it allow the
features of business transaction management (app-defined participants,
business-rule determined selective outcomes) to be combined with the use of
XA-compliant resources?

6) Does the product support a range of underlying transport protocols for
concurrent use within a single transaction, or is it restricted to SOAP
(excluding e.g. MOMs or Java RMI)?

7) Does the product allow the construction of transaction trees such that a
branch or sub-tree can be treated as a sub-transaction, including with
application-control over the outcome of the sub-transaction (e.g. selection of
the best price quote from several offers).

Alastair


Alastair J. Green
CTO and Director
Choreology Ltd
68 Lombard Street
London EC3V 9LJ
www.choreology.com


-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@...]
Sent: 16 March 2005 16:25
To: WS-TX-Workshops@yahoogroups.com
Subject: Re: [WS-TX-Workshops] Solving distributed TX'es through classic ACID,
fashionable WS'es or what?






Andre, you asked whether there were any "shrink-wrapped implementations" of
WS-AT and about momentum of the various standards. I can only speak for the
momentum of the set of standards that this group is focussed on. 5 separate
implementations participated in the interoperability workshop that we held
earlier this year for these specifications - see the summary of this event
posted to http://groups.yahoo.com/group/WS-TX-Workshops/files/
(specifically:
http://f1.grp.yahoofs.com/v1/8Ek4QgDu_IU-pndJARE31OBj1EdSsDI_iyGt5mU9yjkwrfHzBN9\
jUngQ7zDw91BrTCBwatCIqzlG5hx2onRYzGp3lrtueMU/Transaction-InteropResults012605.pd\
f)

I think this demonstrates that there is momentum behind these specs -
remember the specs were only published in Nov 2004. And there certainly are
"shrink-wrapped implementations" - for example WebSphere Application Server
V6 offers WS-AT support as described at:
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websp\
here.nd.doc/info/ae/ae/cjta_wstran.html

With respect to your scenario, the WAS link above describes an architecture
in which a J2EE application server is the IA, initiating a WS-AT
transaction as a consequence of an application making a web service request
while running under a J2EE (JTA) transaction. The partner in the WS-AT
transaction can be any web-service platform that supports WS-AT, which may
of course have a completely different runtime architecture. And WS-AT
interop between different runtime architectures was exactly what was
demonstrated at the interop event.


Regards,
Ian Robinson




"torkveen"
<andre.torkveen@s
ensewave.com> To
WS-TX-Workshops@yahoogroups.com
15/03/2005 08:39 cc

Subject
Please respond to [WS-TX-Workshops] Solving
WS-TX-Workshops distributed TX'es through classic
ACID, fashionable WS'es or what?











Dear fellow transactions-involved professional,

I who write you this am an IT architect working for a Norwegian
electrical energy/utilities company, Statkraft
(http://www.statkraft.com/). We're in the process of building an
enterprise-wide SOA platform, using middleware from various vendors
(significant players are webMethods and SAP) to realize an ESB between
different Line-of-Business end-nodes.

One of the challenges we face is to come up with a consistent,
reliable and recoverable way of ensuring that end-nodes in our loosely
coupled environment are kept in synch in by some mechanism, - but
without resorting to synchronous means of communications
(participating parties are - and should be - unaware of each other)!

Our first idea was to see if we could «steal» some of the very
good
groundwork laid down through traditional OLTP, but hopefully without
having to employ all the advanced features, simply opting for a custom
implementation of the simplest semaphores.

The following scenario outlines a lightweight custom setup - any
comments would be highly appreciated!

* Either the initiating party (IA) itself or a centralized
broker facility (equivalent of a resource manager of
the OLTP era) sends a «BeginTransaction» message with
a transaction ID to all participating applications (PAs).
This transaction ID is then referred throughout the
lifecycle of the following message conversations
* When all PAs have replied that they're listening,
one or more messages are transmitted (large messages
may be split up into several pieces, but that's out
of scope here)
* During the run, one or more of the PAs can submit an
«Aborted» message. In that case, the resource manager
will send a «Rollback» to all parties involved.
Messages received before this point are then deleted
* If the resource manager doesn't get any «Aborted»
messages within a defined period of time, the resource
manager sends a «Prepare» message to all PAs. PAs can
then open database transactions to their own underlying
data stores (typically RDBMS'es), handle all received
messages and answer either «Prepared» or «Aborted» to
the resource manager. If «Prepared», the described
RDBMS transaction will remain open
* If the resource manager receives «Aborted» from some
PAs, «Rollback» is sent to all PAs. Any open transactions
to underlying RDBMS stores are then terminated
* If the resource manager receives «Prepared» from all PAs,
«Commit» is sent to all PAs. Open RDBMS transactions will
then be completed

Then there's a second issue that I'd very much like to understand
better - unclear availability of shrink-wrapped implementations:

We've done a bit of «desktop research» to find a suitable
approach,
and it appears that neither the WS-* stack of specifications
(including WS-AT), the OASIS-promoted WS-CAF (including WS-TXM) or the
older OASIS BTP has gained major momentum. Meaning there are few - if
any - working real-life product implementations that support any of
these. I'll be glad to be corrected if I'm wrong!

BTW: The new specifications seem to substitute the old-fashioned ACID
«I» (isolation) with after-the-fact compensations, and that
appear a
bit scary to many people. Perhaps this is a contributing reason why
even vendors like webMethods and SAP have put their decisions and
implementations on the wait-and-see list?

Bst rgds,
André Torkveen
Statkraft AS




Yahoo! Groups Sponsor



ADVERTISEMENT
(Embedded image moved to file: pic29579.gif)click here


(Embedded image moved to file: pic26132.gif)




Yahoo! Groups Links
To visit your group on the web, go to:
http://groups.yahoo.com/group/WS-TX-Workshops/

To unsubscribe from this group, send an email to:
WS-TX-Workshops-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Yahoo! Groups Links