Hi again everybody,

First of all I want to thank everyone who has taken time to answer! Even
more so to those of you who I contacted directly while I was waiting for
my application for admittance to this group to come through. Too late I
recognized my double effort was a bad idea, and when I told you I had to
finish the independent dialogs and rather share our conclusions with the
entire forum, nobody objected, even though I’d been handed papers that
gave us excellent input!

Conclusion #1 – General:
----------------------------------------
The community spirit still flows! At a point we felt disturbed about
finding a suitable way for solving this very delicate problem, not to
forget navigating the WS’es maze. That’s not so much the case any more,
thanks to you guys!

Conclusion #2 - Conceptual solution design:
-------------------------------------------
We’ve considered three different strategies:

A) DON’T GO THERE - avoid the thing completely!
Outside of this forum several people advocate that we should rather try to
work around it, e.g. by performing the various flow steps in sequence
instead of simultaneously; in the simplest cases with only two PAs (one of
them being the IA), it should be absolutely viable. A strong argument for
this viewpoint is that classic 2PC/XA would effectively work as a poison
pill for a loosely coupled environment like ours; holding resources
through the state transitions is simply not acceptable!

B) LIGHTWEIGHT
This scenario is for those occasions when the A) alternative just won’t
cut it, while the challenge at hand still isn’t too complicated.
In the projects we’ve mapped, the need is to synchronize no more than two
participating systems at the same time, except from in one case where a
3rd system also needs to be updated, but that doesn’t have to happen until
after the other ones have finished. And long running TX’es are out of
scope, at least for now. Besides, since we have a MOM with guaranteed
delivery in operation. So we hope we can cope by emulating a limited
vocabulary/set of semaphores on top of that, as outlined in my first
posting.

C) FULL-BLOWN
Here we’re talking about a centrally managed environment; an advanced
«black box» resource manager runs a tidy ship and coordinates all the
traffic – like the ones several of you guys offer. Without a doubt, this
is the cleanest act, and on an asynchronous platform I find it downright
impressive that it can be achieved at all!

So, what’s the decision going to be over here at my employers’ then?
Well, my hunch is that we’ll probably settle for the «uncool» solution; a
mixture of the A) and B) approaches above.

Now, it’s important to keep in mind that in such a case we would actually
be doing a custom protocol implementation. Under such circumstances we
believe that it’s imperative to isolate in-house code so that we’ll be
able to scrap/swap it out when similar functionality becomes available
through standard off-the-shelf offerings from our preferred vendors
(…which may be a couple of years ahead: TX’ing trails second last on
webMethods WS’es to-do list, and as far as I’ve been able to determine,
SAP hasn’t even come out with one of enough detail).

Naturally, there are inherent drawbacks of creating things on your own;
except from the fact that the result will have narrow functional scope
(read: «stiff», not very reusable code), we recognize the escape from
purchase price translates into more risks in terms of internal
housekeeping (read: change/configuration management). Unless good
routines are in place, embarking on such a route could easily turn into a
maintenance nightmare. How do you for example handle upgrades of
components that are touched by the custom code? Besides, we know we
haven’t worked out all the small intricacies yet, but at this point we
don’t see the remaining work holding issues of potentially show-stopping
nature.

Since we’re deciding on issues of this importance, we wanted guidance and
second opinions from externals. Being a Gartner client we asked for a
conference with an analyst proficient in both XA and WS’es. Luckily, we
got to speak with the very competent Yefim Natis
(http://www.gartner.com/AnalystBiography?authorId=7256) who confirmed our
findings, strongly advocating sobriety or «proceed with caution», much in
line with Alastair Greens posting dated the 16th.

Conclusion #3 - Standards and product offerings:
------------------------------------------------
We’re fascinated about how the WS-* specifications have sliced the natures
of short running (WS-AT; all-or-nothing, like the name suggests) and
longer running (WS-BA; after-the-fact compensation) scopes neatly between
themselves. But being emotionally in favor of open organization-supported
instead of vendor-driven specifications, I must admit that the OASIS
WS-CAF still isn’t quite clear and convincing to me; I can’t say I’ve
gathered how they intend to support a span of varying requirements –
except from by employing the more proven but far less «sexy» approach of
BTP. Then again, since everyone touts WS’es nowadays, I believe it would
be far more difficult to convince decision makers to go for a perceptional
«old fashion thing». And at the end of the day, stuff like that can make
the whole difference!

We were a bit skeptical because we had the [FUD’ed?] impression that the
only viable alternative in terms of WS-* product implementations would be
the very proprietary WSE2 (now) and «Indigo» (someday), with the only
true contenders being the upcoming versions of the spooky huge WebSphere &
WebLogic families - following somewhere in Microsofts wake.

Shame on me!

But actually, I’d say that the same could go for you guys as well; please
tell me WHY standards-compliant, neatly pluggable packages like ArjunaTS
and Cohesions are «well kept secrets» to simple soles like me?

I should add that Eric Newcomer told me Artix can provide the same
capabilities, but I must say that my perception of IONA inclines more
towards the complete stack offering; would it really be natural to
purchase, learn and integrate a floor-to-ceiling offering like Artix into
a running webMethods-based infrastructure like ours, just for the sake of
TX’ing? I’m sorry to say so, but the way we tend to see things around
here, I think not – from our point of view IONA is more in the league of
the aforementioned larger suites (…so if I was looking for a full-blow
framework Artix would appear on THAT list instead).

On the other hand, I think we would have been able to drop any of Arjunas
and Choreologys offerings into our environment - without having to
reconsider/redesign fundamental aspects of our existing platform.
Beautiful!

- Further comments, anyone?

Thanks again,
André T.


-------------------------------------------
This mail was sent through Freewave AS Webmail
http://www.freewave.no/

Solving 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