You can do reflection calls in many many styles. It is sometimes nice to pick up and use one that is already well understood, and because of dynamic proxies can have extra behaviours added in. You can't actually use JMX as a back plane for communication between components. But you can follow the same style it uses throughout (consistency is sometimes a nice thing when there is no reason to alter it).
I'm not sure that there is an "other-side of the fence" where you don't need to make things work in real life if you are actually a long-term living in this industry. I'm going to assume that my JMX projects, others that are successful and the JBoss kernel argue the opposite of your "other side of the fence" comment.
These projects all focus on using standard interface, that any compatible, swappable component must implement. They use reflection style calls to keep weak references between components so that the internal JVMs wont cache a method binding between components. There is a small first time lag when the JVM has to get the lookup loaded for the reflection calls, but there are ways of speeding that up (by using something like BCEL) and after that the speed difference should be negligible.
Cheers, Thor HW
On 26-Mar-04, at 7:13 AM, Gianugo Rabellino wrote:
Pier Fumagalli wrote:
On 25 Mar 2004, at 19:40, Thor Heinrichs-Wolpert wrote:Hmmm ... I've never used JMX for remote loading as the security just isn't there for my tastes and there other mechanisms that work so much better. It does do a fine job of loading/unloading components though.Gianugo and I spent an hour on the phone (he paid the international rate :-) talking exactly about it...
He has a lot more practical experience on JMX than I have, and I believe that we got down to a pretty good rationale on how it can all work...
Who, me? Actually I have very little real life JMX experience, but indeed I've been for quite some time on the other side of the fence, where you have to really make things work (which is your situation as well, I reckon). Since I come from a network background, I consider myself an SNMP diehard, and I think there is a very good analogy here.
SNMP has three basic functionalities:
1. gather informations about a device (read an SNMP value); 2. configure a device (write an SNMP value); 3. handle anomalies and alarms (SNMP traps).
Of such functionalities, #2 is really never used in real life, and this is because of separation of concerns: SNMP is an _invaluable_ tool for people who need to keep things running, but such people aren't the ones configuring such things. Skills of monitoring are horizontal, while configuration skills are much more vertical. This is basically why the Cisco guy and the Apache guy operate on a CLI much better than on an OpenView console.
I think that the same applies to JMX, which really should be nothing more than an object oriented and Java aware SNMP (oh yes, it can do more than that, but it looks like forcing the paradigm to me).
Now, there _might_ be some goodies that are best managed via JMX, but overall I think that generic configuration tools are not the way you want to go since they'll give you a tool to, say, set an integer value but they won't tell you *why* and *how* you should do that, which makes it even more dangerous. A configuration system should be as complex as the needs it's solving: it should be usable and comfortable, but not necessarily "easy" per se.
So, bottom line, I'd say that JMX should be used for health monitoring and alarms. Activation/deactivation of components might be another issue that fits in JMX, but not much than that.
This said, the real issue is where to put JMX. There are three candidates:
1. The container itself
2. The block itself, as a whole;
3. The components inside a block.
I have very little doubt that the container should expose a JMX interface. I would like to see even blocks to expose some kind of JMX behaviour for resource management (something like a generic health status monitor, the number of times this block has been called, and the like). As per components, I used to think that it would have been great to design them as Mbeans, but Pier convinced me that there are a number of cases where this doesn't make sense and might just bring overcomplications.
Pier, did I summarize well what we've been up to?
Ciao,
-- 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/)
