I'll have to say yes I do know about sys admin work (if we're going to count years, mine is 22 years now). Matter of fact one of the JMX products I mentioned is a IT management tool (monitoring SNMP, services, even SSH accessible shell scripts and the internals of our Oracle, MySQL and other databases, Cisco routers, Linux routers, and even slot machines *g*).
Well, of course I have no interest in a "my experience is longer than yours" discussion. :-) I'm not saying that JMX can't be part of an IT management environment, it's quite the opposite actually. What I'm contesting is that every configuration and basic application behaviour should be managed via JMX since this would mean forcing your application to adhere to the JMX model which is, AFAIU, somehow limited architecturally: it seems to me that it's easy to do simple task (set and get properties, send notifications) but it becomes horribly (and uselessly) complicated when it comes to complex stuff. There are things that are better done with plain old configuration systems, which can express much more: starting to use model/open MBeans seems to me ankward as hell and, most of all, unmanageable (go figure!) from the application development point of view: my impression is that there is a high chance of inserting bugs when using JMX the way it wasn't conceived for.
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).
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?
Thor HW (who is really enjoying these discussions!!!)
Oh, same here, that's for sure. :-)
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
