Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Exploring WebLogic JMX: JMX and J2EE Part 1

Exploring WebLogic JMX: JMX and J2EE Part 1

J2EE is rapidly becoming an established platform for deploying long-running business-critical applications. As the number of J2EE applications grows and their importance increases, a standard way to manage J2EE servers and applications is becoming a key requirement.

Java Management Extensions (JMX) provide a pure Java management infrastructure that can be used for all Java-based software.

BEA WebLogic's support for JMX comes in not only providing a JMX implementation, but in basing all of its key administration and management features on this standard. The administration and management features of WebLogic are now extensible ­ open to both developers and third-party tool integrations.

There are obvious benefits in improved and extensible administration, but J2EE application developers still face several questions: What exactly does JMX provide and how is it likely to be used? What management features should developers build into J2EE applications? Which management facilities should the application server provide automatically? This first article in a two-part series on WebLogic JMX provides a brief overview of JMX and discusses some of its implications for enterprise Java developers.

JMX and Application Management
An application is instrumented if it provides a well-defined public interface that allows other applications to access its management or administrative functions. The management interface of an application does not generally resemble its public client interface. Instead, it is intended for privileged users, exposing data and functions for monitoring and administration. A component that has been instrumented to provide such a management interface is a manageable resource.

Manageable resources include devices such as printers, network routers, and telephone switches. More generally, any software component that resides on a server or in a distributed environment that is available to service requests is a good candidate for instrumentation. J2EE components fit well into this larger category. Management interfaces for such components include functions for tracking resource use, measuring client volumes, generating error logs, stopping and starting services, and load-balancing.

Developers (when tuning and debugging systems), system administrators (when monitoring applications and intervening when necessary), and other users employ management applications to access instrumented manageable resources. Management applications range from graphical resource-use monitors that run locally to Web-based administrative consoles that can be accessed remotely. Many of these tools use standard protocols to discover and display managed resources and their interfaces dynamically.

JMX is intended to be simple enough to allow developers to rapidly provide a management layer for either new or existing Java applications, and comprehensive enough to be adapted to other standard (non-Java) management protocols. The JMX specification, currently in its 1.0 release, is being developed through the Java Community Process. The JMX reference implementation is available from Sun Microsystems, which also provides a commercial JMX-based product, the Java Dynamic Management Kit (JDMK). A number of J2EE vendors now include JMX implementations in their application servers; WebLogic is one of the more comprehensive of these.

A specification for J2EE-specific management requirements based on JMX is currently under development, as are other specifications that describe how JMX should be adapted to other management protocols.

JMX Architecture
JMX presents a layered architecture, shown in Table 1 and Figure 1. At the two extremes of the JMX levels are the instrumentation level and the management level, representing managed resources and management applications. Between these are the agent and distribution levels, which provide the necessary protocols for applications in the management level to access the manageable resources of the instrumentation level.

Managed Beans, or MBeans, make up the instrumentation level. These objects represent the manageable resources of the system, and are the primary components of the JMX architecture.

An MBean Server is the most essential part of the agent level. It provides a means for creating, registering, and finding MBeans within the system.

The agent level includes several services that are also represented by MBeans.

The distribution level may provide remote access to the agent level through CORBA, RMI, or other means, and may also provide adapters for other protocols. It may provide security as well.

The management level consists of the external applications that can access the MBeans via the APIs exposed through the agent layer, using protocols provided by the distribution layer.

WebLogic goes beyond the JMX 1.0 specification to provide a distribution layer that maps logically onto the underlying agent level. Both local and remote users of JMX can access MBeans through the corresponding MBeanHome, a WebLogic-specific component that provides a client with access to MBeans. WebLogic's MBeanHome components offer some distribution facilities, as well as other features that make them easy to use.

Using JMX
Simple Instrumentation

JMX's instrumentation level provides a variety of Managed Bean types for developers to implement depending on their requirements. It is important to note that MBeans bear no resemblance to Enterprise JavaBeans (EJBs). An MBean is like a regular JavaBean, having a well defined interface, complete with getters and setters. Unlike EJBs, they have no built-in transactional security or distribution facilities.

A Standard MBean, the most basic MBean, is not required to implement a special JMX interface or extend a particular abstract class. To be considered a Standard MBean, a class must simply implement an interface whose name matches that of the class with the additional MBean suffix. The MBean interface defines the management interface for the corresponding MBean class. A simple MyService MBean is shown in Listing 1 (code for this article may be found at www.sys-con.com/weblogic/sourcec.cfm).

