Enterprise adoption of J2EE as the strategic architecture for server-based applications is on the rise. Increasingly, mission-critical applications are being built and deployed on J2EE infrastructures. This trend is driving demand for better administration, monitoring and management of J2EE applications as well as the underlying network and systems infrastructure. J2EE based solutions will need to deliver on the management needs of large enterprises to be successful. An emerging standard, Java Management Extensions (JMX), will be essential to meeting these needs for J2EE applications.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
JMX is already playing a key role in the trend towards better management of J2EE applications and application infrastructures. For example, many J2EE application server providers are using this technology for core control and management functions, and have made JMX an essential building block of their products. JMX acceptance is growing, to where it will be mandatory for compliance with J2EE 1.4 and a standard component of J2SE 1.5.
While JMX is widely being used for managing J2EE infrastructure, the most interesting aspect of this technology is that it enables powerful management capabilities for the applications themselves. This goes beyond managing just the J2EE server or other middleware infrastructure. This ability to easily and directly manage the specific applications built on J2EE or other infrastructure is a major benefit of this new technology.
IT organizations have been forced to deal with application management limitations while operating their distributed computing infrastructure. A litany of complaints is all too frequent with regard to application management of complex deployments in the enterprise. J2EE technologies are being adopted in part because of the push by enterprises for better management and control of their server-based application infrastructure. Application developers can now leverage JMX and the new ways of delivering server-based applications to help IT get their application management issues firmly under control.
A promising aspect of JMX technology is the business benefits it promises beyond basic application management. Many mission-critical software deployments support business processes that need to be monitored and mined for information that drives key business decisions. JMX makes it easier to quickly expose information on demand from critical systems used in operating the business, and use that information for business intelligence and informed decisions. Application developers and IT managers can derive business benefits with these tools, in ways not available before.
Application Management Challenges
Most application developers view management as an afterthought when building and delivering their applications. In some cases, developers try to anticipate administration and monitoring needs of their users, and build such administration, logging and instrumentation into their applications. This often uses a variety of proprietary mechanisms for consoles, log files, and instrumentation. While this may fulfill the immediate needs anticipated by application developers, it is usually a poor fit with the real requirements of enterprises that have to deal with a complex integration of many such applications. If each application has its own way to do administration and monitoring, handling the diversity of management tools becomes its own challenge.
A lack of operational perspective may be one cause for the limited application management capability delivered by developers. This goes beyond the fact that application developers are rightly focused on their own applications. Even for an operations group, a maturity level is required to appreciate the need for many management capabilities. Without scale and diversity, it's easy to make do without many of these capabilities. It is typical in a small deployment or organization to have no application management tools. However, once an organization experiences scale, diversity, outages, downtimes, and other operational facts-of-life, all these dimensions of management take on increased importance. It is often a result of experiencing high-profile outages that many a growing enterprise has matured their processes and tools.
It's difficult to anticipate all the management needs of a complex deployment with a diverse set of integrated systems and applications. Management tools address some of the needs, but IT operations groups have had to work with imperfect and incomplete management solutions for most complex deployments. Given the different applications from a range of software vendors, and the multitude of custom developed J2EE applications, application management vendors are hard pressed to keep up with the real requirements.
There is therefore a need for standards-based instrumentation from applications, such that the management applications can use it effectively. A host of initiatives using SNMP, DMI, CIM/WBEM, AMI, etc., have tried to address this. Each has made some contribution, but we are left without a good solution to the problem. One cannot overlook the difficulty of instrumentation for application developers as one of the major reasons for the scarcity of good solutions. This is one of the areas where JMX is making a real contribution.
JMX is a Java standard that specifies a model and the interfaces for remote or local management of Java applications. An important goal for JMX is to allow a broad range of management systems and applications access to instrumentation and control of the managed applications. JMX achieves this goal with a creative model that uses a common set of application management components and provides access via multiple protocols like SNMP and HTTP. With JMX, applications can be instrumented once and be managed via multiple protocols accessing the same management instrumentation. Furthermore, it allows for rapid manageability in ways that no longer require heavy lifting by application developers.
The architecture for JMX is illustrated in Figure 1. The goal of enabling remote management from different kinds of management applications and systems is solved with a layered approach.
At the application level (called the Instrumentation Level), components called MBeans provide the application-specific management information. These MBean components, which bear some similarity to Java Beans, provide the essential visibility and control for managing applications. These components interact with the applications and are developed for each application based on its management needs. For example, an MBean may provide a method to shutdown an application component.
The Agent Level interfaces to the MBean components and provides a management interface to these components. The MBean Server is the key component in this layer, and provides a set of management functions useful to managing MBeans.
The Connector Level, or the Protocol Level, consists of one or more connector (or protocol adaptor) components that provide access to remote management systems.
Depending on the protocols supported by the JMX implementation, remote managers supporting SNMP, HTTP, or other management protocols can access the management information and control exposed by the MBeans for each application. Multiple management systems using different protocols can now simultaneously access the application management capability. Thus the application management can be made available to existing enterprise management consoles traditionally used in enterprises.
The MBean components are Java classes that fit design patterns based on the type of MBean. The defined MBean types are Standard, Dynamic, Open and Model MBeans. Standard MBeans provide a static interface. Dynamic MBeans provide an interface that can change at runtime, and is defined by metadata associated with the MBean. Open MBeans are Dynamic MBeans that use a small set of universal Java types. A Model MBean is a Dynamic MBean that provides a generic template for managed resources, so that users can expose the information they want without creating MBean classes.
JMX includes a complete notification model so MBeans can easily generate notifications, and managers can register for and get asynchronous notifications. These notifications are supported over each of the management protocols integrated with the JMX agents.
A common need for modular application architectures is a component model that can be remotely controlled, including adding, starting and stopping modules. JMX provides a great standard solution for this purpose, and enables applications to take advantage of its modular, extensible, lightweight architecture for this purpose. Some J2EE application servers, e.g. JBoss, use JMX as the core application control infrastructure. With this approach, standard application consoles, including HTML consoles, can be readily provided once JMX is integrated into the infrastructure.
Automating Management Instrumentation
By eliminating protocol and connector dependency cleanly from the MBeans and application instrumentation, JMX makes a number of other benefits possible. Management access to information and control of applications has always depended on providing this access through appropriate instrumentation. Through this simple but rich component model for creating this instrumentation, JMX makes it easier for developers. More importantly, it makes possible automated tools to generate instrumentation and radically simplify the burden on the application developer. This new breed of tool empowers the developer to quickly and easily provide the kind of information needed to properly manage his or her application.
JMX is also designed to meet the trend towards distributing application intelligence, rather than centralizing processing using dumb agents. This trend is driven by commoditization of processor power and memory, enabling more powerful distributed agents. Processing information closer to the source increases the ability to act on information instead of volumes of data and improves responsiveness. JMX therefore is a great fit with the drive to expose the appropriate information for business and service level management.
The rise of Java and J2EE for the development of server based applications, has led to standard component models for server-side development. These well-defined component models are used widely by application developers in building applications that are being deployed for mission-critical enterprise functions. JMX, with its model of application instrumentation, is a great fit with these standard ways of building applications in Java and J2EE. Not only does it make it easy for developers to build this application instrumentation, but also gives rise to new ways of automating this task.
Freed of the dependence on management protocols and specifics of management systems, exposing application management information and control can now be directly based on the application being managed. Tools that analyze the application and generate management are, thus, possible. And as a result a new category of automated management tools based on JMX is emerging. This frees the application developer from the burden of building management instrumentation. For example, there is no longer a need for the application developer to manually add instrumentation code to measure performance of business methods. The only task for the application developer is to select what information and control needs to be exposed for management, and the tools and JMX implementation take care of the rest. The tool can generate the management instrumentation code, compile, and even deploy it automatically in many cases.
In addition, to EJBs, Servlets, Java APIs and Java classes, there are a number of other resources that can be automatically exposed and instrumented via JMX. Data from log files and databases, SNMP, SOAP and other interfaces can readily be instrumented using such tools. This makes instrumentation of a complex IT infrastructure and applications possible, with a level of ease and flexibility not possible before.
An important consequence of this kind of tool is the ability to add and change the management information and control being exposed without touching or disrupting the application code itself. As a result, manageability can be added or changed at any time in the product lifecycle. As many application developers know, the management requirements sometimes change when the rubber meets the road. This type of tool allows for meeting these changing requirements, without the long delays associated with any change in the application code.
Given the new freedom offered to application developers and others to add manageability to an application at any stage, a number of benefits arise. The ability to easily overlay access to management information and control from the application opens many doors for business managers. Once applications become mission-critical and widely used, many ideas are generated in the business to improve visibility or use the information in the application to trigger pro-active management. However, managers often find these ideas are bound to the application software development cycle, which has to be a long cycle for any production application. The ability to quickly add manageability will make it possible for short-term projects that mine this information and provide pro-active monitoring.
In today's information economy, concepts like business activity monitoring (BAM) and real-time enterprise, all capture a common need of enterprises to get rapid access to information and respond quickly based on that information. BAM is a Gartner term for the concept of providing real-time access to critical business performance indicators to improve the speed and effectiveness of business operations. And the real-time enterprise is a similar idea where the end-to-end business processes in the enterprise are integrated in real-time, reducing lead times and improving efficiency and responsiveness to customer demands.
Let us consider the example of a call center where operators work on J2EE applications in each step of their call processing. The process manager needs to monitor many aspects of the systems used by operators to affect improvements in the process. Sometimes these are collected in logs or databases for his use. However, what needs to be measured often changes as the process manager looks for new efficiencies or tries modifications to the process. The ability to collect data on time spent in specific steps can help in driving and measuring efficiencies through process changes. For example, a process manager may want to know how much time operators spend accessing or searching a specific remote database for information, so that he can evaluate whether to invest in a faster local database optimized for their use. With the JMX tools, this kind of data can be mined at any time without interfering with or depending on the software development cycle of the call center application.
In a traditional model of changing the application every time a business need is identified, the cycles of implementation are too long. With JMX and the capabilities it open up, enterprises can quickly overlay management capability on existing applications without disrupting the application development or operation. The business objectives can thus be met in a very timely manner. JMX is therefore another powerful tool in an IT manager's arsenal to achieve the promise of BAM and real-time enterprises.
About the Author
Tony G. Thomas is CTO of AdventNet, the first independent vendor of JMX technology. AdventNet provides a range of standards-based management software products, which includes ManageEngine, a JMX-based rapid application manageability tool for J2EE and Java applications. Thomas oversees AdventNet's product and technology direction. At AdventNet, he led the development of the industry's first Java SNMP products and the industry's first Java and Web-based network management system. Thomas is a member of the Java Community Process Expert Group driving JMX standards. Prior to founding AdventNet, he was at AT&T Bell Laboratories where his responsibilities included building and managing OSS software solutions. He obtained his PhD in Engineering from the Johns Hopkins University. He can be reached at firstname.lastname@example.org.