JMX, SNMP, Java, etc...

In a recent blog, Kohsuke Kawaguchi proposed a means to turn any MBean into a Weak MBean. His suggestion is both interesting and clever. But what is actually a Weak MBean?

Weak MBeans is a concept that was introduced by Eamonn McManus in his blog Cleaning up an MBean when its resource dies. Basically, a Weak MBean is an MBean that only holds a WeakReference to its underlying resource, and which gets deregistered - or rather, deregisters itself, when the resource is garbage collected.
The great advantage is that exposing a resource as an MBean in this way doesn't create any additional strong reference to that resource, and doesn't prevent it from being garbage collected when it is no longer used. When the resource is garbage collected, its associated MBean also automagically disappears from the MBeanServer.

No matter how appealing this feature appears, I can't help feeling uneasy with this Weak MBean concept. Thus the question I ask myself is this:

Could it be that Weak MBeans are simply symptoms of a Wicked Model?

Having worked for a telco manufacturer (Alcatel), for a TMN company (Netmansys), and in the Java DMK / JMX team (Sun), has provided me with many exposures to management interfaces and information models. GDMO/CMIP, CIM/WBEM, SNMP, CORBA, Jini, JMX, to name a few, are technologies/protocols that I have either worked with, or investigated, or even in some case implemented, in the course of my job.
Although I won't pretend to be an expert in all of these - and far from it - I am not completely naive either when it comes down to talking about management information models.
Somehow, this experience gives me the gut feeling that if you resort to using Weak MBeans in the design of your Management Interface, it's possibly because you're working at the wrong level of abstraction.

Let me take an example. In a previous entry, I have talked about the ThreadMXBean exposed by the Monitoring and Management API of Java SE 5.0 (Tiger).

In a naive sort of way, Weak MBeans would have been a perfect match for modeling thread MBeans. However, for all the reasons explained here, it would most certainly have turned out to be a big mistake.

Don't get me wrong.
I don't deny that Weak MBeans are an extremely interesting and appealing concept.
I don't deny that there might be cases where using Weak MBeans might actually be the right choice to make.
What I am simply saying is that it is better to be wary of them, especially if they seem to match your own object model in a kind of natural 1 to 1 mapping. Force-feeding application objects into the application's management interface is not always the best choice.

Before making that kind of decision - I believe it worth to look at the implications and alternatives. In that respect, the ThreadMXBean example makes good food for thoughts.

So now, how would I go about determining whether Weak MBeans are the right choice for managing my application?
I can offer some clues.
The first step is probably to realize that the view of the management interface - as conjured by the MBean developer, and the view of the management interface, as expected by a managing application, may not be driven by the same kind of requirements.

Indeed, being an MBean developer myself, I usually design my MBeans with an eye at seeing, and an eye at testing. What matters to me is being able to see my MBeans with jconsole, and being able to interact dynamically with them - note: if you're not familiar with jconsole, Mandy's article on jconsole is worth reading.
If I can see my MBean in jconsole MBean Tab, if I can click on it and display its attributes, tweak it if it is tweakable, register for its notifications and display them, and if in addition, I do see my MBeans appear and disappear from the MBean tree as if per magic - which makes great stuff for demos - I am more than happy.

However, the developer's jconsole use-case may not be the only use case relevant for the situation, and these are a list of questions that may be worth asking:

• What is the canonical management software that will manage my application through its JMX interface? Is there any that I know of?
• How is this managing application - real or hypothetical - going to use my MBeans?
• What will be the use cases that such a managing application will have? Have I identified the most relevant?
• Are there data consistency aspects (need for correlated attributes / correlated MBeans) that I need to take into account?
• If I model my resources with Weak MBeans, is it going to simplify the task of the management application with respect to these use cases, or is it going to make it more complex, or will it make no difference?
• Are there alternatives by which the task of the management application could have been made simpler?
• Is there a significant impact, one way or the other, on performance and footprint with respect to the various alternatives?

If - after having asked all these questions, I am still convinced that using Weak MBeans is the best alternative, then go ahead! I will use them.
Otherwise, I will most certainly reconsider my design choices, least my Weak MBeans eventually turn into... Wicked MBeans...

Cheers to all!
Tags:
Posted by dfuchs ( Jan 19 2006, 03:21:58 PM CET ) Permalink Comments [1]