Making the MyService MBean available within a JMX agent is straightforward. The examples in Listings 2 and 3 are based on the standard JMX interfaces and can be used with Sun's reference implementation.

Registration of an MBean with the agent layer is carried out using the MBeanServerFactory, MBeanServer, and ObjectName classes, all part of the standard JMX API, found in the javax.management package. The MBeanServer interface provides a rich API for registering and manipulating MBeans; essentially, all management of MBeans is carried out using this interface.

The MBeanServerFactory is a class that provides a broker for the various MBeanServer instances within a system. It is an implementation-neutral way of obtaining references to an MBeanServer. The API provided by the MBeanServerFactory allows for multiple servers to be active within the system.

An MBean is registered under a particular name that is used to uniquely and meaningfully identify it. For most MBeanServer operations, this name is represented by an ObjectName instance. It is a structured piece of data that complies with the JMX naming conventions. MBean names are given by a domain name, followed by a colon, and then by a sequence of one or more property-value pairs. Certain MBeanServer APIs support pattern-matching for MBean names, allowing users to query for a range of MBeans whose names conform to a given object name expression.

As shown in Listing 2, the basic registration process is quite simple. However, additional JMX facilities provide hooks for developers during the registration process, if required. For example, the MBean can implement an additional MBean Registration interface that will give the MBean- event callbacks during registration. These callbacks (preRegsiter, postRegister, deregister, and postDeregister) allow the MBean to obtain a reference to the MBeanServer, allowing the MBean to perform management actions on other MBeans. MBeans are used by invoking their methods through the MBeanServer interface (see Listing 3).

Intermediate and Advanced JMX Use
Standard MBeans are simple, as is the basic API for manipulating the MBeanServer. However, JMX also offers functionality that goes far beyond basic use. Instead of Standard MBeans, implementers of MBeans can choose to build Dynamic MBeans or Model MBeans, and may make use of the JMX Notification framework. The agent level also has other features, including a number of built-in MBean monitors, and services for loading and relating MBeans.

Dynamic MBeans
Dynamic MBeans allow the management API of an MBean to be defined dynamically instead of through a predefined interface. For all MBeans, the agent layer discovers the management interface and exposes it through various APIs. For Standard MBeans, this interface is discovered by inspection of the MBean interface. For Dynamic MBeans, the agent level discovers the management interface by invoking particular methods on the MBean (see Listing 4).

Dynamic MBeans generally require more coding than Standard MBeans, but allow the management interface to change at runtime, and allow the MBean developer to expose more information (such as textual descriptions of the MBean and its operations) through the agent level.

The surprising aspect of DynamicMBeans is that they present essentially the same client view to their users as Standard MBeans. A Dynamic MBean's attributes are displayed and its actions are invoked through MBeanServer methods in the same way as the much simpler Standard MBeans.

Model MBeans
Although a specialized form of Dynamic MBeans, Model MBeans are completely different in how they are built and configured. Essentially, a Model MBean is a generic Dynamic MBean that can be loaded with an object that represents the manageable resource. A JMX Provider is required to provide Model MBean implementations that developers can configure to wrap their resources without creating any MBeans themselves. As a result, Model MBeans require far less coding than Dynamic MBeans. To build a Model MBean, the developer must

  • Create an empty Model MBean,
  • Provide a managed resource delegate against which all operations will be executed,
  • Provide an MBeanInfo object that lists the allowed operations for the MBean,
  • Register the Model MBean with the MBeanServer.
JMX Notifications
The JMX Notification framework allows MBeans to notify management applications of changes of state or other events that have occurred in the manageable resources of the system. Various subclasses of javax.management.Notification (which extends java.util.EventObject) can be used by MBeans that implement javax.management.NotificationBroadcaster to signal events to objects that have implemented the javax.management.NotificationListener interface.

MBean Monitors
Instead of relying on MBeans to notify interested parties of changes in their state, management applications can actively track MBean attributes through MBean monitors provided by the agent level. A JMX agent implementation will provide various MBean Monitors. These are used to detect changes in specific MBean attributes. Several monitor types are provided with a JMX agent, including

  • CounterMonitor: Checks the value of attributes that act as counters (these are integer types and have nonnegative values)
  • StringMonitor: Detects changes in string values
  • GaugeMonitor: Observes fluctuations in integer or floating point attributes within a range.
