> If I use Standard MBeans, the MBean itself holds onto the data I want to manage. There is no way to wrap a
> resource with the standard MBeans.

You could still write a Standard MBean that delegates all its calls to the actual resource, therefore acting as sort of a "wrapper" to the actual resource.

> Using the Standard MBean would require my app to have knowledge of this
> MBean and make calls to it via the MBean server to update the data in the MBean.

True in case the Standard MBean itself encapsulates the resource's state.


> If I use a ModelMBean I can wrap an application object and use the ModelMBean to grab the data from
> the wrapped object only when I want it or to reset it.

True. Model MBean automatically provides you with a "template" to the actual resource you are managing. It also provides additional features such as the "caching" of management attributes you describe. To implement these features with Standard MBeans you'd have to manually code them.

> My app now no longer needs to send messages to the MBean since the app can add data to the wrapped
> object directly.

True.

> This makes more sense since most of the JMX related messages are coming into the app as
> opposed to from the app to the MBean server. Also, the wrapped object needs no knowledge of the MBean
> wrapper.

Again correct.


> I used both and the ModelMBean, while more work to
> get working, has more benefits.

If you make use of the JBossMX Model MBean implementation, we can significantly reduce the amount of work involved with creating Model MBean instances. Currently we provide two default ways to build the management interface for an Model MBean: you can read in an XML file that defines the management interface and creates the appropriate metadata (you can further reduce the amount of XML generation by using XDoclet tags to generate this file), or you can choose to use a reflection based Model MBean builder that allows you to define a Java interface for your resource (following the Standard MBean naming conventions) that is used to generate the management interface for the Model MBean.

Furthermore, this mechanism is meant to be extensible, so you can add your own rules how you'd want to generate the MBeanInfo. For instance you could add your own naming convention rules for the Model MBeans if you do not want to use the Standard MBean conventions, or need to extend them (to add support for additional descriptors for instance).

> Also, how much is the overhead from using a standard
> MBean and is that reason enough to avoid them?

The overhead is only significant in cases where the MBeans are part of the performance critical invocation paths of your applications. An example is an EJB container that is invoked through the MBean server (potentially having to deal with a large number of invocations per second).

The real reason to avoid Standard MBeans is their lack of extensibility though. In most cases they're quite limited, and you end up building your own hacks around these limitations.

-- Juha