This article introduces a new form of analysis for Java EE applications: a runtime abstract application model derived automatically from an application server using stored knowledge of Java EE construction. The model is used dynamically to perform extensive, automatic checks for a range of construction errors that could produce poor performance or unreliability. The model also allows server behavior to be dynamically visualized, in real time or retrospectively.
A lot of attention has been given recently to the topic of Model Driven Architecture (MDA), which aims to create working systems by generating source code from successively transformed high-level component models. While doubts have been cast on the real-world robustness of this idea, and previous code-generation solutions have not been a big success, the possibility of working with software at a more abstract level holds a strong appeal for engineers.
Although the inauspicious history of CASE tools suggests making a project dependent on model-driven code generation could be limiting, the central tenet of MDA—the ability to view and analyze our application at an abstract level—is a powerful and attractive goal. Even if our application grew beyond an initial set of predefined patterns and code templates we still would like to be able to validate and understand it based on a design-level description of its operation.
If we don't have a predefined model, how are we going to get one? Well, if you try to describe your application to someone else you will almost certainly use architecture-level abstractions: the services it uses; the main business and data components; and how these relate. So it would be good if similar high-level abstractions could be derived and presented automatically by analyzing and monitoring the execution of your application. Model elements would include application components, the application server services they use, and data access, transaction management, and calling relationships between these.
Once application model elements were identified they would be updated dynamically during execution. Monitoring the changing patterns of inter-relationships in the model would allow the automatic detection of construction quality problems by detecting unlikely relationships, unnecessary and duplicated relationships, and undesirable model entity states. Instead of trying to spot problems in the clutter of source code we could observe key abstractions directly in the model.
eoLogic named this form of indirect application monitoring Derived Model Analysis (DMA): tools analyze Java EE applications both statically and during server execution to derive an abstract model, which includes both application components and Java EE services. Subsequent changes to the model form a dynamic event sequence that can be used to (a) track and validate application execution, and (b) visualize the model. Lower-level application execution details can be recorded in the context of the sequence of model changes.
Note that DMA is not a profiling technique; it doesn't aim to identify current code hotspots. Instead, it analyzes how services have been constructed and are being used. The aim is to identify places where hotspots or unreliability may occur under load. This deeper form of analysis can be applied to find problems before they manifest themselves and without requiring the application to be loaded during testing. These problems include incorrect or inefficient transaction grouping, inefficient database access, unreliable sequences of inter-component communication, and failure to control service lifecycles correctly. There is no need to drive the application to a point at which it exhibits slowdown, and the results need little interpretation.
To generate and validate an abstract model of an application a tool must be able to monitor events within the server and interpret these in light of relevant stored knowledge. This includes definitions of the main abstract entities we are interested in (transaction manager, transaction resources, transactions, EJB containers, JMS Destinations), the possible relationships between these entities, and invalid and valid patterns of relationships and states. DMA forms these into an abstract Entity-Relationship-Attribute (ERA) model as the system executes, with model changes triggering annotated definitions of problem states.
The model sounds a lot like Java Management Extensions (JMX) —which essentially defines a form of abstract model for the purposes of managing and monitoring Java applications, and it suggests DMA possibly could be layered on top of the information available from JMX MBeans. In detail, what characteristics does a DMA model require?
JMX goes some way toward what is needed: It provides an abstract model of an application for both its static and dynamic aspects; it allows easy selection of MBeans; many MBeans relate directly to easily understood aspects of server operation; there is a notification system for attribute changes and there is even an MBean relation service.
However, for our purposes it also has some serious limitations: Many of the relationships we need to monitor are based on calling sequences and application component relationships. Designed primarily for system management and threshold monitoring, JMX does not provide the source-level monitoring and mapping that the detection and (especially) the explanation of application construction errors requires. Also, the level of coverage is generally insufficiently detailed to provide a coherent execution model for the purposes of visualization. And if we wish to use the product to investigate problems requiring the ability to freeze the server at the point of problem detection and extract stack and related data information then JMX isn't precise enough.
So the approach we adopted is to create a more detailed runtime ERA model specialized for the following purposes:
This specialized model then provides the structure for attaching knowledge about model entity roles and valid and invalid patterns of model relationships and attributes, together with details on problem descriptions and suggested fixes.
The need for detailed tracking of calls and object states means the DMA engine moves from the realm of JMX more towards an application of Aspect-Oriented Programming (AOP), combining the planned abstraction of JMX with detailed and flexible monitoring and intervention. Having said this, it would be wasteful not to exploit the JMX information provided by a server. Some JMX MBeans serve as important internal DMA monitoring and access points but are augmented with additional monitoring and updating points within the server.
As shown in Figure 1 DMA abstracts from the underlying framework and application objects to a conceptual ERA model. Queries against this model then provide the means for problem recognition.
Figure 1: DMA operation by abstraction and selection
Usually the abstraction stage is one of selection as key objects are monitored, but it can also require composition of elements from more than one underlying object.