ARM

 
The ARM API offers many benefits to a manager who needs to monitor the response times of applications: The most important factor is its openness. Resulting from a joint initiative of 15 companies, it offers a well defined interface that can be used either by application developers or by management tool vendors. Applications instrumented with the API calls will work seamlessly with management tools from various manufacturers (e.g. Tivoli Application Performance Management (TAPM) or HP MeasureWare/PerfView). However, it is also general enough to allow sufficient differentiation between management solutions from different vendors. Its adoption as a standard by the Open Group further strengthens its position as the predominant standard for response time measurement. Another important fact is its simplicity and efficiency. There are not more than six calls to be used. Technically it is very easy to instrument an application using these calls and it is also relatively easy to provide a measurement agent that implements the calls. Depending on the amount of processing the measurement agent does, it affects system performance only to a minimal level. A further benefit is the way transactions are defined. Even in a highly distributed environment it is easy to monitor the transactions a user is aware of. Users are not interested in certain parts of the transactions but in the total amount of time from their request to the reception of the response. Through the concept of subtransactions, managers still have the chance to find out which part of the transaction is responsible when performance problems occur.

However, the ARM API still comes with a lot of problems: Obviously, the first to mention is the need for instrumented applications. Today most commercially available applications are not instrumented. As normally no source code is available it is also impossible to instrument these applications on your own. Even if the source code is provided it is a difficult and time consuming task because the business transactions seen by the user must be identified in the code, which requires expert knowledge of the implementation. When using transaction correlation, the correlator received by the measurement agent must be known to the subtransactions. In a distributed environment this requires changes to the applications because the correlators have to be passed explicitly as parameters when calling the server component.