JMX MetaData
One of the key things that JMX provides is a way for managed resources to describe themselves to management applications. This allows management applications to be written independently of the systems they administer, without knowledge of the operations and attributes of the manageable components they will manipulate. The description of manageable resources is carried out through the JMX metadata data classes ­ MBeanInfo, MBeanOperationInfo, MBeanConstructorInfo, MBeanAttributeInfo, and so forth.

Without a metadata infrastructure, management applications would have to rely on the Java reflection API for this discovery process. By providing this framework, JMX avoids the difficulties associated with reflection and provides a standard means of self-description that allows developers to provide more information than is available through reflection.

Roles in JMX
One of the main questions with JMX is not how to use it ­ its architecture and API are straight-forward ­ but when and why to use it. The potential users of JMX technology are best described through a set of illustrative roles (see Table 2).

Java developers will likely find themselves in the roles of application developer, while building manageable applications, and management solutions developer, while creating ways to better manage existing applications. The application developer develops Java applications that provide a runtime management interface. J2EE applications built with technologies such as JSPs, servlets, EJB, JMS, and so on are likely to be the most common manageable applications. This role will use the instrumentation level of JMX.

Management solutions developers will create customized administration and monitoring systems that will function as components in the management layer of JMX. They will be accessing instrumented application components from the agent level through the distribution level. These developers may have to develop additional protocol adapters in the distribution level if they are integrating legacy management systems.

Management tool vendors may build management tools in Java, or may enhance existing tools to use JMX. This may include adapting existing management protocols to JMX.

For both the management solutions developer and the management tool vendor, the end-user of their work is the system administrator. This role uses these tools and solutions to manage the running applications ­ monitoring their behavior, running diagnostic checks, shutting down and starting up services, and doing manual load-balancing as required.

A standalone Java application may provide a complete JMX implementation, but the more common scenario is that the vendors of J2EE servers will also become JMX Providers. The JMX Provider provides an implementation of JMX either as a framework to be incorporated into standalone Java applications, or as part of an application server.

JMX Use in J2EE
The inclusion of JMX in J2EE-based application servers will enable developers to:

  • Provide application-specific management interfaces that can be used by in-house and third-party management tools
  • Leverage existing application-server instrumentation to create custom reporting and monitoring applications
  • Integrate third-party management tools into their J2EE applications.
Perhaps the most significant use of JMX technology by application developers will be in writing interfaces and reporting tools that make use of the instrumentation already provided by the application server. In other words, it is likely that developers will develop more applications at the JMX management layer than building MBeans themselves.

Ideally, integrating JMX into J2EE application servers will make the configuration and administration facilities of such servers extensible, allowing developers to create simplified administration consoles, integrate reporting facilities and statistics-gathering into the server, and tie server and application events to logging facilities or messaging channels.

The more instrumentation provided by the application server, the less need there will be to build JMX interfaces for individual J2EE application components. Instrumentation provided by the application server will be safer than anything built into individual components, and will provide a consistent management view across all deployed applications. Standard J2EE management facilities may include:

  • Deployment, undeployment, and redeployment of components
  • Server availability and cluster administration
  • Security management
  • Error logging
  • Connector monitors (i.e,. JDBC connection tracking)
Clearly, developers will rely on the J2EE platform to supply more than just a JMX implementation. The platform will use JMX to provide access to built-in administration, management, and monitoring facilities, and ensure that applications deployed on the platform are preinstrumented and ready to be managed through app-server or third-party tools. WebLogic JMX does precisely this, offering a comprehensive set of prebuilt MBeans that provide access to all administration and monitoring features.

JMX Pitfalls
Overuse of JMX is a pitfall that should be avoided. It is not designed to be a general-purpose distributed object system. JMX use should be limited to those aspects of the system that are clearly management-related. Some other areas in which JMX users should proceed with care include:

