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