I am kind of new to JMX, but could somebody elaborate the advantages of using JMX over other technologies like EJB? I have read the tutorial and concepts from Sun's website, and it seems to me that the whole concept of JMX is to wrap one application or resource as MBean, register it with JMX server, and then invoke the corresponding methods from somewhere else. However, similar steps have already been taken by EJB.
Furthermore, if the whole application is on one server, which is the most common scenario, you can easily pack the resources or sub-applications as regular Java Beans, and then use them directly without worrying about the JMX server.
Probably I am just not clear what problem JMX is trying to address.
I dont know much about JMX, but I think its used for management and coordination of the system, whereas EJBs contain the business logic of the system. I presume JMX is mainly used in distributed scenarios.
Willie is spot on. JMX is used to manage and monitor an application, not use it. Through it, you would expose properties and methods that configure an app and its runtime environment. Tomcat, e.g., exposes all the settings you usually set in server.xml and the other config files through JMX, and puts a very nice web app on top of that.
Even though it's mainly used to remotely monitor an app (or a server like Tomcat), it does have applications even on a local machine. I've found that it's rather easy to make a few settings of an app accessible through JMX (by providing MBeans), and then use the bare-bones HTML-UI that comes with JMX as a GUI for those. It's certainly faster than writing an AWT/Swing/Web UI to do the same yourself, and it works locally or over the network.
There's a good three part introductory series by Sing Li on developerWorks; the second part has some code examples.