???? Since Model MBean is much more flexible and is easy to decouple your manageable resouce from?the mbean implementation details, people like to use it as the basic MBean. After we examine the Model MBean, let's see how to write our own Model MBean. First, let's review the Model MBean class diagram showed previously.

?And we can see from the above, a complete Model MBean is much more complicated but also much more powerful. It can do a lot things, like persisting its state to a local file or remote db, or notifying other components it works with to do some corresponding tasks when some attributes of it change or some specific operations occur. But as I said in the Model MBean blog entry, the main purpose of Model MBean is to make creating the MBeanInfo and the manageable resource outside of the MBean system being possible.So we can leave the persisting ability and the notifying ability out for?this moment. And the simple Model MBean should be like the below:

?? And according to the purpose of the Model MBean, the ModelMBean interface should at least contains two operations, one for holding the MBeanInfo metadata and the other for holding your manageable resource, which maybe like the below codes show:

    public interface ModelMBean extends  DynamicMBean   
{   
  
public void setMBeanInfo(MBeanInfo mbeanInfo) ;   
           
public void setManagedResource(Object mr);   
       
}  

  

?

?? And it is straight, after that, let's try to finish our Model MBean, first of all, we need to find a better way to construct our MBeanInfo, you know, constructing a MBeanInfo metadata is a tedious, repetitive work and you wouldn't like to do that again if you did that before. This is also the problem of Dynamic MBean. Some people may come up with an idea of configuring them in a file, yeah, it is the traditional way to do it. And using annotations will be another way to handle this situation.

?

??? Now let's start with the traditional way, configuring them in a file. And it's no doubt the xml file will be our first choice. And then we need to map each of the mbean meatadata to its corresponding xml element. Recall from the Dynamic MBean, we got 5 MBean metadatas, MBeanConstructorInfo, MBeanOperationInfo, MBeanAttributeInfo, MBeanParameterInfo and MBeanNotificationInfo. You might find out the relationship btw the mbean metadata and its corresponding xml element from the below xml.

    <mbean name="test mbean" domain="Test"
	className="com.telenav.cserver.framework.management.jmx.support.test.Person">
		
	<attr name="name" type="java.lang.String" description="name of person"
		readable="true" writable="true" is="false" />
			
	<op name="printHouseInfos" type="java.lang.String" description="only print infos">
		<param name="msg" type="java.lang.String" description="the msg will be used to print" />
		<param name="age" type="java.lang.Integer" description="only for test, useless" />
	</op>
		
	<con name="Person" description="the person constructor"/>
		
	<notification name="test.person.notification" description="the person notification" notifyTypes="test.Person"/>
</mbean>
  

??? If you examine each xml element with the constructor of its corresponding mbean metadata, you will find that the content of xml file above is easy to understand. Like <attr> element, it refers to a MBeanAttributeInfo mbean metadata and its attributes like name, type etc are actually the arguments of the MBeanAttributeInfo constructor.

??

     public MBeanAttributeInfo(String name,
			      String type,
			      String description,
			      boolean isReadable,
			      boolean isWritable,
			      boolean isIs)
  

???

?? ?And the rest is similar.?The general idea of this is that when we meet with a xml element, we will?create a corresponding mbean metadata, for example, when we meet with a <attr> element, we will create a MBeanAttributeInfo by using the attributes of <attr> element, but I dont want to construct a MBeanAttributeInfo directly, since I want to take more control over it. Think of the case, as we know, most of our java beans are readable and writable, thus we can simplify our <attr> element without specifying its readable,writable attribute, that is to say, they are true by default. If we create a MBeanAttributeInfo directly when we meet with a <attr> element, we have to do this kind of thing in the parsing xml logic, bad smell, isn't it? And if one day, we want to build our application on another jmx framework, as opposed to sun's jmx framework, then it seems that we have to do a lot of work to

get used to a new jmx framework. So, the better way is to build our own model, which will wrap a corresponding mbean metadata. And the following is a big picture of the above model.

??

?? Notice that all our Model implements a common interface, ICreateMBeanFeature interface, which only exposes a createMBeanFeature() method:

    public interface ICreateMBeanFeature<T extends MBeanFeatureInfo> {
	public T createMBeanFeature();
}
  

??? And from the above picture, we can see that the createMBeanFeature() is used to create the subtypes of MBeanFeatureInfo like MBeanAttributeInfo, MBeanOperationInfo etc.

