Monitoring and testing middleware based application software

[0002] The invention relates to a method for on-line monitoring the behavior of middleware based, distributed application software during run-time of the latter software. The invention further relates to a method for on-line testing the behavior of middleware based, distributed application software during run-time of the latter software.

[0003] There is the need to perform monitoring and testing in several fields of applied technical environments, such as communications, in particular telecommunications, automation, and databases.

[0004] In the past, solutions for testing and monitoring were based purely on as the intellectual capacities of the developers and their ability to avoid and correct bugs. This ability was developed via experience. The time devoted to test, the complexity of the computer system, the heterogeneity of the architectures and system do not permit today to proceed as in the past.

[0005] With the coexistence of software (old and new versions, components from different retailers), there is also a need for continuous monitoring and testing of the behavior of a software.

[0006] A first aim of the invention is therefore to provide a method for on-line monitoring the behavior of middleware based, distributed application software during run-time thereof.

[0007] A second aim of the invention is to provide a method for on-line testing the behavior of middleware based, distributed application software during run-time thereof. According to the invention the first aim indicated above is achieved by a monitoring method comprising:

[0008] (a) defining events capturing the behavior of the software execution, said events being based on an abstraction of the application software, said abstraction being provided by said middleware,

[0009] (b) using code generating means and an instrumentation technique for automatically adding to the implementation of the software code suitable for generating traces suitable to be sent to an observer, the information carried by said added code including information on the order of occurrence of said events and on the software part location where each event occurs, and

[0010] (c) using a monitoring mechanism based on sending of trace reports to said observer which ensures or takes into account the time order of the reported traces.

[0011] In order to achieve the above objects, there is provided a method for spying on the distributed application, where the spying is performed on events occurring in the system, where a trace report of the detection of these events is sent to an Observer.

[0012] According to the invention the second aim indicated above is achieved by a testing method comprising:

[0013] (a) monitoring the behavior of said software during run-time thereof by means of a method according to the invention, and

[0014] (b) using a checking mechanism for checking whether said behavior is violating or has violated properties or constraints, said properties or constraints being dynamically defined at runtime by the user,

[0015] (c) expressing properties by the mean of the events that can be observed when the software application is running.

[0016] The main advantages of the methods according to the present invention include the following:

[0017] The instrumentation providing traces of relevant events is effected automatically.

[0018] The methods are independent of a choice of implementation language.

[0019] The methods make possible the monitoring and testing of an implementation still being developed or a final version thereof.

[0020] It is not necessary to specify the behavior of the entire system.

[0021] It is possible to focus the monitoring and testing only on specific part/behavior of the system

[0022] The methods are easy to use, even for a user not familiar with formal methods.

[0023] It is possible to configure the monitoring and testing dynamically at runtime.

[0024] Preferred embodiments of a monitoring method according to the invention comprise one or more of the following features:

[0025] Events capturing the behavior of the software execution, running on top of a middleware, are defined.

[0026] The defined events are generic for middleware softwares.

[0027] The defined events to be observed are selectable, and they are in particular selectable at run-time of the software being monitored, so that the set of events that can be monitored is dynamically configurable during said runtime.

[0028] The defined events are directly identifiable by the abstraction thereof provided by the middleware or by the interface definition language used, so that no other specification thereof in a different language is necessary.

[0029] The monitoring mechanism according to the invention is based on the sending of trace reports to a central or distributed observer.

[0030] The order of the reported traces is ensured.

[0031] The traces can be displayed in a graphical user interface and can also be stored, e.g. for post processing.

[0032] The monitoring method according to the invention makes use of an instrumentation technique that automatically adds code to the implementation of the distributed application software being tested, said code being such that traces of predefined events are sent to the observer. Since the latter instrumentation is performed automatically, there is no need of manual intervention of the user for this purpose.

[0033] The traces sent to the observer are preferably transmitted asynchronously,

[0034] displayed by means of a graphical user interface, the traces being represented by a time line, a table or a graph, and stored in a memory for post-processing.

[0035] The order of the reported events is reconstructed e.g. either by a logical clock system, a synchronization protocol, or the distributed processing environment.

[0036] Preferred embodiments of a testing method according to the invention comprise one or more of the following features:

[0037] Properties or constraints are expressed with events by means of a formal language, the expression of said properties or constraints being automatically translated into Finite State Machines or oracle, or some means derived therefrom.

[0038] The formal language allows the specification of temporal relations.

[0039] The formal language allows the specification of relations between events of same or different types, e.g. application events, error events and/or other events of interest for monitoring purposes (e.g. breakpoints), said events being directly identifiable by the abstraction thereof provided by the middleware or by the interface definition language used, and said events being selectable at run-time of the software being monitored.

[0040] The formal language allows the specification of procedural dependencies.

