With Web services usage on the rise, organizations are seeing a growing complexity in the enterprise systems being built. The need for a robust management solution is critical, as organizations look for better ways to monitor and control their IT environment.

While Gartner has estimated that 40% of unplanned downtime is often caused by application failures, application manageability is often an afterthought for the developer.

The benefits of manageability to an organization are indisputable. With manageability built-in, IT can quickly identify and resolve problems that occur. This can result in increased reliability and a better end-user experience. But, why should the developer care about this? A well-managed application relieves a great amount of burden from the developer. Developers don't have to be woken up in the middle of the night to resolve nonapplication problems. Time typically spent on problem resolution can be focused on developing new application functionality for the business.

To leverage the benefits of manageability, a developer must design for manageability. This means carefully considering the approaches and technologies available, including JMX, Logging, ARM, SNMP, and WSDM. The choice is often driven by ease of use, languages and platforms supported, and market adoption. This article focuses on one management standard for Java, JMX.

JMX (Java Management Extensions) is a specification defining how Java resources can be managed through a common interface. The JMX architecture, illustrated in Figure 1, consists of three layers:

• Instrumentation layer: How you create manageable objects in Java.
• Agent layer: A set of management agents that control the resources being exposed at the instrumentation layer.
• Distributed layer: How to connect the management layer to external applications and protocols (e.g., HTTP, SNMP, or RMI, etc.)

JMX development occurs primarily at the instrumentation layer, where MBeans are used to represent the managed resources. An MBean describes a given management interface through its attributes and operations. MBeans can be developed using either static operations (standard MBeans) or operations that are discovered at runtime (dynamic MBeans). Additionally, JMX offers additional persistence, and caching through Model MBeans.

In this article, we'll demonstrate how JMX MBeans can be developed in BEA WebLogic Workshop, the visual development environment used to develop applications on the BEA WebLogic platform. Workshop has a simplified programming model, based on controls, events, and properties, which greatly enhances the development of J2EE and Web services application. The IDE enables enterprise applications to be easily built through a robust Model-View-Controler (MVC) architecture.

Case Study
The case study presented here demonstrates an online shopping application called DizzyWorld, which provides key functionality for ordering products from a shopping catalog. Ultimately, we will want to create a business metric that helps line-of-business managers monitor their online business. In order to do this, they need to see the percentage of customers who are visiting the DizzyWorld Web site and completing a purchase. By using JMX, we can keep track of specific business transactions initiated by the customers to help calculate the percentage of purchases completed at any time.

First, to get a better sense of how this application works, let's go through a shopping experience. Initially, the DizzyWorld application displays the main page, which contains different categories of items available from the catalog. We can choose a category to further drill down and view the items in that category. If we select a particular item, we are then shown detailed information on the item and have the ability to add it to our the shopping cart. Figure 2 illustrates one step of this process.

Once we click on the Add to Cart button, the items are placed in our shopping cart. We can view the items in our shopping cart by clicking the View Cart link. The next step in the process is to proceed to checkout and place the order. Once we submit the order, the purchasing process is complete.

If we look at the architecture for DizzyWorld, it consists of several J2EE components, including JavaServer Pages (JSPs), Enterprise JavaBeans, and Web services. One BEA WebLogic technology used in our scenario is the Java Page Flow, or JPF. JPF is a Struts-based framework that makes a clean separation between page navigation, business logic, and the data model components. Developers can easily construct JPF flows through visual drag-and-drop tools available in Workshop.

Figure 3 illustrates one of the JPFs in our DizzyWorld application. This flow leverages WebLogic control to easily access certain resources in the application. Essentially, a control handles the work of connecting to the resource, so you can focus on the business logic. For example, the checkout, placeOrder, and cancel controls correspond to the Proceed to Checkout, Place Order, and Cancel buttons, respectively, on the application. In addition, you can easily navigate to the business logic that corresponds to each control by double-clicking on the control in the diagram.

So far, we have seen a fully functional online shopping application. What we're going to look at next is how to add management capabilities to this application. We'll discuss the following topics:

• Developing a management component using JMX, implemented using a JMX MBean
• Instrumenting the DizzyWorld application with JMX calls, including a discussion of the importance of design patterns for manageability
• Testing the JMX instrumentation and monitoring JMX values using a browser-based tool

At the end of this article you should have a good sense of how JMX technology can be used to instrument an application developed in BEA WebLogic Workshop.

