A realization has dawned across the industry that "service-oriented architecture" is a good thing. In fact, this is less of a dawning and more of a reawakening.

Ever since our Neolithic forebears picked up a bone and realized that separating the 3270 screen handling code from that which implemented their business rules was a "jolly good thing," three tier architecture, n-tier architecture, SOA, call it what you will, has been recognized as the best way to build systems. The facets that make it the best way are called out by the industry mantra "coarse-grained, loosely coupled, asynchronous interfaces," as we all know.

Looking around at a lot of enterprise systems in production today, the "asynchronous" part is often (maybe even usually) delivered via use of an asynchronous reliable queuing mechanism. The power of the "fire and forget" programming style that these technologies bring to the table is that your part of the system can simply post a message and rely on the fact that it will eventually arrive at its intended destination (or be processed by some harassed administrator who was paged in the middle of the night when the infrastructure went pop). The ability to rely on this behavior keeps the application code nice and simple - the concept of "fire and forget" is readily understood, and the technical complexity required to implement it is encapsulated within the queuing product. Couple that with transactional xa access to a database, and your application can rest easy in its bed at night, knowing that everything it wants to achieve will happen once and once only, with no user code needed.

Life is good. We know the chant, we sing it, and we have a trouble-free existence as developers. Everything is as it should be.

Of course, in all of life's rapture moments, something is bound to happen to cause a rude awakening. Imagine now the discordant ringing of a thousand alarm clocks.... Snap out of it! Life isn't that good!

For a start, the administrator got paged in the middle of the night when things went wrong... What did he have to do to fix things? Well, we can't answer that. It depends. Where was the message going? Why didn't it get there? Is the data in the message in error, did the queuing infrastructure break under the strain? Our administrator needs to answer these questions (hopefully in consultation with the documentation, rather than the actual developers that wrote the system, but either way, what to do to resolve the situation can only be decided in the light of hidden knowledge of the context around what was going on). For one thing, this highlights that coarse-grained, loosely coupled, and asynchronous are orthogonal attributes - the asynchronous behaviour of our transport has not bought us loose coupling - a point-to-point asynchronous link is still just that - point-to-point. To address the problems of hidden complexity brought about by a point-to-point design, a choreography layer is introduced into the architecture, decoupling the message senders and receivers. Standards like BPEL, implemented by products such as BEA's WebLogic Integration (or WebLogic Process Edition), provide this place within the architecture for the "knowledge about interconnectedness" to live, so there is a point of reference for the guy who needs to fix things when they break - a single place to go to see the end-to-end message flow, and determine where things fouled up in the overall scheme of things to provide some context for fixing whatever failed. This is the realm that is emerging as the "enterprise service bus (ESB)."

