Most Read This Week
Accessing MBeans Through the Jini Service
Accessing MBeans Through the Jini Service
By: Frank Jennings
Sep. 1, 2003 12:00 AM
Network systems based on service discovery can provide a consistent view of their distributed components even during changing network conditions. The ability of a system to heal itself during a network catastrophe, including architectural change and system breakdown, will help the system to realign its content traversal route intelligently and swiftly. This ability can be obtained from various healing strategies like failure detection, consistency maintenance, and distributed service activation techniques.
A complete understanding of the interactions among self-healing strategies would provide architects of distributed systems with the knowledge necessary to build the most effective catastrophe-free network system with minimum overhead. A self-healing, manageable distributed system can be developed using a Jini federation. Since Jini is focused on service-oriented programming and supports the discovery of services, active or dormant, identifying service failure and recovering from a major disaster is possible.
As a rule of thumb, a network system is not complete if it's not manageable remotely. Hence there should exist a framework for exposing the application or Jini service for remote configuration. MBeans do just that.
Accessing MBeans from a different VM or a remote location can be done using a protocol adapter or connector. Connectors are similar to protocol adapters but they need the presence of a wrapper at both the server and the client sides; adapters are software, listening on the server side, built on a common protocol that the client is expected to understand and access. The JMX agent that starts the MBean server should let remote clients invoke methods on the MBeans registered in the MBean server.
The conventional way of accessing the MBean server from a different location is by using an RMI connector. RMI connectors are inherently MBeans registered in the MBean server. The remote client can access the MBean server using the RMI connector client. While this seems to be a neat solution for remotely accessing MBeans, the client needs to know the physical location of the MBean server. Even if the the MBean proxy is bound to a lookup, the client should know the lookup location. Even when using protocol adapters like the HTML and SNMP adapters, the client is expected to know the server location.
Consider a typical setup, such as a distributed content management system running on an agent framework, where the publishing server doesn't need to know where the content updating modules are running since it can be run by an editor, writer, or a designer in different locations. Implementing a simple connector does not solve this problem. This article explores the possibilities of using a discovery mechanism to find out where the JMX agent is running. This can be achieved by using a Jini connector, which is registered as an MBean with the MBean server.
However, we don't actually discover a running JMX agent but we discover the Jini lookup service that holds the proxy of the Jini service, which is also registered as an MBean with the MBean server. Figure 1 shows the MBean invocation process between two different VMs.
Management Through MBeans
Discovering MBean Agents
Reggie for Discovering Agents
Accessing Remote Agents
In this article we'll build a simple Jini connector that registers itself with the MBean server and exposes the MBean agent for remote administration. Figure 3 shows the MBean list through an HTTP adapter showing the Jini connector and a configurable test string. The Jini connector is comprised of the service, which we want to register with the lookup service, the MBean, and a Jini client. Figure 4 shows the Jini lookup browser showing the Jini service class and the JiniWrapper registered with it. The MBean enables the agent to control the Jini service and, as you refer to the source code (which you can download from www.sys-con.com/java/sourcec.cfm), the MBean has a reference to the MBean server, which allows the Jini service to perform callbacks to the MBean server methods. The Jini client forwards its method invocation to the MBean server via the Jini service. The Jini client-side application discovers and uses the Jini connector service and therefore can use the agent.
The process of setting up a Jini environment can be frustrating at times. For this reason, I've provided some instructions (see sidebar). Though our service does not register with the RMI activation daemon, enabling auto-restart during crashes, the Jini lookup service, an activateable service, requires RMID running on the same VM. So make sure the lookup service and RMID are running in the same VM. The Jini connector service can be run in any VM as long as the correct server codebase is specified for dynamic classloading. When the client gets started, it finds out the lookup service and hence the agent, and tries to get the MBean registration information, MBean count, and the test string value. It also dynamically changes the value of the string that can be viewed in a browser (see Figure 2). The output of the client is shown in Figure 5.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads