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. However, it is also general enough to allow sufficient differentiation between management solution from different vendors. Its adoption as a standard by the Open Group further strengthens its position as the one 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 its 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. The NULL library allows applications to run as if they were not instrumented at all.
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 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.
Another problem is the use of fixed data structures. As mentioned above information about the currently running transaction can be included in the API calls. However, the type of data is predefined to a maximum of six numerical values and a string of length 32. In our implementation this caused a problem because it was necessary to include the URL of the requested page into the packet, which often exceeds a length of 32 characters. By using arm_update this problem could be avoided, because it allows to include up to 1020 bytes of unstructured data.
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.