[0041] Properties are expressed independently from the implementation language at any of the following levels of granularity, at the level of: threads, a single object, a set of objects, the entire system, a variable of an object, an interface, a method.

[0042] Embodiment of methods according to the invention are described hereinafter with reference to the accompanying drawings in which:

[0043] FIG. 1 shows an overview of a typical development process of distributed applications in the middleware CORBA (Common Object Request Broker Architecture) framework.

[0044] FIG. 2 shows an example of an overall monitoring and testing scenario according to the invention.

[0045] The invention is now described hereinafter in terms of its preferred embodiments with reference to the accompanying drawings. These embodiments are set forth to aid in the understanding of the invention, but are not to be construed as limiting.

[0046] FIG. 1 shows an overview of a typical development process of distributed applications in the CORBA (Common Object Request Broker Architecture) framework. The white boxes depict the normal development process of distributed applications; the gray boxes describe the extensions proposed in this paper. Rounded boxes denote tools. Development at level 11 is independent from the platform and from the implementation language. Development at level 12 is dependent from the platform and from the implementation language.

[0047] During the development process of a distributed application, the IDL (Interface Definition Language) specification 13 of the interfaces is passed to an IDL compiler 14 associated with the middleware which generates stub code and header files 15 which are then linked to the actual implementation code by a compiler/linker 17 thereby shielding the developer of the distributed application from the difficult task of handling the distribution issues.

[0048] In addition to passing the IDL specifications to the IDL compiler, those specifications are sent to a code generator tool 22. This code generator tool 22 generates generic observation code 23 which will be linked to the actual implementation and form the instrumentation part of the implementation 18 with on-line Observation and Validation. When the implementation is running, this instrumentation will generate traces. The trace generation machinery is automatically added by code generator tool 22. The trace generation machinery is configured dynamically by the user, thus making possible to dynamically change the traces to be collected. The approach for instrumenting the code in a method according to the invention is presented in Section 1 hereinafter.

[0049] The traces sent by the instrumentations are collected by an observer 24. By using the operations available at its interface, objects can report the event-occurrences to the observer. It is therefore irrelevant that the implementation of the Observer is written in the same implementation language as the distributed application. This means that the code generator introducing the trace generation mechanism is the only part that depends on the implementation language used for developing the application.

[0050] The architecture of the observer is divided into two parts:

[0051] The monitoring part is concerned with the activation and parameterization of the instrumentation added in each object, and the handling of the traces. The Monitoring part activates and parameterizes the instrumentation of the object, so that they report only specific event-occurrences. The Monitoring part is described in detail in Section 2 hereinafter.

[0052] The testing part interprets and transforms the properties into executable code via the transformation into Finite State Machines (FSMs). During this process, it also identifies the events that are involved for the testing of the property and dynamically gives the parameterized and activation information to the Monitoring part. Finally, at run-time the traces are used for checking whether a violation of the properties takes place. When a property is violated, an error is discovered. The Testing part is described in detail in Section 3 hereinafter.

[0053] An example of an overall monitoring and testing scenario according to the invention for the case of a simple client-server application is depicted in FIG. 2. As shown by this figure in such an scenario a user 30 has basically to do with a system comprising a client 33, a server 34 and an observer 31 which is a software for monitoring and testing. Client 33 has e.g. an object 36. Server 34 has e.g. objects 37 and 38. Observer 31 comprises a monitoring part 35 and a testing part 40. Monitoring part 35 contains a properties translator 41 and an observation manager 42. Testing Part 40 contains a properties checker 43 and an error handler 45. The abstraction level that is provided by an IDL specification in the case of CORBA or any other interface definition language is such that it is an excellent source for expressing properties, e.g. property 51 in FIG. 2. Such properties are entered by user 30 via a graphical user interface 53 and then translated into a FSM by properties translator 41. Each property 51 is analyzed and observation manager 42 is informed of what information is to be monitored. Observation manager 42 parameterizes the instrumentations, which are the interceptors 52, 54, 55, 56, 57 within system 32. Up to this point, system 32 is configured to send notifications to the monitoring part 35 of observer 31 each time a relevant event occurs in system 32. Observation manager 42 encompasses a mechanism 46 ensuring a consistent order of the notifications received. The information sent via the notifications can be displayed by means of graphical user interface 53 and can also be stored in a suitable storage or recording mechanism 48 for post-processing. Observation manager 42 transmits the monitored information to the testing part 40 which carries out a check for violation of behavioral constraints by means of properties checker 43. For this purpose, the state of each Finite State Machine (FSM) 47 in properties checker 43 is updated to reflect the new global state of the system 32 under test. Whenever testing part 40 finds a property violation, testing part 40 transmits this information to error handler 45, where an error message is displayed on the screen of graphical user interface 53. In summary, the only action that user 30 has to perform is to enter specific properties by means of graphical user interface 53, said properties being entered dynamically at runtime; the remaining work, including the instrumentation, is done automatically.

