SOA Transactions

When it comes to monitoring your service-oriented architecture (SOA), the problem is that you typically have to do it in production, which means you have to rely on fake transactions – instead of on real SOA transactions. The result is that you never have a complete or clear picture of what's really going on with the various interdependent services, systems and processes in your environment. You need a clear view of all your Web services dependencies.

A typical multi-tier distributed application in a production environment, such as the one shown below, contains many moving parts. While many products exist that can report on the health of each individual application or machine in these types of environments, there are few effective approaches to determining the overall health of the business processes that flow through a network of connected systems. The most common approach to understanding the health of the overall system is via synthetic transactions. Synthetic transactions are essentially "fake" or "test" transactions generated by management products. These test transactions, usually submitted as web requests, are intended to mimic the typical actions of end-users and to see whether the results are as expected.

"Synthetic" SOA transactions have two limitations: (1) Complex transactions are hard to fake and (2) Problems tend to get hidden in the background.

Unfortunately, synthetic transactions have several critical limitations:

Complex SOA Transactions are Hard to Fake

The first is that often the most important transactions to measure are the hardest to fake. For example, in an ordering system, it's easy to test a "check order status" transaction, because doing so has no adverse effect on the system. However, testing a "submit order" transaction is entirely different. This transaction may perform third-party credit card validation, commit data to databases, and send requests to fulfillment systems. To truly test complex order submission processes of this kind, the order submission must be real (including real requests to the third parties to verify that they are also working correctly). Once the test order is submitted and verified, however, all of the actions that were triggered need to be rolled back so that the fake order is removed from all of the relevant systems. Correctly performing this type of compensation is quite complicated and very error prone.