| Java Management eXtensions (JMX) is a technology aimed at management and monitoring using the Java platform. JMX provides standard interfaces for connecting an application with a management infrastructure and management consoles. The JMX specification defines an architecture, programming design patterns, APIs, and a standard set of monitoring services. JMX facilitates the integration of a management infrastructure with popular management consoles, such as IBM Tivoli, HP OpenView, and Computer Associates Unicenter. JMX has been officially included as part of the J2SE 1.5 platform, and most Java middleware providers now expose JMX-based management facilities. JMX can be used to easily instrument any resource in a scalable fashion. Resources may expose configuration and runtime attributes, operations, and notifications. JMX provides APIs to dynamically query a resource's management APIs, access attribute values, invoke operations (such as start, execute, monitor, configure, operate, and stop), and subscribe to management notifications. This section will explore how a JMX-based management infrastructure can manage a highly distributed SOA in an ESB architecture. 10.3.1 A JMX Primer From a high-level view, the JMX architecture consists of the following components, (illustrated in Figure 10-7): JMX Server, which is a Managed Bean (MBean) server that contains MBean services JMX clients Protocol adapters and connectors JMX connector interface Managed Beans (MBeans), which serve as the interface for managed resources (applications)
These components are described in the following sections. Figure 10-7. Overview of JMX architecture 10.3.1.1 JMX server environment A management server, also known as an MBean server, provides a registry for MBean resources and MBean services. An MBean resource is a Java class that represents a resource to be managed or monitored. MBeans support interfaces that allow for instrumentation of a managed resource such that it can be enabled for receiving commands from and sending notifications to an MBean server. 10.3.1.2 JMX client protocol adapters A JMX client is an application that controls JMX management servers by submitting requests, activating new services, and receiving notifications. JMX relies on protocol adapters and connectors to make the MBean server remotely accessible from outside the server's JVM. A protocol adapter exposes a protocol directly to a client. For example, an HTML adapter exposes an interface to a web browser using the HTTP protocol. An SNMP adapter exposes SNMP directly to management consoles that support it. 10.3.1.3 JMX connector interface A JMX server may also be remoted using a connector[1] interface. The MBean server exposes an MBean's management interface across the connector. It does not expose the MBean's object reference directly; rather, a JMX client can dynamically interrogate the management interface that an MBean exposes. The management interface, management requests, and notifications are sent across the connector between the client interface and the MBean implementation on the server. [1] The use of the term "connector" in JMX parlance is not to be confused with a JCA "connector." The client side of the connector may be a specialized management console that was written from the ground up with JMX in mind, or it may be a client that acts as a proxy for JMX interfaces and uses some other proprietary means for communicating with a general-purpose management console. A connector implementation may use protocols such as RMI, IIOP, or HTTP. In the next section, Section 10.3.2, we will explore how an ESB may use messaging as a transport for JMX management communications. An MBean server containing MBean services, a set of MBeans that represent managed resources, and one or more protocol adapters or JMX connectors are collectively referred as a JMX agent or JMX container. 10.3.1.4 JMX MBean interfaces An MBean interface contains metadata that describes the following: - Attributes
-
Attributes include state information about the resource being managed. In an ESB environment this can include the following:
Attributes that indicate whether a remote service is in a ready state, or has been shut down or temporarily halted Counts, such as the number of messages pending in a queue, or the number of active service instances in a service container Settings, such that a remote JMX client can have a set of names and values that it can manipulate through operations
- Operations
-
Operations can include actions, or commands that can be executed on managed resources. In an ESB environment, these types of actions can be performed as commands issued to a remote service through its service container. This can include lifecycle commands such as shutdown, restart, suspend, and resume, and may also include commands to components of the ESB, such as telling a message queue manager to clear a specified set of undelivered messages from its queue. - Notifications
-
JMX defines a notification model, with senders that broadcast notifications and listeners that receive notifications. Through the connector interface, notifications emitted by the MBean are propagated to JMX clients that have registered interest on such notifications by providing a notification listener callback object. Notifications can be generated either by managed resources or by the JMX-specified monitor MBeans that can be used to monitor an attribute value. Examples of notifications in an ESB environment include:
Alerts based on certain thresholds being reached, such as the size of a message queue approaching its maximum specified size limit Connections into the ESB being established or dropped Message delivery timeout and subsequent routing to a dead message queue
10.3.2 JMX Management in an ESB Architecture Most JMX implementations assume a client-server model where JMX connectors use RPC protocols such as RMI, IIOP, and HTTP to connect JMX agents with JMX clients. In an ESB architecture, the JMX connectors can be implemented using the ESB messaging layer, as illustrated in Figure 10-8. Figure 10-8. A JMX management layer implemented across a messaging layer of the ESB (JMS) Figure 10-8 shows the underlying messaging topology of an ESB MOM core being used to link a corporate headquarters (the Head Office) with multiple regional offices and a business partner. Note that JMX management communications can be carried across the same secure messaging topology that is being used for the business-level communications. There are several advantages of using this approach over other protocols such as RMI or HTTP: - Messaging
-
Using JMS messaging, a management console may asynchronously push commands or configuration settings to multiple remote JMX agents. - Reliability
-
Management communications can enjoy all the benefits of asynchronous reliable messaging. For example, using reliable messaging and durable subscriptions, remote JMX agents may receive instructions even if the agent is temporarily unavailable. - Fault tolerance
-
If the message broker infrastructure supports fault-tolerant clusters with failover capabilities, the JMX communication can take advantage of that. If a message broker goes down for any reason, a backup broker can take over with no negative impact on the transfer of management data. - Centralized configuration
-
The MOM can be used to remote the configuration store (directory service) so that each JMX container does not need its own fully replicated directory service. - Firewall security
-
The deployment topology in Figure 10-8 shows that the only communication link that needs to be opened in the firewalls between the headquarters and other locations is the single link between the message brokers. The alternative (using a point-to-point protocol such as RMI) would likely require an unmanageable number of holes in the firewalls. - Authorization and secure access
-
The management console can gain access to all of the remotely managed agents, given that the proper security credentials are in place. In Figure 10-8, the management console at headquarters has authorized access to all of the remotely accessible nodes in the regional offices and the partner site. The management console at the remote partner site could intentionally be restricted to only have access to the local agents at that site. - Minimize network configuration
-
If you are going to set up a messaging infrastructure like this anyway, why maintain a parallel RMI infrastructure just for the management layer? Of course, this approach of using JMX across a messaging infrastructure works effectively only if the ESB MOM core supports a fully connected distributed topology that is capable of linking remote messaging domains in such a fashion. 10.3.3 JMX-Managed Components in an ESB In an ESB architecture, individual components of an ESB can be managed by a JMX agent. Figure 10-9 shows message brokers and ESB containers being managed by JMX agents that are using a JMS connector to communicate with each other. One of the message brokers is acting as a domain manager, which manages all of the other JMX agents that are within a designated realm of control. It serves as a domain manager because it has direct control and access to a directory service that holds all of the configuration information for the entire ESB segment. Figure 10-9. JMX agents manage ESB components using a JMS connector Examples of configuration information that can be remotely managed include: Endpoint definitions for service interfaces, described using WSDL. Message channels, which have many characteristics to be configured. For example, the channel name; whether the channel is designated for publish-and-subscribe or point-to-point queuing; and message queue tuning capabilities such as a setting that specifies how much a message queue can hold in memory before it starts flushing its message to disk. Configurable settings for an ESB service, such as those discussed in Chapter 6. XSLT stylesheets, JavaScript helper functions, JAR files, process itineraries, WS-BPEL scripts, XQuery scripts, and CBR rules can all be specified using the management layer, and propagated out to remote service containers. Security information, such as allowable security credentials for access to endpoints. ACLs and QoP settings on individual message channels can be also remotely managed by the management layer.
10.3.4 Directory Cache In a centralized hub-and-spoke EAI broker, there is an intrinsic advantage to centralized configuration in that all of the configuration information can be managed in a single place. However, such an architecture creates a single point of failure. In an ESB architecture, a directory service can push its content out to remote containers that maintain their own local caches of configuration information, as illustrated in Figure 10-10. Figure 10-10. The ESB-managed component maintains a local directory service cache, thus eliminating the single point of failure Any ESB-managed entity, such as a service container or message broker, can have its own local directory service cache. In Figure 10-10, the directory service and the management console are located elsewhere on the bus, and the directory cache is colocated with the ESB service container. As new information is updated in the directory service, it can be proactively pushed out to the remote directory service caches. This prevents the directory service from being a single point of failure. If the directory service becomes unavailable for any reason, the ESB service container can continue to function using its locally cached information. 10.3.5 Template-Based Remote Configuration Replication Remotely managed ESB entities often have much in common with each other. For example, in the video-store scenario mentioned in Chapter 1, each of the remote stores has its own local messaging traffic and its own local service containers for integrating with the local point-of-sale kiosks. A common configuration template can be created for each store that describes the integration characteristics that all remote stores have, such as the local messaging channel definitions and the routing information that controls how messages flow between applications within a store and back to headquarters. Using a single management console interface, a configuration template can be created once and then subclassed for each location prior to being pushed out to all of the remote stores. This local configuration can be done by IT staff at headquarters through a remote management console. If any change needs to be made to the shared configuration, it needs to be done only once by changing the configuration template, and the changes can then be made immediately available to all of the remote stores without disrupting the local configurations. This can potentially affect hundreds or even thousands of remotely managed ESB containers and message brokers. If the underpinnings of the management infrastructure are based on a message channel infrastructure, large-scale changes can be propagated efficiently. These changes would have been impractical or impossible if each site was connected to explicitly in a 1-to-1 fashion. |