Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1999-04-16
2003-10-14
Coulter, Kenneth R. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S202000, C709S203000, C709S220000, C709S223000, C709S225000, C709S226000, C709S241000, C717S127000, C717S131000, C717S154000, C370S351000
Reexamination Certificate
active
06633908
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the area of systems management. More particularly, the invention relates to means and a method for determining and managing application performance.
2. Description of the Related Art
Business applications today are critical elements of practically every business and organization. Determining whether these applications are functioning properly is the single most important issue for systems management. Many techniques have been created in host-centric environments to address this issue. Because of the rapid migration toward distributed applications, systems management vendors have begun to address distributed application performance with new techniques. There are mainly three approaches to systems management on the market, based on standards from Tivoli, Computer Associates and Microsoft. While all of these approaches can be perceived as defining an industry standard, the Tivoli approach is partially a de jure standard too (i.e. the systems management framework of Object Management Group (OMG)). Many systems management vendors support the Tivoli framework (called TME10) and its Application Management Specification (AMS). This specification enables a consistent development of management-ready applications.
AMS is complemented by the so-called Application Response Measurement (ARM) technique together with its application programming interface (API). The ARM API enables distributed applications to provide critical information about business transactions from the perspective of business operations. This API allows the development of distributed applications which pass information to the systems management environment, which is critical for performance management in terms of business operations. Based on this information, appropriate tools can measure service level agreements and signal early warnings of poor performance etc. in terms of business functions. With this information, systems management software can measure and report service level agreements, receive early warning of poor performance, notify operators or automation routines as soon as a transaction is not completing on time, and help isolate slowdowns. An overview on this technology is given in a white paper available from Tivoli via the Internet at http://www.tivoli.com/o_products/html/body_map_wp.html and incorporated herein by reference.
The monitoring of the status of an application takes place during runtime. Primarily it is used for performance measurement of key application transactions. Exploitation of this technology results in advantages in terms of usability and comprehensibility when compared with the corresponding monitoring capabilities available today for networks, database systems etc. As for providing the same information by other techniques, for example from reports describing network latency, response times, I/Os etc. for the various granular pieces of an application, it is very cumbersome (if possible at all) to derive data from them that can be used to prove the fulfillment of service level agreements between IT departments and their users.
Application response measurement technology assumes that the managed application is a self-instrumented component. This means that the application itself has to use the ARM API to exchange information with the systems management environment. This requires changes to existing applications or explicitly adding code to newly written applications. In spite the benefits of the application response measurement technology it currently will not be the complete solution for all situations, because it requires applications to be instrumented to invoke the API, which requires additional effort, and because the instrumentation is not always possible (the source code is owned by another organization or is no longer available etc.). As admitted by the providers of the technology, this will restrict the area of applicability of ARM. Especially the application provider has to decide which of the systems management environments to adhere to, which in the worst case means that he has to furnish for all of them.
The technology of invocation agents is offered within the area of application integration systems, which support the integration of applications, thus allowing the users to access these applications from a single environment. The integrated applications may even cooperate with one another. Also, depending on the capabilities of the application integration system, it may even support independently designed applications. Even different legacy applications, which have not been developed with the intention of cooperation, can work together through such an approach. Invocation agents can be found in a multitude of runtime environments like in workflow systems, in message brokers or component brokers (like the Common Object Request Broker Architecture (CORBA) standard from OMG ). Further information may be found for instance in the documentation for IBM's workflow system FlowMark available in every IBM sales office. Further information with respect to message and component brokers is given in R. Schulte, Message brokers: A focussed approach to application integration, Gartner Group, Strategic Analysis Report SSA R-401-102, 1996.
The main purpose of an invocation agent is to isolate the rest of the runtime components from the idiosyncrasies of invoking applications which implement the proper business functions. Especially, invocation agents prepare the input for an application as required, set the appropriate security context etc.
SUMMARY OF THE INVENTION
The invention is based on the objective to improve the exploitation of application response measurement technology for all kind of applications and all types of application response measurement systems. In particular the present invention is targeted at a reduction of the instrumentation effort allowing an application to participate within an application response measurement system.
These objectives are achieved by the present invention, which contemplates an invocation agent for invoking an application instance. The invocation agent comprises instrumentation means interacting with an application response measurement system (ARM) to provide response measurement on behalf of the application instance by the ARM.
Application Response Measurement (ARM) assumes that the managed application is a self-instrumented component. Normally this would mean that the application itself has to use the ARM API to exchange information with the systems management environment. Thus this would require invasive changes to existing applications or explicitly adding code to newly written applications. This additional effort would restrict the area of applicability of ARM. Especially the application provider has to decide which of the systems management environments to adhere to, which in the worst case means that he has to furnish for all of them. Even worse, the instrumentation is not always possible; the source code is owned by another organization or is no do longer available etc.
The present invention enables the management and measurement of application performance in systems management environments without special instrumentation of the corresponding applications.
The basic idea of the present invention is not to instrument the application components. The present invention contemplates instrumenting the invocation agent instead, which in turn is responsible for calling the application for execution. This solution provides application response measurement without any modification of the application being measured. As a consequence, no special code has to be added to newly or existing applications to enable them for response measurement. It is the invocation agent that makes the appropriate ARM calls to furnish the instrumentation on behalf of the application. Moreover, as the invocation agent is a generic component independent from the specific application, instrumentation of the invocation component has to take place only once and is available for all applic
Leymann Frank
Roller Dieter
Coulter Kenneth R.
Kinnaman, Jr. William A.
Nguyen Hai V.
LandOfFree
Enabling application response measurement does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Enabling application response measurement, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Enabling application response measurement will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3142187