Another rude awakening comes when the user of the application built on this asynchronous technology says, "What happened to my trade" (or, in general, what happened to my <whatever I initiated a while ago with my app>). Suddenly, the support staff is scrambling around with all kinds of headaches. Where did this particular instruction get to? If you are using a choreography layer to solve the point-to-point problem outlined above, then this should provide a means of drilling into an individual instance of a business flow and tracking where it got to (and perhaps why it's stuck there) so you have a solution for this class of problem too.

Then, just as you were feeling smug and ahead of the game, the managers of the individuals who use the system come along and say, "How's it working? Is everything fine? How is our business performing?" Now, the ability to drill into an individual request is not so important. What's needed is to get a top-level overview of the system - how many business transactions are in flight? Where are they all up to in the chain of events from entry to completion? Have any taken too long to pass through the system, requiring intervention to fix whatever is wrong?

This last requirement is usually termed "business activity monitoring" (BAM) - and in traditional point-to-point messaging-based systems, its delivery generally constitutes some kind of dashboard that shows red lights when "too many" messages haven't passed through any given point (or when messages appear to have missed stages, or otherwise broken the rules) and the infrastructure that gathers the transaction tracking data needed to provide the aggregated view generally consists of yet more queues. As each message is delivered to the next application, a "BAM message" is sent to the BAM system, which processes it (along with all the others that are flooding in) to determine where in the end-to-end system each individual business transaction is. Again, in a world orchestrated by an ESB-type approach, the message bus provides an ideal point to collect and collate all this information.

So that's nice. We are happy again, and can start to go back to our sweet dreams.

So, What About "Next Generation Transactions"?
Well, the scenario I described is very much one in which the overall structure of the system is fairly static. OK, so you configured your ESB to wire the constituent services together so it wasn't point to point, but the flow follows the same consistent pattern execution after execution. What about other scenarios? Imagine an order fulfillment system that works out a price for an order by getting prices and availability from several sub-contractors and then makes some decision as to which set of purchases provide the best offer. For example, I get a quote for laptops from three suppliers, each responds with a different price, guarantee terms, and availability. I then get a quote to ship the laptops from each of these suppliers to my customer. My overall price for each permutation is the sum of the unit price and shipping cost, and my customer may wish to choose between the options based on the overall price, and required delivery dates, the guarantee terms, etc. The flow of the final transaction will only be decided when these decisions are made. Suddenly, we are in a situation where we are getting forced down the line of writing an "orchestration" application, which is relatively closely coupled to all the back ends it accesses.

Moreover, because we are getting painted into that corner, tracking our orders will be rather difficult: for every order, we will have to track the decisions that were made in order to know where to look for our in-flight order, once placed. This is where the new-generation transaction comes in. The notion of a cohesion - a unit of work similar to a transaction in that it can be cancelled or committed, but distinct in that it does not have to complete or cancel in an all-o-nothing fashion - was introduced in OASIS' BTP specification. The concept is currently working its way into the WS-BusinessActivity variant of the emerging WS-Transaction specification. Provisional orders for the laptops could be placed with the three suppliers in one cohesion, with every intention that by the time the order is finalized, two of these three laptop orders will be cancelled again. It will be similar for the shipment requests. Using a framework to drive this loosely coupled transactional behavior will greatly simplify the code of the orchestrating application (and provide loose coupling benefits similar to those the ESB offered in the fixed-flow case). The fact that a framework is being used to track all these interactions means that when the requirements for the BAM-style capability surface, the next-generation transaction framework provides a central point of reference, which will directly provide the "where has my transaction got to" information, and (via something analogous to transaction timeouts) be able to monitor service-level agreements and provide the information to drill in to to diagnose problems. In fact, this is an often-overlooked benefit of the traditional JTA style transaction manager: it provides a place you can go to and say, "What data did this operation touch?" at least while the transaction is in flight.

So, a framework supporting cohesions could become to the dynamic application system what the ESB is to the static one. In fact, it is also possible to envisage a cohesions framework augmenting an ESB-style approach, even for statically defined systems. The ESB provides a good "message oriented" way to visualisze a composite application, but business semantics are not described in messages, technology solutions are. Cohesions provide a standardised mechanism for associating messages (and processing of the messages) with business transactions - things like "place an order" that it doesn't take an IT expert to comprehend. Service-oriented architecture encourages us to build components in a loosely coupled fashion so that they can be combined in ways not thought of when they were initially created. Their loose coupling however is merely a technically loose coupling. The composite services are by definition coupled - why else does the business need invocations of the components to occur in sequence? The concept of cohesions provides a standardized way to identify the business semantics causing the message flow - it is this kind of information that will be needed for business activity monitoring at the business level (as opposed to message - flow spotting at the infrastructure level). With an ESB approach, this higher-level information is likely to be some kind of static commentary on a flow diagram, whereas a cohesions framework allows the information about the business semantics of each operation to flow dynamically with the messages that implement it, providing for better visibility into and management of the composite application system, not to mention the more traditional transaction-related business benefits of consistent recoverable outcomes thrown in for good measure. Maybe we had better watch out for the "enterprise transaction bus" appearing alongside the enterprise service bus. But that's the thing about buses. Never one when you want one, and then several arrive at once!

Transactions: Driving You to Distraction? Addenda!
In the May/June issue (Vol. 3, issue 5) of WLDJ, I wrote (after hearing the topic come up on numerous occasions, in many contexts) about the best choice of JDBC driver for use under WebLogic Server-based applications.

As every consultant tries to do, I hedged my bets and gave some good generic advice (namely, benchmark your application using the XA configuration you need for production to ensure that your exact setup will give the throughput you require from your application), but I also (after much hesitation and deliberation) came off the fence and gave specific advice: "with the technology where it is today, it seems safe to conclude that you should try to stick to the type 2 driver for XA database access, unless you have a pretty compelling reason to do otherwise."

I stand by that advice (and boy, am I glad that I included the "technology where it is today" caveat!!!), but needless to say, technology today isn't where technology was at the time of the copy date for the article!!!

A new driver came out of Oracle pretty much as my article left my laptop. That driver is the Oracle 10g thin driver. It supports versions of Oracle prior to 10g (as well, of course, as 10g itself); it's a type 4 driver so it doesn't need native libraries on the client, it supports XA. Not only does it support XA, but it does so without the overhead on database CPU consumption that the old thin drivers had in XA mode. Hallelujah!

So the new specific advice (what am I doing... I see another correction coming in the future!) is to take a long, hard look at the Oracle 10g thin driver as the way to access your database, especially if you're planning to use XA transactions. Not only can you use it in your own database access code, but this driver is supported by all the components of the WebLogic platform in WebLogic 8.1 service packs 2 and 3 (see http://e-docs.bea.com/platform/suppconfigs/ configs81/81_over/supported_db.html#1127404).

Now, back to drawing bubbles, clouds, and lines. Why is it my whiteboard architecture diagrams never have these problems?