This chapter is from the book
This chapter is from the book
This chapter is from the book
2.3 The Goals of JMX
There has been incredible growth in the number of mission-critical Web-based and Java applications being developed. The Web applications bring new business to the enterprise. Java e-business applications actually conduct business transactions on the Web, including catalog and shopping cart applications. E-business applications that generate income for the enterprise become mission critical in a hurry. When these applications are not available or responding quickly, customers shop elsewhere and income is lost. Therefore, enterprises are demanding end-to-end application manageability for e-business applications. The manageability requirement applies to the device, system, network, middleware, and any other applications that the e-business applications depend on.
In order for Java applications to make this transition from "cool" Web applications to "critical" e-business applications, they must be well behaved, reliable, and manageable. These requirements, along with the need for end-to-end management of these applications, mean that customers and developers will demand that products be manageable out of the box. These products include application servers, distributed application infrastructures, component toolkits, and the applications themselves.
Ideally, development tools and environments would provide wizards and tools to make it easy to develop manageability along with the product. These tools need a standard, portable, flexible API in order to be able to generate or modify applications so that they are manageable.
JMX defines a set of APIs to address management of and through Java. Three main influencing forces on the success of JMX are (1) having a simple API for the developer, (2) ensuring enough information for management systems to manage the resource "generically," and (3) providing an architecture to support the management of diverse, dynamic applications. Figure 2.1 shows the relationship of the JMX MBeanServer to the resources it manages and the management systems it communicates with. The following paragraphs will explain further.
)
Figure
2.1 JMX Overview
2.3.1 Simple API
JMX provides a simple, straightforward management API for Java application developers. You can use this API to bring attributes, operations, and notifications to management systems from within your application. The API is easy to understand because it is similar to one you already know: JavaBeans. JMX uses Management Beans (MBeans) to represent the management interface for the managed resource (see Section 2.5.2). As you can see in Figure 2.1, the MBeans interact with the resources they manage: memory, ports, and printers. You can use your existing JavaBeans as MBeans, like the catalog MBean in Figure 2.1, or you can easily develop new ones as facades for your existing Java applications.
2.3.2 Dynamic Management
JMX provides a "management container" called an MBeanServer. The MBeanServer is a registry and a "traffic cop" in that it is always between the MBeans and their users. You can see this relationship in Figure 2.1. You can register your MBean with the MBeanServer at any time. You can also deregister your MBean at any time. Therefore, the MBeanServer represents an accurate inventory of all the resources to be managed. If resources are permanently removed from the system, you can remove them from JMX without reconfiguring or recycling the MBeanServer. JMX also provides for management services to be registered as MBeans. This means that additional functionality can be added or removed at any time. This flexibility makes JMX a dynamic and easily extensible architecture to use for management.
2.3.3 Isolation
The MBeanServer acts as the isolation or mediation layer between your application and management system vagaries, including protocols, behavior, platforms, and so on. The management system is encapsulated away from the managed resources by JMX adapters. JMX adapters, as seen in Figure 2.1, translate from the MBeanServer's MBeans to the management systems' native protocols and object models, and back again.
In fact, these adapters don't have to be provided by the management system; they could be developed by anyone. If the adapters communicate with a local management agent on the system, like an SNMP agent, then the management system will never "see" JMX. This means that the management system may not be aware if JMX is providing access to the manageability of your application.
2.3.4 Generic Management
Many current management systems require a custom module to be written for every application they are to manage. This module integrates the application's management into the management system. One of the goals of JMX was to provide sufficient information to the management systems so that management support could be generated or provided generically (i.e., without developers having to create custom integration modules for their applications for every management system). Ideally, the management system would provide a tool, along with its adapter, that would generate these integration modules if they were needed.
When information is being provided to management systems, either a management model or metadata must be supplied. JMX is a model-less management architecture; it deliberately does not define an information model or the structure of management information (SMI) like the IETF did for its Network Management Framework.15 Instead, JMX provides metadata in MBeanInfo objects associated with every MBean. Management system adapters and tools can use the information in the MBeanInfo object to create integration modules or feed dynamic management architectures.