The Evolution of Business Transaction Management - Part II

Business Transaction Management (BTM) is a natural continuation of the past decade and a half’s evolution of IT systems management. In the past few years, the modern data center has finally started to stabilize; the number of “node types” seems to be stabilizing and each node has had tools developed for it.

It seems that distributed systems are not going to see any additional “node types” on top of today’s proxies, web servers, application servers, databases, message brokers and storage anytime soon. Not to undermine the complexity of service oriented architectures, but as far as solving the problem of tracking transactions is concerned, it seems that things are stabilizing enough to enable a viable solution.

These silo-specific tools are now able to solve 90% of the problems; leaving IT departements with the hardest to solve – the last ten percent. This last ten percent is characterized, for example, by those application bottlenecks that occur even though all of the silo-specific tools are showing 100% availability. Traditional monitoring tools struggle to obtain good response time metrics outside of the mainframe. Simply locating the source of the latency is usually the longest step towards resolution when dealing with mission critical incidents.

If the monitoring tools at all tiers are showing 100% availability then how does one know that there is a problem? Either the enterprise has put in place an end user measurement tool or the help desk is receiving user complaints.

The IT organization’s number one priority is very simple; ensure that all transactions are executing correctly and in a timely manner – it’s that simple.

The demand for Business Transaction Management tools comes from that kind of an issue, where service is not acceptable, but current tools fail to show it. What has enabled the development of these Business Transaction Management tools is the datacenter’s recent stabilization; with the number of node types staying constant for a few years, it is finally possible to catch up and enable full visibility into the entire datacenter; this is what BTM solutions must provide.

BTM Enables True Availability

The only way to resolve the problems that traditional monitoring tools cannot cope with is to take into account the interactions between the nodes and to connect every click of the user to the many events that are triggered by that activation. This enables both being able to see everything in the business context - the user’s click of a button - and solving problems where the symptom and cause are located at different tiers. For example; IBM Websphere Portal v5.1.1 had a bug where the internal caching wasn’t working properly which caused the server to send out 15,000 SQL statements a second to DB2, causing the database to overload and provide poor response times.

Business Transaction Management tools are able to monitor the entire system by tracking every single transaction that is activated by the users throughout the entire datacenter, collecting information on all of the interactions along the way. This is the essence of connecting business and IT; understanding the business context by linking every single event in the datacenter to the click of a user.

With Business Transaction Management, a common language is created, where performance can be measured as the time it takes for the transaction to travel between all of the nodes and back. Since all interactions are recorded along the way, if something goes wrong, i.e. a latency that is out of specification, then the event that caused the problem can be immediately singled out since the latencies at each tier are known and all of the necessary data has been collected.

What Qualifies as a BTM Solution?

Every Business Transaction Management solution should be able to do the following: Track a transaction that was sent out from a browser, through a load balancer and to a proxy. Let's say that this proxy is not a known vendor’s proxy, but instead one developed by a start-up. The code is still there and still working, but no one has the code - just the binary.

The proxy is sending the work to another proxy and the transaction is split across two different applications, each with its own different web server. Each application is running on its own app server - one is java-based, the other is not; it’s a homegrown C++ program. The first app server is sending out database requests to four different databases: Oracle, DB2, Sybase and SQL server. The second app server is SOAP-based, sending SOAP requests to an external application. There is an MQ at the external application, ‘puts’ are being sent to the MQ and a Mainframe is receiving the messages from the MQ.    

If a vendor wants to be called a BTM vendor they has to be able to track the transaction across all of these components. They have to be able to account for the time every transaction spends at every point in the datacenter.

Developing a Business Transaction Management Solution

Developing this kind of solution is far from trivial. The task of connecting each event within the datacenter to a specific transaction is a big challenge in today’s distributed and heterogeneous systems.

The general concept of how to execute a Business Transaction Management solution is pretty straight forward. Agents must be installed at all tiers, collecting information about everything that flows through that particular tier and all of the collected data is sent back to a central dedicated server that is able to correlate all of the events to the single user’s click of a button in the application. The various methods of gluing these events together are the core competency of the solution, along with the ability to develop an agent that complies with all of the different kinds of servers that one finds in the data center.

Many BTM solutions on the market today include some of the essential elements but fail to truly glue all of the necessary pieces together. All too often these products:

• Introduce too much overhead when intercepting transaction segments at different tiers making it impossible to continuously capture all transactions in the production environment
• Lack coverage for all of the various tiers; web servers, non-J2EE/.NET application servers, message brokers, databases and mainframes
• Are unable to correlate between the various hops that a transaction makes through the datacenter which greatly reduces the value of transaction monitoring and limits it to individual silos
• Are too invasive for many enterprises to adopt; require code changes and long implementation times
• Are unable to break down the response time that the user sees into; browser rendering time, network time and the time spent at the various tiers within the datacenter

SharePath from Correlsense is designed to solve these problems. Not only does it capture all of the relevant transaction data but it presents the data in usable graphs with tools that immediately convey specific IT department actions to solve the current problem.