Transactionality

Transactionality is mandatory for all application integration solutions for obvious reasons. We must ensure the delivery and processing of certain business information and, in doing so, need to support the notion of a transaction.

As we discussed above when considering connectivity, transactional application integration solutions require that complex applications be divided into bite-sized units called transactions. Transactionality controls transactions from their beginning to their end, from the client to the resource server and then back again.

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 Automic, Consistent, Isolated, and Durable.

Automic refers to the all-or-nothing quality of transactions. Either the transaction completes, or it does not. There is no available middle ground. Consistent refers to the fact that the system is always in a consistent state, regardless of whether it completes the transaction or not. Isolated refers to the transaction's ability to work independently of other transactions that may be running in the same TP monitor environment. Durable means that the transaction, once committed and complete, can survive system failures.

Although the ACID test might oversimplify the concept of a transaction in the context of connectivity, it provides an easy acronym for remembering the features and functions of transactional connections.

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

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 is that a transaction is always secure. Even when other things go wrong, transactional middleware won't allow those problems to affect any other transaction, application, or data.

To this end, we can divide transactions into three types, all mandatory: short-term, long-term, and state management.

Short-Term Transactions

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:

• These transactions are durable for a short period of time, typically less than a day.

• Small amounts of simple data such as invoices, SKUs, and customer data make up these types of transactions.

• These transactions are numerous, typically more than 1,000 an hour for many businesses.

Long-Term Transactions

Long-term transactions, in contrast to short-term, are durable for a long period of time, perhaps months or years. These transactions are more difficult to track due to the complexities of monitoring transactional conditions over such a duration. 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:

• They are durable for a long period of time, typically more than a day.

• They support complex data, perhaps tracking special metadata just for a particular transaction.

• They are few in number, typically less than 10 a day, and in some cases much fewer.

State Management

Finally, state management is another mandatory feature. This refers to the ability of the application integration solution 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, and making sure 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.