Novell is now a part of Micro Focus

How to Build J2EE Applications Using Novell Technologies: Part 5

Articles and Tips: article

J. Jeffrey Hanson
Chief Architect
Zareus Inc.
Jhanson583@aol.com

01 Sep 2002


This AppNote is the fifth in a series that outlines a platform and methodology for Java 2 Platform Enterprise Edition (J2EE) application development on NetWare using a service-oriented architecture. In this AppNote, we will learn more about JMX (Java Management Extensions) and present some of the other services that JMX offers to empower our platform. We will then further explore the JMX-enabled kernel introduced previously.


Topics

Java application development, J2EE, Java Management Extensions (JMX)

Products

Java 2 Enterprise Edition

Audience

developers

Level

intermediate

Prerequisite Skills

familiarity with Java programming

Operating System

n/a

Tools

none

Sample Code

yes

Introduction

This is the fifth in a series of AppNotes outlining a platform and methodology for Java 2 Platform Enterprise Edition (J2EE) application development on NetWare using a service-oriented architecture.

In the previous AppNote we introduced a JMX-enabled kernel for our platform. We also delved deeper into the business tier and explained how our services interact with the kernel. In this AppNote, we will learn more about JMX and present some of the other services that JMX offers to empower our platform. We will then further explore the JMX-enabled kernel introduced previously.

More About JMX

The JMX specification is divided into three levels: instrumentation, agent, and distributed services. This allows different parts of the specification to be individually utilized by different developers.

  • The instrumentation level contains items that allow management applications to communicate with JMX agents. This level contains managed beans (MBeans) and their manageable resources. An MBean is anything that can be represented as a Java object.

  • The agent level provides technologies to build management agents. This level contains agents and their MBean servers, as well as appropriate services. It manages the communications, storage, and lifecycle of the MBeans.

  • The distributed services level contains parts that allow management applications to communicate with JMX agents. This level contains protocol adapters and connectors, as well as distributed notifications. It enables remote clients to connect to agents.

Following are some notable benefits of JMX:

  • Transparent handling of remote communications between clients and servers

  • Real-time monitoring and resource reloading

  • Hot-deployment of resources

  • Enabling the use of generic administration tools to manage components at runtime

  • Eliminating the need for manual administration of multiple configuration files and property files

Agent Services

The agent level stores data about managed resources and basic common management interfaces used by JMX-managed systems. This level provides a way to implement management agents, which control resources and make them available to management applications.

A JMX agent is a Java process that provides a set of services for managing a set of MBeans. An agent provides remote management application access to all registered MBeans, and is the center of the JMX framework. The agent also provides additional services, which are registered MBeans, so they can also utilize and benefit from the JMX framework.

An agent must perform certain mandatory services and can also contain other optional services. Management operations are performed by agents on MBeans registered in an MBean server; they are often implemented as MBeans themselves, and can also be controlled by an MBean server.

The following table lists the agent services of the JMX specification.


Service
Description

Dynamic class loading

Retrieves and instantiates new classes from an arbitrary location specified by a URL using the M-Let (management applet).

Monitors

Observes an MBean's attribute values at specified intervals and notifies other objects if target conditions, called gauges, have been satisfied.

Timers

Provides a scheduling mechanism that triggers notifications at certain predefined intervals, or specified dates and times.

Relations service

Enables user-defined associations between MBeans using roles and maintains consistency of all relations by checking MBean operations to ensure validity.

Relationships

The JMX specification defines instrumentation and management of resources (such as components, services, configuration files, applications, and so on) by providing an architecture consisting of a set of patterns and a framework of APIs. Management of resources (known as Mbeans) is standardized by the JMX specification, which unifies them within an open and extensible architecture. JMX separates management interfaces from implementation details; thus it promotes efficient object-oriented practices.

Notifications

In the JMX model, MBeans are allowed to broadcast notification events. The JMX event model is similar to the JavaBeans event model, because objects register as listeners with an MBean to receive events that are transmitted by the MBean.

The MBean notification model expands on the JavaBeans event model, as the MBean notification model enables a listener object to register once with a broadcasting MBean and receive all events transmitted by the broadcasting MBean. Notification events can be transmitted by MBeans and by an MBean server.

The JMX notification model defines the following components:

  • Notification class, which extends the java.util.EventObject class, to indicate any type of notification event.

  • NotificationListener, which extends the java.util.EventListener interface, which is implemented when objects desire to receive notification events transmitted by MBeans.

  • NotificationFilter, which extends the java.io.Serializable interface, implemented by objects that serve as filters for notification events, allowing notification listeners to filter notification events transmitted by an MBean.

  • NotificationBroadcaster, implemented by an MBean that transmits notification events, defining methods that allow objects to register as listeners with an MBean. The broadcasting MBean can also return information about the notification events.

Distributed Services

The distributed services level concerns itself with how remote clients connect to agents. It defines entities that operate on agent-level components. Remote management tools gain access to an agent using any number of communication protocols. Some common protocols used by remote agents include SNMP, HTTP, SOAP, RMI/IIOP, JMS and others. A client running in a different process or on a different machine can manipulate an agent and the MBeans registered with it once the agent has made itself available remotely.