[0054] Within the scope of the invention, properties can be expressed at different levels of granularity: properties on threads, on single objects, properties involving clusters of objects, properties representing specific behavior of an entire application. When expressing properties the user can concentrate on a selected set of constraints that he expects to be exhibited by the system; it is not necessary to specify the behavior of the entire system.

[0055] In order to monitor the events happening in the system, it is useful to be able to interpose a mechanism on the invocation (and response) path(s) between a client and a server. For example, in the CORBA middleware specification, there is a standardized notion that can be used for precisely this purpose: the Interceptors.

[0056] Within the scope of the invention the assumption is made that a run-time observation mechanism, that is called “Filter” hereinafter, is provided by the distributed platform. This assumption is not restrictive: in the case where such a mechanism is not offered by the distributed platform, a proxy object that plays the role of the Filter can be added for each object within the system.

[0057] The breakpoints provided by the Filters are used to send traces to the Observer. Filters are put in each object but activated and parameterized only as needed, thus, optimizing the number of traces generated and minimizing the intrusive impact on the system. The functionality of the code added in each Filter encompasses:

[0058] a notification mechanism which is exactly the same for each object of the system. A notification is an operation carrying the trace generated invoked on the Observer. A preferred embodiment of the invention uses an asynchronous reporting method (as opposed to a synchronous method). It minimizes the impact of the monitoring mechanism on the system; the processing power of the Observer does not affect the computation rapidity of the application

[0059] a selection mechanism which allows selecting specific data to be monitored per object. This selection mechanism is based on an operation select} that is offered by each object (via its Filter), and a table containing all the data that can be monitored on the object. A special field is reserved for marking if a data ha s to be monitored.

[0060] some specific code that guarantees the causal dependencies (order) of notifications. This mechanism is presented in the following section.

[0061] In general, it cannot be assumed that the middleware guarantees that the Observer will receive the notifications in the same order in which they have been sent. Therefore, the establishment of the “true” order of the events is mandatory in order to be able to follow what happened in the system.

[0062] The system of logical clocks is used to preserve the causal ordering of notifications. Causal ordering is the natural extension of FIFO (first in first out) ordering in the case of more then one sender and receiver.

[0063] The algorithm used to reconstruct the causal ordering of notifications is based on the so called RST algorithm (called so after the names of its authors Raynal, Schiper and Toueng, as in the publication: Raynal Michel, Schiper Andre and Toueng Sam “The causal ordering abstraction and a simple way to implement it” in Information Processing Letters, vol 39, pp 343-350, 1991). This algorithm is only used to ensure that the causal ordering can be reconstructed at the Observer site. Each object of the system is associated with a vector timestamp. Each element of the timestamp is a pair where the first element is the object identifier of the object sending the notification hereinafter called object A and the second element is the number of notifications sent to the observer by object A as known by each other object of the system.

[0064] The number of notifications sent by each object is propagated through the system by piggybacking the time-stamp with the requests. The size of the timestamp is equivalent to the number of objects in the system. As the number of objects in the system evolutes (depending on the creation and deletion of objects) the algorithm used within the scope of the invention is capable of maintaining a dynamically sized time-stamp.

[0065] The formalism used to express properties is Linear Time Temporal logic (LTL). Unlike other proposal in the domain of specification-based testing, within the scope of the invention properties are not restricted to safety formula.

[0066] In order to be checked at run-time, the LTL properties have to be translated into some machine readable form. Different approaches, well known in the literature and tools are available for translating LTL formula into FSMs.

[0067] The invention has several domains of applicability, generally being those in which the testing software is crucial, and in particular when this testing must be performed on the real implementation rather than on an abstract model of the implementation, and where the software are built by the use of a middleware, for example:

[0068] development of communication softwares (as in the publication: X. Logean, F. Dietrich, J.-P. Hubaux, S. Grisouard, P.-A. Etique “On applying formal techniques to the development of hybrid services: challenges and directions”, in IEEE communication magazine, July 1999),

[0069] detection of feature interaction in communication systems,

[0070] development of Internet software (e.g., electronic Banking, electronic Commerce),

[0071] development of multimedia application (e.g., videoconference),

[0072] development of large distributed software (e.g., automation, network management, database management)

[0073] supervision of softwares (e.g., to dynamically add new alarms to be raised at runtime, without modifying the implementation code of the software, e.g., for the supervision of hardware equipments by their software).

[0074] The invention has been described with reference to specifically preferred embodiments. Additional embodiments within the skill of an artisan and the spirit of the invention are contemplated and intended to be included within the inventive concept.