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 will aim to show how we can identify a pattern of application and framework components that indicates a problem. We will then show how the problem can be visualized and explained back to the source level by exploring the model at the point of detection.
Figure 2 shows a simple Web-based order processing example that accepts orders and processes them in the following manner:
Figure 2: Example order form
However there is a problem: The invoices do not arrive at the invoice processing application although the order entries are processed correctly.
To monitor the sample application we will run the BEA WebLogic Server from our DMA analyzer, called eoSense, which consists of a server agent and a client. The agent constructs and checks the abstract model as WebLogic Server executes. When a problem is detected, the agent signals an alert to the client.
Running the example application results in the initial alerts being detected (after several less serious alerts), as shown in Figure 3.
Figure 3: Sample alerts
Looking at the alerts in more detail:
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 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.
Note: This example is not an endorsement of initiating JTA transactions in servlets. That's another doubtful practice, and one that eoSense can also detect, but it's simpler to show the example this way.