Emerging LinksEmerging Links

Remember transactions? They're still alive and well and running our businesses today. However, their use in the world of application integration isn't as well understood. Indeed, as you look to bind business services together, creating huge cross-organization processes without failure, transactions are the "go-to" enabling technology — either leveraged directly or embedded as an application integration product feature.

Clearly, transactions aren't for transaction servers anymore. Traditional application integration technology, such as integration servers, application servers, and even process integration technology have learned to leverage the notion of transactions and the goodness of this paradigm — rightfully so, considering the importance of an application integration infrastructure and its place in driving a real-time business that can't stop. In other words, organizations are creating the mother of all single-points-of-failure and must build application integration solutions with this in mind, using whatever mechanisms we need to ensure success.

In my opinion, transactions are mandatory for all application integration solutions for obvious reasons. We must ensure the delivery and processing of certain business information and invocation of services as well as support long running business processes, and, in doing so, we must support the notion of transactions.

"Mom, I'm on ACID"

Backing up just a bit, when considering one-to-one and many-to-many connectivity, transactional application integration solutions require that complex messages, processes, and service invocations be divided into bite-sized units called transactions. Transactional containers control transactions from their beginning to their end, from the client to the resource server (source and target systems), and then back again. However, transactions may also be made up of other transactions (a process known as nesting), creating overreaching complex business transactions in support of short- or long-term business processing. Transactions may also span different types of technology, and even across organizations and companies.

An easy way to remember the properties of a transaction is to put it to the "ACID" test. That is, a transaction has ACID properties if it is atomic, consistent, isolated, and durable.

Application integration architects can count on a high degree of application integrity with transactional connectivity — even in heterogeneous environments of very different operating systems and databases. The most important benefit of transactional middleware (application servers, TP monitors, or integration servers) is that a transaction is always secure. Even when other things go wrong, transactional middleware won't let those problems affect any other transaction, application, or data.

Building on ACID, I think there are three major advantages when you leverage transactions within your application integration infrastructure. I call them the "abilities," and they include scalability, durability, and predictability.

Transactions are scalable because they're able to take advantage of the underlying platform through the concept of resource sharing or multiplexing. Common integration mechanisms such as connectivity, routing, flow control, transformation, validation, and so on will all leverage memory, processor, and I/O services through a mechanism that allows for a more orderly sharing of these resources. This was the same trick we played back in the three-tier client/server days when we made thousands of users appear as a few users to a database server. Enhanced performance is another byproduct, allowing for hundreds of messages and service invocations to process each second, vs. the single digits if transactional mechanisms weren't in place. While this aspect of a transaction typically isn't visible to the user of the technology, it is nonetheless very important.

Transactions are durable (as discussed earlier) and provide you with a mechanism to maintain integrity during network and systems failures, which are problems we must deal with daily, especially considering extended application integration domains, such as supply chains. For example, a message in midflight from your SAP system to your mainframe doesn't get lost after a power failure and is recovered and re-sent to its destination. Or, multiple targets are updated as part of a transaction, or the entire transaction rolls back, never leaving any of the target systems in an unstable state or with erroneous information. Think of the havoc if durability mechanisms weren't built in.

Finally, predictability, perhaps building on the first two "abilities," means that you can pretty much tell when information will arrive and when services will invoke in support of business processes. Predictability is an important notion in the context of application integration because most inter- and intra-enterprise problem domains are more event-driven in nature. Not having predictable integration functions will typically cause a chain reaction up and down the event chain, stopping processing due to whatever type of human or machine error. The error causes the entire process to stall, perhaps halting the reordering of raw materials required to build parts, build a product, ship to a customer, or make your numbers. You get the idea.

Additionally, you must provide transactional control among systems that may not, unto themselves, support transactions. And, clearly, you must also provide support for transactions among systems that are transactional in nature and provide nesting transaction support and support for transactional standards such as two-phase commit.

What's Your Flavor?

Now that you understand the basics, you can further divide transactions in the world of application integration into two types: short-term and long-term.

Short-term transactions are typically business transactions with a short duration, such as purchasing a book online. The payment is made, the product is shipped, the accounting database is updated, and it's over.

Most transactions, as you may have guessed, are short-term transactions due to the nature of how we do business. These transactions have the following characteristics:

In contrast, long-term (or long-running) transactions are durable for long periods of time, perhaps months or years. These transactions are more difficult to track due to the complexities of monitoring transactional conditions over such long durations. Examples of long-term transactions are the construction of a house or office building or collaboration in the development of a product or service. These types of transactions have the following characteristics:

What's more, state management is needed for application integration solutions to track the current state of an application integration transaction through long- and short-term transactions.

State retention is important to application integration due to the number of integration transactions that may be running at an instance in time. It also needs to ensure that all sync points are recorded during the duration. Applications entering or exiting the transaction will have context as to how they participate in both the production and consumption of information as well as remote service management.

Transactionality is a key component of application integration. Its value, however, is not nearly as well understood or appreciated. As problem domains increasingly become more complex and far-reaching, you'll need to lean more on transactions as a core enabling technology.

David S. Linthicum is the author of three books on application integration, including Next Generation Application Integration: From Simple Information to Web Services (Addison-Wesley, 2003). He was CTO both for Mercator Software and SAGA Software, two application integration technology vendors.