Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-06-08
2001-12-04
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
Reexamination Certificate
active
06327700
ABSTRACT:
TECHNICAL FIELD
The present invention relates to techniques for measuring the response time and other parameters related to processing of transactions by computer programs and, in particular, to a method and system for determining a set of locations within a computer program that are executed during processing of a particular transaction and that thus comprise a witness set for the transaction.
BACKGROUND OF THE INVENTION
During the past thirty-five years, advancements in computer hardware and programming methodologies have fuelled the development of increasingly useful and complex computer-based tools for automating business processes. Currently, both custom-built and commodity computer programs are pervasive in both small and large businesses. Computer programs manage information, including inventory control data, employee data, customer data, and financial data. Computer programs also manage business transactions, such as airline reservation systems and automated order entry, and may even provide a large portion of the business interface between a business and people who interact with the business, such as the web pages of an Internet-based business or automated telephone order-entry systems.
Computer programs, whether used internally within a business, used as a portion of an interface between the business and customers or suppliers, used for supporting general computational tasks, used for conducting scientific analyses or data processing, or for many other reasons, can be considered to be transaction processing systems. For example, an airline reservation system processes flight schedule requests, seat availability requests, and reservation requests. As another example, an order entry system may process submitted order forms. As still another example, an operating system may process an internally generated request to read a block of data from a mass storage device. Transactions are generally defined to have a starting point, often corresponding to the input of data into the computer system, and an ending point corresponding to the completion of a set of related activities, or functions, that together comprise a logical operation. For example, in an airline reservation system, a reservation request transaction may be defined to start with a travel agent inputting, through a graphical user interface (“GUI”), a combination of keystrokes or mouse clicks that indicate to the airline reservation system the beginning of a request for reservation of one or more seats on a future flight. Starting from the initial input by the travel agent, the airline reservation system conducts numerous related operations in order to make a reservation, and finally displays to the GUI an indication that the reservation has been successfully completed, a logical point to define as the ending point of the transaction. The related set of operations conducted by the airline reservation system in order to carry out the transaction may include solicitation and processing of additional input information, such as the customer's name, time of travel, etc., searching a database, based on the input information, for stored data representing the desired flight, checking whether the requested number of seats are available, and updating the stored data to reflect the reservation. The processing of a single transaction by a computer program may involve execution of hundreds or thousands of software routines and millions of computer instructions.
A transaction is the execution of a particular group of instructions by a computer program that have an identifiable effect on some aspect of the environment in which the computer program is running. While many logical transactions that may be defined in the context of a business application program may correspond to business transactions having certain well-known data integrity properties, many other logical transaction are unrelated to business transactions. For example, the detection of a hardware event within a computer system by an operating system and handling of the detected event through one or more subroutine calls may constitute a logical transaction within the context of an operating system program.
Computer programs are continuously subjected to monitoring of various parameters and are regularly refined and redeveloped in accordance with the results of the monitoring. One important parameter is the response time with which a computer program processes a given type of transaction, or, in other words, the time between the start of the transaction and the end of the transaction. Various types of response times may be measured. For example, the total wall clock time of the transaction is often a useful parameter for efficiency studies. The difference of the wall clock time of the transaction and that period of time within the transaction during which the computer program waits for user input may, in some cases, be a more useful parameter. Various statistical measurements of response times, including the variance and standard deviations of different types of response times may also be useful. Another useful parameter is a count of the number of times a particular transaction occurs, and, in some cases, an indication of whether a particular transaction does or does not occur. Such information may allow the usage of various software components to be monitored.
There are a number of different approaches for measuring the different types of response times. Manual methods may involve human observers recording response times using a stopwatch, pencil, and paper. In certain specific types of computer programs, notably database management systems, partially and fully automated techniques may be employed in order to collect large amounts of performance data and efficiently process those large amounts of performance data. These semi-automated and fully automated methods rely on incorporating data collection functionality into computer programs. A standard for instrumenting computer programs for automatic collection of response time data, called the Application Response Measurement (“ARM”) interface, has been developed. The ARM interface is an application programming interface (“API”) comprising a set of functions that can be called from within a computer program. Using the ARM API, functions can be called to identify the starting and ending points of transactions and to measure the response times associated with execution or processing of each transaction. Thus, the ARM API is a high-level programming interface, and the functions within that interface are incorporated within the high-level programming language description of a computer program in order to instrument the computer program for subsequent performance monitoring. Additional APIs for monitoring computer programs include the Simple Network Management Protocol (“SNMP”) API and the Remote Management (“RMON”) API.
The approach represented by the ARM API has many deficiencies. Specific deficiencies of the ARM API include a flat name space for transactions and a requirement that a computer program have a single starting and stopping point with respect to the ARM API. Unfortunately, modem computer programs tend to be extremely large, complex systems developed by large, hierarchically-ordered teams of software developers and engineers. In such a development environment, a flat name space for transaction names becomes a difficult problem, requiring a coordinated effort for partitioning the flat name space among the various groups and subgroups of developers and engineers. Because various groups of developers and engineers may work more or less independently on portions of a computer program, the single starting point and stopping point requirement of the ARM API may introduce additional coordination problems when separately developed portions of a computer program are merged together.
There are more fundamental problems with the instrumentation approach represented by the ARM API. Generally, developers and engineers are concerned with the functionality and correctness of that portion of the API that they develop. T
Bershad Brian N.
Chen J. Bradley
Appliant Corporation
Powell Mark R.
Summit Law Group PLLC
Zhen Wei
LandOfFree
Method and system for identifying instrumentation targets in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for identifying instrumentation targets in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for identifying instrumentation targets in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2602425