Agents that use an HTTP interface allow management applications to control them using a Web browser, which can be very advantageous if an agent resides behind a firewall. Agents that provide SNMP support allow many existing network management tools, such as IBM's Tivoli, to control them and the MBeans they contain. This allows companies to benefit from the investment they have made in training existing employees on these tools.

Some of the components provided by the distributed level include:

  • Protocol adaptors, providing the means for the clients of the protocols to interact with the agents using semantics of each given protocol. Examples are HTML and SNMP.

  • Connector components, providing transparent interaction between management applications and an agent. "Transparent interaction" means the interaction behaves in the same fashion whether the agent is local or remote.

  • Manager components, controlling multiple agents and providing security for the transactions taking place between them.

An agent relies on protocol adaptors and connectors for accessing management applications outside of the JVM in which it resides. Each protocol adaptor offers unique views of an agent over the specified protocol. Connectors rely on a client and server component that is unique to the given protocol, but expose the same interface to a client allowing access to the agent regardless of the underlying protocol. Both protocol adaptors and the server components of connectors act as liaisons between agents and remote management applications.

An agent must provide at least one protocol adapter or connector in order to be accessed remotely. However, an agent can provide multiple protocol adaptors or connectors to any number of heterogeneous management applications simultaneously. Protocol adaptors and connectors are usually implemented as MBeans, allowing the same benefits that manageable resources enjoy, such as hot deployment, runtime modifications, and others.

Protocol Adapters

Protocol adapters allow management applications to access an agent and manipulate it using any given protocol that the adapter supports, such as HTML, SOAP or SNMP. They use a given protocol to provide a management view of the JMX agent. Protocol adapters provide views of the agent and the agent's MBeans suitable for a given protocol, such as a Web browser view for an HTML adaptor. Protocol adaptors are used when management applications rely on a specific protocol, such as legacy applications.

Connectors

Connectors are used to connect an agent with remote management applications over a variety of protocols. Connectors consist of a server component in the agent and a connector client in the management application. All connectors for a given agent expose the same Java interface, allowing applications to choose the interface that most precisely fits the needs of the application. As the management application changes over time, the connector used by the application can automatically change without modifying the code in the application or the agent.

A typical use of protocol adaptors and connectors.

Promoting the Kernel

Our kernel uses JMX to manage all components. Each component registered with our kernel automatically becomes manageable by any JMX-aware management tool. To provide a registry and lifecycle manager for services, we will use the MBean server and the agent's relations service. These two entities will collaborate to form a bond between the business services and the kernel.

The kernel uses JMX to provide structure for services to be added, removed, and updated dynamically. The kernel also provides a means to create inter-service relationships, by providing a "sandbox" where each service plays. This ensures that the services behave in a well-defined, secure, and efficient manner.

The following code sample demonstrates the fundamental features for starting our kernel, registering services, removing services, and invoking operations on a service.

import java.util.*;

import java.lang.reflect.*;

import javax.management.*;

    

public class Kernel

{

    public static final String OUR_DOMAIN = "J2EEonNetWare";

    

    private HashMap services = new HashMap();

    private MBeanServer mbeanServer = null;

    

    public static void main(String[] args)

    {

        Kernel kernel = new Kernel();

    }

    

    public Kernel()

    {

        ArrayList list = MBeanServerFactory.findMBeanServer(null);

        if ((list == null) || (list.size() == 0))

        {

            mbeanServer = MBeanServerFactory.createMBeanServer(OUR_DOMAIN);

        }

        else

        {

            mbeanServer = (MBeanServer) list.get(0);

        }

    }

    

    private void registerMBean(Object resource, String name)

        throws Exception

    {

        ObjectName objectName = new ObjectName(OUR_DOMAIN, "service", name);

    

        mbeanServer.registerMBean(resource, objectName);

    }

    

    public Object invokeService(String serviceName,

                                    String operationName,

                                    Object[] args,

                                    Class[] parameterTypes)

        throws Exception

    {

        Object retval = null;

    

        Object service = services.get(serviceName);

        if (service == null)

        {

            throw new Exception("Unable to find service: " + serviceName);

        }

        else

        {

            Method method = service.getClass().getMethod(operationName,

                                                                    parameterTypes);

            if (method == null)

            {

                throw new Exception("No such operation: " + operationName

                                            + ", for service + " + serviceName);

            }

            else

                retval = method.invoke(service, args);

        }

    

        return retval;

    }

    

    private void registerService(String name, Object service)

        throws Exception

    {

        registerMBean(service, name);

    }

    

    public void addService(String name, Object service)

        throws Exception

    {

        registerService(name, service);

        services.put(name, service);

    }

    

    public Object removeService(String name)

    {

        return services.remove(name);

    }

}

Conclusion

In this AppNote, we further explored the platform kernel in relation to services that JMX offers to empower our platform. In the next AppNote in this series, we will see how the platform interfaces with the data tier and how we can build data-access components in a highly flexible and robust manner.

For Additional Information

For more information about the technologies discussed in this AppNote, refer to the following resources:

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates