Why using JMX instead of an EJB ?

[fmarchioni]

Hi all,
I have read some chapters about JMX, I'd like
to ask what is the clean advantage of using
JMX against using an EJB or bare Java classes
invoked via reflection?
JMX looks nice as it's a pluggable architecture
but I can also do the same with EJB when I hot
deploy them.....moreover in the 2.1 release of
EJB there should be included timer services too
as in JMX......
Please give me some feedback....
regards
Francesco

[juha]

> I have read some chapters about JMX, I'd like
> to ask what is the clean advantage of using
> JMX against using an EJB

See the JBoss server for example. There MBeans are used as system level components that build the server (including the EJB container). This automatically enables server components for management (through HTTP), and decouples the components from clients (via MBean server). It's not an either/or question between MBeans and EJB, they're complementary (where EJB's come with 'heavier' contract more geared for application development, including pools, caches, concurrency control etc.).

> or bare Java classes invoked via reflection?

There's no component contract here at all. You're tightly coupling your clients to the objects through reflection assuming the Java reference you have does not go away or the interfaces don't evolve. References break when you need to recycle the object, there's no indirection (like you have with JMX object names) to isolate your client's from such change.

> JMX looks nice as it's a pluggable architecture
> but I can also do the same with EJB when I hot
> deploy them...

No, you're missing the point. You can do it this at your application level as we provide the JMX base as part of JBoss (the EJB container you're hot deploying is an MBean). But it would not be possible to build the server as EJB's.


> ..moreover in the 2.1 release of
> EJB there should be included timer services too
> as in JMX.

So all we need to do is interface that to the existing Timer service of JMX.

-- Juha