Developing the JMX MBean
We will begin by building a management component using JMX. For any kind of management component that you create, it is important to first identify what it is you want to manage. In this example, we are going to manage business transactions initiated by the user. Specifically, we want to be able to manage the ratio of completed shopping carts to created shopping carts and expose this as a metric that can be monitored from management software such as HP OpenView. This requires that we capture two data items: the number of shopping carts opened and the number of shopping carts completed. In this example, we will define a management component that will be registered with WebLogic and updated from the DizzyWorld pageflow.

To get started, we will use Workshop to do our development of the JMX component, illustrated in Figure 4. First, we have to define a Java project within this application called ShoppingCartManager. Within this project, we will implement our MBean and some additional helper classes that will make deploying and accessing this MBean easier.

For the Standard MBean, an interface must be defined that exposes the various methods that can be invoked on the MBean. These methods can be either attribute methods, which will be getter and setter methods; or operations that are higher-level operations that can be used to alter the state of the MBean.

As shown in Listing 1, three getter methods are used to retrieve the MBean name, the CartsCreatedCount, and the CartsCompletedCount. In addition, we have two MBean operations that are used to notify the MBean that we've added a shopping cart or closed a shopping cart (see Listing 1).

Once we've defined our MBean interface, we must implement it. This is a requirement for developing standard MBeans. Note that the class must be named the same as the interface minus the MBean suffix. This is a requirement the MBean server places on standard MBeans.

Listing 2 shows the implementation of the interface we defined. Specifically, you can see that calling addCart() or closeCart() simply increments the respective attribute values by one. These are the public operations that we will use to instrument our application.

Once the MBean has been defined and implemented, it must be registered with the MBean server. We put the registration code inside a startup class, MyShoppingCartManagerStartup, which is a special class that can be loaded and invoked by WebLogic Server at startup (see Listing 3). By doing this, we have an easy way of ensuring that the MBean will be loaded and registered each time the server starts.

Next, we built the project in BEA WebLogic Workshop, which compiled all of the classes and created the ShoppingCartManager.jar file. While we chose to use a startup class to load and register the MBean, you could also use the Administrator's console to load and unload the MBeans.

In addition, we had to make some changes to our WebLogic startup script and configuration file to reference the ShoppingCartManager.jar file. In our WebLogic startup script we added the ShoppingCartManager.jar file to the CLASSPATH:

set POST_CLASSPATH=%POST_CLASSPATH%;
c:/projects/ShoppingCart/lib/ShoppingCartManager.jar

In the config.xml class, shown in Listing 4, we added a reference to the MyShoppingCartManagerStartup class. This would make sure the MBean was registered each time the WebLogic Server started.

Now that we have the MBean interface implemented and registered, we can instrument our DizzyWorld application.

Instrumenting Your Code with JMX
With the JMX MBean developed, we can turn our attention to the instrumentation step. Two important development steps must be completed. First, we need to decide how we will discover and invoke the operations on the MBean. We then need to decide where in the JPF we will place our JMX calls to notify our MBean when shopping carts have been created or closed.

The discovery process for an MBean works similar to EJB discovery in a J2EE application. Developers must first locate the MBeanHome and then locate a RemoteMBeanServer instance. At that point, any of the operations on the JMX MBean can be invoked. Listing 5 shows how this can be accomplished for our ShoppingCart MBean.

There are a couple of things to consider in the development. First, you should see references to a MyShoppingCartConstants class. This class, shown in Listing 6, allows us to isolate some of the JMX Server configuration information into a single location. This class contains settings for the BEA WebLogic Server host and login information. We could have also placed this data in an XML configuration file and dynamically loaded it at runtime.

The design should also look for opportunities to increase reuse and reduce complexity. The logic in Listing 5 will become unmanageable if you have to add this code everywhere instrumentation is required. To simplify the business logic, we have developed a Proxy class, MyShoppingCartMBeanHelper, to hide some of the complexity of discovering the JMX MBean and invoking the operations. Listing 7 highlights the interface for this Proxy class. We would place the code shown in Listing 5 in this addCart() method and any clients wishing to invoke this operation can call this method directly.

There is one further refinement we can make to the code. You'll notice that we're doing a lookup of the MBean every time one of the Helper class methods is invoked. We may want to consider caching the reference to the MBean Server once we have obtained it and then use that reference in subsequent invocations. This is where the Home Factory design pattern could be applied to isolate this lookup step.