1.   Mixing JMX directly with EJB: Care must be taken to ensure that JMX code does not violate the security and transactional integrity of the EJBs. An EJB cannot also be an MBean for several reasons:

  • The EJB life cycle, which allows beans to be pooled, change identity, and be destroyed, does not match that of MBeans, which are treated like normal objects living within the virtual machine;
  • If an EJB acts as an MBean, the agent layer would have direct access to the bean-instance, bypassing the component interface and violating the transaction-and security-checking code provided by the container;
  • The EJB deployment, creation, and querying protocols do not match those provided by JMX.

    EJB components should not also be MBeans, nor should they expose their underlying bean instance directly to MBeans. It is possible, however, for MBeans to access EJBs through the standard EJB protocols. Unfortunately, MBeans would not be able to access EJBs through the new local interfaces provided by EJB 2.0 since these are restricted to use by other enterprise beans. Consequently, MBeans would have to access EJBs as remote clients, and the operations available to the MBeans would be the same as those exposed through the regular client interfaces.

    2.   Distributed JMX use: Lack of details for distribution in the specification puts developers who are trying to create application server­neutral management solutions at a disadvantage. MBeanHomes make up for this by providing a straightforward distribution mechanism.

    3.   Relying on Standard J2EE management features: There is no official statement on what management facilities should be present in an application server. The existing management and administration facilities in WebLogic are a good example of the direction in which these specifications are likely to proceed.

    JMX provides an incredibly simple and flexible way to make Java applications manageable, and a standard way to build powerful management applications. J2EE application servers have reached a level of maturity where management facilities are a requirement. As these two technologies evolve, developers of J2EE applications will see an increased need to make their applications JMX aware, and will see more JMX-based management tools appear in the application server marketplace. Although JMX is based on well proven management concepts and products, its use in application servers is in its infancy but as with all enterprise Java technology, it is bound to grow up quickly.

    In part two of this series, we will look at WebLogic's JMX implementation, and discuss some concrete ways that it can be used to instrument J2EE applications.


  • Sun Microsystems (July 2000). "Java Management Extensions (JMX) Instrumentation and Agent Specification (JSR 3)."
  • Sun Microsystems. "J2EE Management (JSR 77)".
  • Sun Microsystems. "CORBA Adapter for JMX (JSR 70)."
  • Sun Microsystems. "WBEM Services Specification (JSR 48)."
  • Sun Microsystems (March 2001). "Java Platform Enterprise Edition Specification, v1.3 (proposed final draft 3)."
  • Sun Microsystems. "IIOP Protocol Adapter for JMX Specification (JSR 70)."
  • Sun Microsystems (2001). "Java Platform Enterprise Edition Specification, v1.3 (proposed final draft 3)."
  • Sun Microsystems (April 2001). "Enterprise Java Beans Specification v 2.0 (public final draft 2)."
  • Sun Microsystems (June 1999). Java Management Extensions White Paper: "Dynamic Management for the Service Age; Revision 01."
  • BEA Systems (2001). "Using WebLogic Server JMX Services."
  • More Stories By Dan MacKinnon

    About 7 years ago I wrote these two articles for the now defunct "WebLogic Developers Journal." They have now shown up on 'ulitzer'. They are now horribly out of date - please ignore them! :) Thanks, -- Dan

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    Most Recent Comments
    Thomas SMETS 01/07/05 10:31:12 AM EST

    The URL reference in the page is incorrect : http://www.sys-con.com.com
    Secondly, if adapted to : http://www.sys-con.com/weblogic/source.cfm it does not respond (404).


    @ThingsExpo Stories
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
    DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of bus...
    With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
    DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    DXWorldEXPO LLC announced today that "Miami Blockchain Event by FinTechEXPO" has announced that its Call for Papers is now open. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to [email protected] Financial enterprises in New York City, London, Singapore, and other world financial capitals are embracing a new generation of smart, automated FinTech that eliminates many cumbersome, slow, and expe...
    DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by FinTechEXPO. ICOHOLDER give you detailed information and help the community to invest in the trusty projects. Miami Blockchain Event by FinTechEXPO has opened its Call for Papers. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to [email protected] Miami Blockchain Event by FinTechEXPO also offers s...
    DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    With tough new regulations coming to Europe on data privacy in May 2018, Calligo will explain why in reality the effect is global and transforms how you consider critical data. EU GDPR fundamentally rewrites the rules for cloud, Big Data and IoT. In his session at 21st Cloud Expo, Adam Ryan, Vice President and General Manager EMEA at Calligo, examined the regulations and provided insight on how it affects technology, challenges the established rules and will usher in new levels of diligence arou...
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
    Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
    Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
    Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...
    Cloud Expo | DXWorld Expo have announced the conference tracks for Cloud Expo 2018. Cloud Expo will be held June 5-7, 2018, at the Javits Center in New York City, and November 6-8, 2018, at the Santa Clara Convention Center, Santa Clara, CA. Digital Transformation (DX) is a major focus with the introduction of DX Expo within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive ov...