Previous Next Contents Index


3

Design Patterns for Developing M-Beans

A managed bean, or m-bean, is a Java object that conforms to certain design patterns. These design patterns are derived from the JavaBeans component model and are described in detail in this chapter. They enable properties, actions, and events to be defined for an m-bean. They also enable you to make the distinction between a read-only and a read-write property in an m-bean. To comply with the design patterns for m-beans, an m-bean must be a JavaBeans component.

Introduction

The design patterns for developing m-beans consist of:

Except where stated, the design patterns defined in this chapter are taken from the JavaBeans component specification. The design patterns that are specific to the m-bean model are compatible with the JavaBeans component model, but their meaning is not recognized outside the context of a Java Dynamic Management agent.

Properties

Properties are discrete, named attributes of a JavaBeans component that define its appearance or its behavior, or are a property of the managed resource that the m-bean represents. For example, a property named ipackets in an m-bean representing an Ethernet driver could be defined to represent the number of incoming packets.

Properties can have arbitrary types, including built-in Java types, and class or interface types such as java.awt.Color.

Properties are always accessed via method calls on the object that owns them. For readable properties, there is a getter method to read the property value. For writable properties, there is a setter method to allow the property value to be updated.

Simple Properties

By default, the following design pattern is used for identifying properties:
public PropertyType getPropertyName();
public void setPropertyName(PropertyType value);

If a class definition contains a matching pair of getPropertyName and setPropertyName methods that take and return the same type, these methods define a read-write property. If a class definition contains only one of these methods, the method defines either a read-only or write-only property called propertyName.

CODE EXAMPLE 3-1 provides an example of a simple read-write property.

CODE  EXAMPLE  3-1     A Simple Read-Write Property

public Square getFoo();
public void setFoo(Square aValue);

Boolean Properties

In addition, for Boolean properties, it is possible to define a getter method using the following design pattern:
public boolean isPropertyName();

The isPropertyName method might be provided instead of a getPropertyName method, or it might be provided in addition to a getPropertyName method.

CODE EXAMPLE 3-2 provides an example of a Boolean read-write property.

CODE  EXAMPLE  3-2     A Boolean Property

public boolean isRectangle();
public void setRectangle(boolean m);

Indexed Properties

An indexed property is an array PropertyElement[] that is accessed by methods of the form:
public PropertyElement getPropertyName(int index);
public void setPropertyName(int index, PropertyElement b)

If a class definition contains any one or both of these method forms, PropertyName is an indexed property. These methods can be used to read and write an indexed property value.

These methods can be defined in addition to the methods defined for simple properties. Therefore, an indexed property can be represented by four accessor methods. This is illustrated for a property called foo by CODE EXAMPLE 3-3.

CODE  EXAMPLE  3-3     An Indexed Property

public Bah[] getFoo();
public void setFoo(Bah a[]);
public Bah getFoo(int a);
public void setFoo(int a, Bah b);

Event Sources

The JavaBeans component model defines design patterns for:

Multicast Event Sources

By default, the following design pattern is used to define which multicast events an m-bean can send:
public void addEventListenerType(EventListenerType a);
public removeEventListenerType(EventListenerType a);

Both the methods take the same EventListenerType type argument. EventListenerType is a Java interface which conforms to the following rules:

This design pattern assumes that the m-bean is a multicast event source for the events specified in the EventListenerType interface.

CODE EXAMPLE 3-4 defines a multicast event source.

CODE  EXAMPLE  3-4     A Simple Listener

public void addFredListener(FredListener a);
public void removeFredListener(FredListener a);

Unicast Event Sources

By default, the following design pattern is used to define which unicast events an m-bean can send:
public void addEventListenerType(EventListenerType a)
throws java.util.TooManyListenersException;
public removeEventListenerType(EventListenerType a);

These design patterns are the same as those defined in "Multicast Event Sources" on page 36, except that the signature of the addEventListenerType method includes the clause throws java.util.TooManyListenersException. This exception is thrown if the addEventListenerType method is invoked when a listener is already registered.

Both the methods take the same EventListenerType type argument. This design pattern assumes that the m-bean is a unicast event source for the events specified in the EventListenerType interface.

Initializing and Deleting an M-Bean

Note - The methods for initializing and deleting an m-bean are not part of the JavaBeans component model, but are specific to the m-bean model.
The methods for initializing and deleting an m-bean are callbacks which the framework invokes. They are optional for an m-bean but if you want to provide them, you have to write them yourself. The methods are:

Initializing an M-Bean - initCmf Method

The initCmf method is invoked by the framework when it is requested to register an instance of an m-bean that contains this method.

The initCmf method you define must have one of the following signatures::

public void initCmf(Framework cmf, ObjectName name)
throws IllegalAccessException,
ServiceNotFoundException,
InstanceAlreadyExistException;


public void initCmf(Framework cmf, ObjectName name,
boolean persist, ModificationList list)
throws IllegalAccessException,
ServiceNotFoundException,
InstanceAlreadyExistException;

The parameters in the call to initCmf are as follows:

The initCmf method must include a call to one of these methods to register the m-bean:

Refer to "Registering an Existing M-Bean" on page 43 for more information.

Defining an initCmf method for an m-bean enables you to define actions to be carried out for the m-bean. For example, an m-bean could be implemented to:

The services provided under com.sun.jaw.impl.agent.services contain an implementation of the initCmf method.

Deleting an M-Bean - deleteCmf Method

The deleteCmf method is invoked by the framework when it is requested to delete an instance of an m-bean that contains this method.

The deleteCmf method you define must have the following signature:

public void deleteCmf()

The services provided under com.sun.jaw.impl.agent.services contain an implementation of the deleteCmf method.

Actions

Note - The action design pattern is not part of the JavaBeans component model, but is specific to the m-bean model.
An action is a public method of an m-bean that is intended to be invoked remotely. Public methods in an m-bean that are not actions are intended to be invoked only by other local m-beans.

It is not necessary for all public methods in an m-bean to be able to be invoked remotely. The action design pattern acts as a filter for the methods that you want to be invoked remotely. The mogen compiler generates code in a c-bean only for actions in addition to property accessor methods. It does not generate code for other public methods of an m-bean.

The design pattern for an action is as follows:

public AnyJavaType performAnAction(AnySignature)


Copyright 1998 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303 U.S.A.
Copyright in French
Previous Next Contents Index