Now that we have defined a simplified interface for interacting with the MBean, we are ready to instrument the application. This is probably one of the most critical steps in the design, because excessive instrumentation can impact performance and maintainability of the application. To illustrate JMX integration with JPF, we opted to identify events, rather than data elements, that could be instrumented. Referring again to Figure 3, we will define the creation of a shopping cart at the point the user clicks the Proceed to Checkout button, which corresponds to the checkout action. We will also define the completion of a shopping cart as the point where the user clicks the Place Order button, which corresponds to the placeOrder action. The JMX calls will go behind each of these two events.

Before we begin instrumenting the application, we first have to import the class and create an instance of the MyShoppingCartMBeanHelper class we developed. The following code is placed at the top of the CheckoutCartController.jpf class:

import com.hp.atc.mbeandemo.*;
private MyShoppingCartMBeanHelper mbeanHelper =
new MyShoppingCartMBeanHelper();

At this point, we just have to insert the appropriate JMX calls in our code. From the JPF, we can double-click on the checkout action, which will take us directly to the code. We can then add the following instrumentation line to the end of this routine:

mBeanHelper.addCart()

We would perform a similar instrumentation step to add a call to closeCart() behind the placeOrder action.

And that's all we have to do to JMX-enable our application. Hopefully, this has shown you how simple it can be to instrument your application with JMX, especially if you leverage design patterns to isolate the JMX logic. But, what if you didn't want to instrument your application? One alternative is to use aspect-oriented programming (AOP) techniques to isolate the instrumentation rules. With AOP, you could define a management aspect that indicates where the JMX calls should be added in the code, without requiring the application code to be directly modified.

We can now turn our attention to testing our instrumented application.

Testing the Instrumentation
The final step in our development is to test the JMX instrumentation. To do that, we will walk through a shopping experience using the application and determine whether the JMX MBean is being updated.

We begin by bringing up a browser and navigating to the home page for the application:

http://localhost:7001/OnlineSalesWeb

At this point, we can browse through the various items available and place them in our shopping cart. When we are done shopping, we can view our shopping cart by clicking the View Cart button. We would then be presented with a screen similar to Figure 5.

Previously, we added instrumentation at two points in the execution: once when the checkout process was initiated and again when the checkout process was completed. In this case, when we click on the Proceed to Checkout button, our JMX MBean should be updated accordingly.

We can use a variety of methods to verify whether the JMX MBean was updated. BEA WebLogic provides a set of command-line tools to return the current values of the JMX MBeans. There are also a number of tools available for browsing JMX data, including EJTools JMX Browser, AdventNet JMX Studio, XMOJO, and XtremeJ. For our purposes, we used a simple HTML adaptor for browsing the MBeans, StartHtmlAdaptor.

Once the WAR file for this Web-based tool is deployed into WebLogic, you can view the deployed JMX MBeans by browsing to the following location:

http://localhost:8082

Figure 6 shows one view of our ShoppingCart MBean. As you'll notice, the CartsCreatedCount was updated to two, indicating a new shopping cart was created. At the point when the purchase is approved by the user, you should then see the CartsCompletedCount get updated as well.

Conclusion
Without application manageability, application problems can cost an organization millions of dollars to fix and maintain the software. While it's possible to manage Java applications once in production, we recommend you consider introducing JMX early in the development life cycle. This approach can offer the following benefits:

• Ease of use: The JMX specification leverages many of the Java and J2EE concepts, such as JavaBeans and EJBs. Learning JMX is quite easy for the Java developer.
• Componentization: With JMX you have the ability to expose as much or as little of your application as you want.
• Leverage existing management components: You don't have to get rid of your current management solutions. You can create synergies between what you have today and what you may want to add in the future.

Application manageability allows you to produce robust applications that can adapt to the needs of the business. If you take time to add manageability, you improve the time-to-market because problems in the application can be found during development or testing, and resolving problems once in production can be done quicker. And, as this article has shown, you can apply JMX technology to solve real business problems, such as determining shopping cart success rates for a business.

In this article, we demonstrated how a JPF could be instrumented with JMX. Hopefully, you have a better understanding on how to get started using JMX and building manageability into your Java application with the BEA WebLogic Platform. In a future article, we will look at taking this JMX-enabled application and integrating it into HP OpenView Operations.

References

Murray, Justin. "Enhancing Application Manageability". WebLogic Developer's Journal (www.sys-con.com/weblogic) Volume 2, issues 6 and 7.

Davidson, Stephen and Rogers Claire. "Instrument Your Application Using JMX Tutorial": http://devresource.hp.com/drc/tutorials/JMX/mBean_123_tutorial.jsp.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Source Code