ARM is an API jointly developed by an industry partnership that is used to monitor the availability and performance of applications. This monitoring is done from the perspective of the application itself, so it reflects those units of work that are important from the perspective of the business. The ARM standard is vendor-neutral and is targeted toward managing the performance of distributed applications.
One of the most difficult parts of an enterprise performance or capacity analyst's job is to characterize computer system and network resource consumption by a particular application or workload. The continuing movement towards distributed systems, especially the client/server model, has complicated this activity even more.
There are several ways transaction data has traditionally been collected on single systems:
Each of these methods has advantages but also has their shortcomings. The most obvious is that the transaction activity is captured in the context of the software layer measured, not necessarily relating to the business unit. When applied to the distributed environment, the biggest shortcoming for all current methods is the ability to track resource consumption by a transaction when several elements in a network (the client, server(s), LAN and WAN network components, message routing mechanisms, etc.) are contributing towards the completion of the transaction.
In June, 1996, Hewlett-Packard, Tivoli Systems, and other vendors, including SAS Institute, announced a collaboration to develop an open, vendor-neutral approach to manage the performance of distributed applications. The Application Response Measurement (ARM ) API, is an application programming interface for measuring end-to-end application response time. The ARM API allows vendors to create management-ready applications and it allows end users to measure and control the total performance of their business-critical distributed applications.
The ARM API is a simple API that applications can use to pass vital information about a transaction to an agent. Simplifying slightly, all the application has to do is call the ARM API just before a transaction (or a subtransaction) starts and then again just after it ends. The API is supported by an agent, which measures and monitors the transactions, and makes the information available to management applications.
The ARM calls identify the application, the transaction, and (optionally) the user, and provide the status of each transaction when it completes. This is sufficient information for the management solution to answer vital questions. Eliminating this guesswork helps both the users of the applications and the administrators responsible for making sure they are meeting the requirements of the business.
The ARM API can help answer the following questions:
The following links are two white papers that offer an overview of the ARM standard from a non-SAS perspective:
The primary drawback of the ARM solution is that users must put forth the effort to instrument their applications themselves. Sometimes, particularly when the application has been purchased or packaged from a vendor, the user does not have the means of embedding the ARM API calls in the code. This problem could be minimized if more vendors ARM-enabled their packaged software applications.
We at SAS have created the Scalability Community to make you aware of the connectivity and scalability features and enhancements that you can leverage for your SAS installation. The success of this community depends on you. Send electronic mail to email@example.com with your comments, requirements, and suggestions.