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 do extensive automatic checks for a range of construction errors that could produce poor performance or unreliability. The model also lets server behavior be dynamically visualized in real-time or retrospectively.

There has been a lot of attention given lately to the topic of 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 haven't been a big success - there's no doubt that 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 that 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'd still like to be able to validate and understand it based on a design-level description of its operation.

Derived Model Analysis (DMA)
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'll 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 the data access, transaction management, and calling relationships between them.

Once application model elements were identified they would be updated dynamically during execution. Monitoring the changing patterns of inter-relationships in the model would automatically detect 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 see key abstractions directly in the model.

eoLogic terms 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 that 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 analyses how services have been constructed and are being used. The idea is to identify places where hotspots or unreliability may occur under load. This deeper form of analysis can be used to find problems before they manifest themselves and without the application being 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's no need to drive the application to a point at which it exhibits slowdown, and the results need little interpretation.

Deriving a DMA Model
To generate and validate an abstract model of an application a tool must be able to monitor events in the server and interpret them in light of the relevant stored knowledge.

This includes definitions of the main abstract entities we're interested in (transaction manager, transaction resources, transactions, EJB containers, JMS destinations, etc.), the possible relationships between these entities, and invalid and valid patterns of relationships and states. DMA forms them into an abstract Entity-Relationship-Attribute (ERA) model as the system executes, with model changes triggering annotated definitions of problem states.

Relationship to JMX
The model sounds a lot like Java Management Extensions (JMX) - which essentially define a form of abstract model for purposes of managing and monitoring Java applications, and it suggests that possibly DMA could be layered on top of the information available from JMX MBeans. In detail, what characteristics does a DMA model require?

• It must be an accurate and complete abstract model of an application, linking static (source) and runtime application components.
• It must be able to be updated in real-time as the server executes generating meaningful sequential event flows.
• It must support a wide range of relationship types including application-level call relationships.
• It must be able to be intimately combined with knowledge about valid and potentially invalid model forms.
• It must be possible to relate model-level information easily back to application source.
• It must be easily filtered to focus on different aspects of server operation.
• And it must be easily and intuitively understood.

JMX goes some way towards 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's a notification system for attribute changes and there's even an MBean relation service.

However, for our purposes it also has some serious limitations. Many of the relationships we have to monitor are based on calling sequences and application component relationships. Designed primarily for system management and threshold monitoring, JMX doesn't 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 want 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 that we adopted is to create a more detailed runtime ERA model specialized for the following purposes:

• Representing sequences of server operation precisely and clearly
• Detecting construction errors based on component interrelations, including call sequences and transaction membership
• Explaining construction errors by relating model entities and relationships to precise source references
• Providing an intuitive visual model of sequential server operation
• Supporting model tracing and playback
• Supporting integrated debugging

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 that the DMA engine moves from the realm of JMX and more towards an application of Aspect-Oriented Programming (AOP), combining the planned abstraction of JMX with the detailed and flexible monitoring and intervention of AOP. 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 in the server.

DMA Error Detection
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.

Usually the abstraction stage is primarily one of selection as key objects are monitored, but it can also require composition of elements from more than one underlying object.

DMA Use Case
To look at how the abstraction mechanisms of DMA allow construction problems to be detected and explained let's look at it operating on a sample application. We'll aim to show how we can identify a pattern of application and framework components that indicates a problem. We'll then show how the problem can be visualized and explained back to the source level by exploring the model at the point of detection.

Example Application
Figure 2 shows a simple Web-based order-processing example that accepts orders and processes them in the following way:

• An order invoice is created and queued to an existing invoice service using JMS to create and process the invoice.
• The order details are queued to an order processing system using JMS to process and deliver the order separately.

However there's a problem: The invoices don't arrive at the invoice processing application although the order entries are processed correctly.

Monitoring the Application
To monitor the sample application we'll run the WebLogic server from our DMA analyzer called eoSense, which comprises a server agent and a client. The agent constructs and checks the abstract model as WebLogic executes. When a problem is detected, the agent signals an alert to the client.

Transaction-Related Alerts
Running the example application results in the initial alerts shown in Figure 3 being detected (after several less serious alerts).

Looking at the alerts in more detail, there was a:

• JMS Message sent inside a JTA Transaction using a non-XA Connection - A JMS Connection created from a non-XA Factory was used to create a JMS session and sender. The sender was then used with the context of a JTA transaction. This may indicate that an XA JMS Connection should have been used instead.
• Mixed Transactions - The JMS sender has been used from a JMS Session marked as transacted, but there's already a JTA transaction active on the current thread.

DMA Visualization
When the Mixed Transaction alert is recorded a diagram of the ERA model allows the context of the problem to be understood. In eoSense this is called the Server View and an image of the server view is shown in Figure 4.

We can see that there are two active transactions, one linked to the Order Processing Servlet and the other linked to a JMS Session. We can also see that the Order Processing Servlet has communicated with two JMS Senders. Figure 5 shows diagrammatically the named key entities and relationships from Figure 4.

• There are two in-flight transactions held by the Transaction Manager
• There is an "initiated By" relationship between the OrderProcessingExample Servlet and Transaction 1
• There is an "Initiated By" relationship between the JMS Session 1 and Transaction 2
• The OrderProcessingExample Servlet has sent two Messages: There is a "Has_Called" relationship to JMS Sender 1, which is attached to the Order JMS Destination, and a "Has_Called" Relationship to JMS Sender 2, which is attached to the Invoice JMS Destination.