The development of application solutions in modern environments sooner or later will point up to the following dilemma: independently develop functionality or use the functionalities environment already provides. Developing application solution in ADF technology has proven to be in need for better control of session management. It seemed illogical to develop our own solution for functionality that has already been implemented in WebLogic. It was time to look into JMX.
JMX stands for Java Management Extensions. At the first mention of JMX most people visualize graphical display of various statistics and that is only partially true. Formally saying, JMX is a standardized API for the management and (or) monitoring applications, devices, services… (in fact everything that can be run on JVM). JMX allows you to change settings, collect statistics and publish alert as a result of an event (popularly called notification). How is it achieved? A system that implements JMX exposes its capabilities within the set of MBeans (Managed Beans). MBeans are Java classes that follow certain naming conventions but Mbeans are just like any other Java class. They consist of attributes, operations, and registered notifications. Every single MBean is a part in the structure of what we want to manage. Since the JMX is standard, it must be broad enough to cover virtually everything (from washing machine to space shuttle). It is not expected from the standard to regulate Mbeans’ structure by itself, which is one of the main reasons for the refusal to use JMX.
Why JMX? Formally saying, WebLogic is JEE application server. That means WebLogic must implement the entire set of Java standards including the JMX. Now it is time to learn more about the MBeans that are available to use. WebLogic classifies MBeans into two groups: configuration and runtime MBeans. Configuration MBeans present memory copy of the domain configuration. By changing the attributes of the configuration, MBean ultimately affects the domain configuration files. Runtime MBeans are something else. They contain the current status of certain components within WebLogic. The value within the runtime MBeans is not persisted (because the attribute like number of active database connections makes sense only in particular moment in time). Another important fact about the Mbeans: they are implemented as objects type javax.management.ObjectName. Furthermore, MBeans are hierarchically organized. The problem starts here. For a typical programmer logical structure of WebLogic is transparent, and to successfully deal with WebLogic MBeans the same structure must become apparent.
How does it look in a real world? The steps would be:
- Find appropriate MBean with the functionality needed.
- Connect to WebLogic server.
- Walk through the structure and retrieve the requested Mbean.
- Execute a method or read/write attribute of the requested MBean.
Let us try the possibility to terminate sessions on web application that are deployed on the WebLogic server. How to find the appropriate Mbean for doing that? The answer is in documentation. In documentation WebAppComponentRuntime MBean we have to reach for MBean that has got a functionality we need.
Figure 1 A look into documentation
The first step is to connect to WebLogic. The code looks like this:
Now it is time to choose on which JMX server to connect (configuration or runtime implementation? – because dealing with live system, which killing sessions that exist only in particular moment in time are, the answer is runtime ). In documentation, entry point is defined as ascom.bea:Name=DomainRuntimeService,Type=weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean.
After connecting to the entry point the walk through the hierarchy begins. In this case it looks like ServerRuntime -> ApplicationRuntimes -> ComponentRuntime. The initial step in the hierarchy walk would look like this:
At the end of the walk through the hierarchy, ComponentRuntime Mbean is found, but WebAppComponentRuntime Mbean is needed. What happened? Both of these MBeans are on the same level in the hierarchy, but the documentation says that WebAppComponentRuntime MBean is one of the ComponentRuntime MBean implementation, so you have to do this:
Thus the Type attribute is used to recognize and retrieve the WebAppComponentRuntime MBean. In the end, the method for terminating session is called:
What next? After examining the documents and the number of MBeans presented there, we can easily conclude: The sky is the limit.