???

    public class ExposedAttribute extends ExposedFeature {
	......

	public MBeanAttributeInfo createMBeanFeature() {
		info = new MBeanAttributeInfo(getName(), getType(), getDescription(),
				isReadable(), isWritable(), isIs());
		return (MBeanAttributeInfo) info;
	}

}
  

?

??? In this manner, we will parse the xml into our Model, ExposedFeature object, and then it will create a corresponding mbean metadata from its createMBeanFeature() method, and make up the MBeanInfo we want. Now that?we know how to create the MBean metadata, do we need a container to collect the created mebean metadata? Yes, we do, since I dont want?to mix?our parsing logic with the mbean metadata collecting logic. Then we need a parser and a MBean metadata?holder,?called ManagedMBean.

?

    #ManagedMBean

public class ManagedMBean {

	private List<ExposedAttribute> attributes = Collections
			.synchronizedList(new ArrayList<ExposedAttribute>());
	private List<ExposedOperation> operations = Collections
			.synchronizedList(new ArrayList<ExposedOperation>());
	private List<ExposedConstructor> constructors = Collections
			.synchronizedList(new ArrayList<ExposedConstructor>());
	private List<ExposedNotification> notifications = Collections
			.synchronizedList(new ArrayList<ExposedNotification>());


     ......
    
     public MBeanInfo getMBeanInfo() {
		// For creating MBeanAttributeInfos
		MBeanAttributeInfo[] attributeInfos = new MBeanAttributeInfo[attributes
				.size()];
		int attrIndex = 0;
		for (ExposedAttribute attr : attributes) {
			attributeInfos[attrIndex++] = attr.createMBeanFeature();
		}

		// For creating MBeanOperationInfos
		MBeanOperationInfo[] operationInfos = new MBeanOperationInfo[operations
				.size()];
		int opIndex = 0;
		for (ExposedOperation op : operations) {
			operationInfos[opIndex++] = op.createMBeanFeature();
		}

		// For creating MBeanConstructorInfos
		MBeanConstructorInfo[] constructorInfos = new MBeanConstructorInfo[constructors
				.size()];
		int conIndex = 0;
		for (ExposedConstructor con : constructors) {
			constructorInfos[conIndex++] = con.createMBeanFeature();
		}

		// For creating MBeanNotificationInfos
		MBeanNotificationInfo[] notificationInfos = new MBeanNotificationInfo[notifications.size()];
		int notiIndex = 0;
		for (ExposedNotification noti : notifications) {
			notificationInfos[notiIndex++] = noti.createMBeanFeature();
		}

		return new MBeanInfo(getClassName(), getDescription(), attributeInfos,
				constructorInfos, operationInfos, notificationInfos);
	}

}
  

???

??? And our parser interface, it defines where to locate the configurable file and the parsing logic.

??

    public interface IMBeanParser {
	public List<ManagedMBean> parse();

	public void setMBeanFilePath(String path);
}
  

??

??? Since now we have introduce the ManagedMBean object, we need to change our IModelMBean interface too.

??

    public interface IModelMBean extends DynamicMBean {
	public void setManagedMBean(ManagedMBean mbean);
	public void setManagedResource(Object obj);
}

  

? ?We don't have to hold the MBeanInfo object directly but its counterpart ManagedMBean object.

?

???After we know how to parse the configurable file into mbean metadata and how to use them to form the MBeanInfo, let's get to implement the IModelMBean interface, as I said before implementing the IModelMBean is actually implementing the dynamic MBean since it is a dynamic MBean, and from the Dynamic MBean entry, you already know how to implement a dynamic MBean by using java reflection,?but there are some differences, first of all, the MBeanInfo is created from IMBeanParser, and when you implement the methods of DynamicMBean like setAttribute(Attribute attribute), invoke(String actionName, Object[] params, String[] signature), actually you are invoking the managed resource's methods, which is passing from the IModelMBean#setManagedResource(Object obj).

???

    public class ModelMBeanImpl implements IModelMBean {

                private ManagedMBean managedMBean;

	private Object managedResource;

                public void setManagedMBean(ManagedMBean mbean) {
		this.managedMBean = mbean;
	}

	public void setManagedResource(Object obj) {
		this.managedResource = obj;
	}
               
                public MBeanInfo getMBeanInfo() {
		return managedMBean.getMBeanInfo();
	}
                ......
}
  

?

??? And the left implementations of other methods in DynamicMBean is similar as we showed in DynamicMBean blog entry, you can check them over there.

?

How to write your own Model MBean