I know there is no love lost between the Apache and JBoss communities, but have a look at their kernel. It is not entirely based upon JMX, but JMX forms a very integral part of their kernel and is pretty good, all things considered.
Well, you see, I don't want to do that because of licensing issues: it's very easy to become tainted, and I definitely don't want to do that with a GPL product (and yes, I know that sucks big time, but we have to face it).
Well, you can get a good glimpse of how things are done from Juha Lindfors book. There are only so many ways you can call and use MLet services ... so there shouldn't be any tainting there (ISBN 0-672-232288-9). It might be a bit dated, but I found it to be a decent reference when I started using JMX.
In the products I've built using JMX, like I stated earlier, I use JMX to load/unload and to manage the config of the components. I think the last one we did was better in that the global configuration is held in a centralized database and the framework itself messaged the new configuration to the servers (nodes) and the JMX system was used to get the new component (via Jini calls, but JMX has no idea how it gets there) and then load it in with the IoC config and swaps out the old component, which is then GC, or can be dropped by kicking the classloader.
Have a quick look at those systems for ideas. When you swap in a component, you also have to consider how all of the other components are talking to it. Almost every system out there that attempts this uses the concept of a messaging bus between components, so that you can actually swap out a component, which becomes difficult and language dependent when using direct references.
The ability to swap in/out components and have the other components in the system use it without much in the way of hiccups is a more interesting design problem than the load/unload and config.
Definitely. I'm still wondering how you might deal with this nightmare with JMX. It's pretty clear to me that JMX relations are not enough. Care to tell us more on how you solved or plan to solve this kind of issues?
I agree there. I only use the MLet services to dynamically load and unload my services. I pass in the configs a'la IOC style as that seems the most flexible was easier for me to comprehend (and dump configurations for debugging). I'm going to be moving towards the MD5Url for getting my component services as this provides some security and version management for the archives I'm using. To manage load dependencies I've opted for service strings. I read about them in various implementations at CERN, but I think the only accessible example is the Rio project at Jini.org to see an implementation that they have tried. They have an attached QoS that is better suited for distributed services. My service string isn't so clever, in that I don't manage QoS, but I do tag in version ranges (e.g. so one component can say it is known to work with versions 1.x - 2.6 of the network alarm agent). All components lookup the service they want from the JMX server, stat current version is compatible (if not they can request an update) and then call the service via a Proxy that is built when the service is loaded. I haven't tried to totally encapsulate all of the indirect calls in a smart proxy, but I've been told that is a batter way to go by Rickard Oberg. If there was an XDoclet like tool with the correct license, I'd say we should look at that for helping with JMX work ... but for our limited requirements we could probably use a transformer of some sort in Ant to create either the classes or if we want to create totally described ones in a configuration doc, with a set of MBeans that get instantiated from an XML descriptor file. We lose some of the compile time checking, but I've found it easier to keep the required JMX info in my interfaces so that the sources are close together.
Does anyone here know how they are using MX4J in the Geronimo container?
Cheers, Thor HW
