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.