Patent Application
20060129995
One or more embodiments of the invention relate generally to the field of multi-layered application program. More particularly, one embodiment relates to a method and apparatus for observing runtime behavior of an application program.
Advanced application programs may be formed by using multiple application layers. To achieve desired application program functionality, each application layer is assigned a specific responsibility. Some common examples of application layers of a multi-layer application include a database layer, a network interaction layer, an application layer, a user interface layer and the like.
Currently, secure software engineering research exists for describing and enforcing fine-grained access control policies in distributed as well as multi-layered environments. Such research enables the design of multi-layer applications, such as, for example, a three-layer application including a workflow layer, an application layer and a database layer. For each layer, specification of access control is required, such that the three different access control policies can map together to ensure a secure application.
As indicated above, to achieve application program functionality, the layers are generally required to interact with one another. Most interaction adheres to one pattern: methods of the upper layer petition services of the lower layer with returned information from the lower layer flowing upwards to the upper layers. As described herein, the issuance of a call, such as, for example, within a method or other programming language terminology to specify a block of code, such as, for example, a method, a function, a procedure or other like terminology, including a statement or call directed to some lower layer resource, is described herein as a “downcall.” Generally, determining information on which downcalls invoke critical methods or procedures, is performed by manually reading through the multi-layered application program code.
The various embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
In the following description, certain terminology is used to describe features of the invention. For example, the term “logic” is representative of hardware and/or software configured to perform one or more functions. For instance, examples of “hardware” include, but are not limited or restricted to, an integrated circuit, a finite state machine or even combinatorial logical. The integrated circuit may take the form of a processor such as a microprocessor, application specific integrated circuit, a digital signal processor, a micro-controller, or the like.
An example of “software” includes executable code in the form of an application, an applet, a routine or even a series of instructions. The software may be stored in any type of computer or machine readable medium such as a programmable electronic circuit, a semiconductor memory device inclusive of volatile memory (e.g., random access memory, etc.) and/or non-volatile memory (e.g., any type of read-only memory “ROM,” flash memory), a floppy diskette, an optical disk (e.g., compact disk or digital video disk “DVD”), a hard drive disk, tape, or the like.
System
The system memory 130 may include high speed, temporary memory that is used by execution unit 170 to store frequently and/or recently used information for processor 110. As described herein, system memory 130 includes but is not limited to solid state memories, random access memory (RAM), non-volatile RAM (NVRAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double rate (DDR) SDRAM, Rambus DRAM (RDRAM) or any device capable of supporting high speed buffering of data. In one embodiment, data storage device 108 includes one or more hard disks, floppy disks, ZIP disks, magnetic random access memory (MRAM) devices, and other system readable media that store instructions and/or data. Data storage device 108 may store program modules such as routines, programs, objects, images, data structures, program data, and other program modules that perform particular tasks or implement particular abstract data types that facilitate system use.
In one embodiment, execution unit 170 operates on image/video data according to the instructions received by processor 110. Execution unit 170 also operates on packed, floating-point and scalar data according to instructions implemented in general-purpose processors. In some embodiments, processor 110 may be an Intel 32-bit (IA-32) architecture. In another embodiment, the processor may have an Advanced Micro Devices 64-bit (AMD-64) architecture, an Intel EM64T architecture or an Intel IA-64 architecture that executes IA-32 code. The foregoing implies that the processor may use an IA-32 instruction set or an AMD-64 instruction set, respectively. In another embodiment, the processor 110 may be any processor that executes machine code generated from a Java compiler.
In one embodiment, configuration manager 230 abstracts configuration settings for IPE 140. Such abstractions may include at least one program target 290, an input program path, a report format and other like information required to enable observation of an input program runtime behavior. In one embodiment, application runner interface 220 utilizes configuration interface 231 to determine where the input program or application is located. In one embodiment, this interface obstructs the processes needed to initialize and launch the desired type of program.
Representatively, the downcall sniffer 200 extracts a report on all downcalls issued by a procedure function, method or other like program construct, referred to herein as “calling methods” in the input application, which issue a call or invoke a method, procedure or the like block of program code offered by an underlying layer and specifically, the target 290. The target, or method looked for (“called methods”) should not be hard coded, such that users should be able to check which methods to look for at launch time. Accordingly, in one embodiment, for each detected downcall 310, report 301 lists the signature of the calling method, the signature of the called method and the arguments passed to the calling method. In one embodiment, this output is provided as an XML format, as shown in Table 1.
Referring again to
As described above, calling method 340 is a method which calls the target method, so one level down the stack trace viewed from the calling method point of view. Called method 330 is a method calling the body of another method, the calling method, and downcall 310 is a call to a method from within the body of another method and lists the calling method and the called method as its properties. The object from which the call originates is the object of the calling method. In one embodiment, this information, along with a stack trace (defined herein as a succession of method calls beginning at an upper program layer and terminating at the called method, or target) are provided in report 301.
In one embodiment, the downcall sniffer module 200 is a modular tool, which examines a given application using aspect-oriented programming to observe the behavior of a running input program 142. Accordingly, in one embodiment, using aspect-oriented programming (AOP), at least one aspect is created to detect targeted downcalls 310. Once the at least one aspect is provided, advice is added to the targeted methods to export detected downcalls to a report 310.
Accordingly, in one embodiment, behavior sniffing aspects are first weaved into the existing code, then the application is launched to test every course of action within the input program. Finally, report 301 is generated to automatically provide detected downcalls 310. In one embodiment, a point cut is added to each method within the input program. Accordingly, for each method invocation issued by a method within the input program, advice is added to the point cut to compare the method invocation against the program target 290, such that when a downcall 310 is detected, the advice exports the detected downcall 310 to a report output file 301.
In one embodiment, sniffer 210 registers all downcalls directed to a certain program target in the input application. Once detected, report generator factory 272 generates a report, including all downcalls, based on an output type 280. Accordingly, downcall sniffer module 200 may be comprised of three components, in accordance with one embodiment. Such components may include behavior sniffer module 210, which performs the actual sniffing tasks, a report generating component 272 for providing a listing of detected downcalls and a runner component 250 for handling the running of the input program.
Configuration interface 231 (See,
(1) gettarget. This method returns a target object describing the called method for which the downcalls should be extracted;
(2) getoutput type. This method returns an output type object encapsulating the type of output, which is expected.
(3) getapplication type. This method returns an application type object encapsulating the type of application to be examined;
(4) getapplication location. This method returns an application location object encapsulating the path to the executable application code to run.
In operation configuration manager 230 expects a configuration file to be present in the default path for example, as shown in Table 2. Representatively, configuration manager 231 abstracts the fetching of configuration settings.
Finally,
In one embodiment, the AOP approach also allows the detection of parameters passed during the execution of the application, which is generally information that cannot be extracted at runtime. In one embodiment, such information may be used for redesigning an existing application for improving, for example, security or manageability, which is greatly simplified if the application can be scanned, as described herein. For example, if one would like to enforce security policies to a certain type of method, the downcall report can point out where all those method calls occur (in which higher level calls invoked in). As a result, adding security functionality on the appropriate locations is only a matter of describing the target and adding the functionality, while avoiding an extensive study of the source code.
Several aspects of one implementation of the downcall sniffer for providing a report including detected downcalls have been described. However, various implementations of the downcall sniffer provide numerous features including, complementing, supplementing, and/or replacing the features described above. Features can be implemented for downcall detection within a multi-layered application or for a distributed application in different embodiment implementations. In addition, the foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the embodiments of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the embodiments of the invention.
In addition, although an embodiment described herein is directed to a downcall detection, it will be appreciated by those skilled in the art that the embodiments of the present invention can be applied to other systems. In fact, systems for generating test data to invoke each method within an application fall within the embodiments of the present invention, as defined by the appended claims. The embodiments described above were chosen and described in order to best explain the principles of the embodiments of the invention and its practical applications. These embodiments were chosen to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.
It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this disclosure is illustrative only. In some cases, certain subassemblies are only described in detail with one such embodiment. Nevertheless, it is recognized and intended that such subassemblies may be used in other embodiments of the invention. Changes may be made in detail, especially matters of structure and management of parts within the principles of the embodiments to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.
Having disclosed exemplary embodiments and the best mode, modifications and variations may be made to the disclosed embodiments while remaining within the scope of the embodiments of the invention as defined by the following claims.
