Maxine 1.1 Released: A JMX Microkernel


News: Maxine 1.1 Released: A JMX Microkernel

  1. Maxine is a simplistic JMX microkernel. It provides a simple configuration model which tells how to register MBeans. The configuration model can be modified and saved at runtime. Maxine can import the attributes of MBeans from the MBean server into the configuration in runtime, too. Maxine also provides MD5 checksum validation and archiving of downloaded codebases (JAR) for reliable code distribution.

    Full feature list:

    * Customizable configuration persistence (local file by default)
    * Simple configuration file format
    * Importing MBean attributes from MBeanServer into the configuration file in runtime.
        * You can change your MBean's setting in JMX client, and save it back to the configuration file!
    * Supports both URL and local codebase:
        * Archives downloaded codebases to file system to cope with download failure
        * MD5 checksum validation for remote codebases

    Check Maxine out at:
  2. What is the difference to the JBoss JMX kernel? At first glance it looks like Maxine is a reduced version of the JBoss kernel.

    NOTE: I am not a JBoss employee nor ever will be
  3. You're right, I can say that Maxine is reduced verion of JBoss JMX microkernel. To compare with JBoss kernel, Maxine:

    * is very small
    * provides reliable codebase downloading and archiving.

    I'm not sure JBoss kernel provides these feature:
    * works with any standard JMX implementations
    * uses Jakarta Apache Commons Logging
    * can import writable MBean attributes (including Standard MBeans) into the configuration file
  4. It is nice to see that someone is taking up the idea from JBoss and tries to build a proper implementation. IMHO JBoss has gone the wrong way by including a life cycle management and forcing everyone to use their interfaces. This way you cannot stick to the JMX standard and are forced to use JBoss micro kernel. Well, Mr. Fleury will say: "Hey, it's free so what's your problem?".
    Also the way that have "abused" the MBeans is not nice. These MBeans should only include the implementation about the management aspects of a component rather then the entire implementation. The JBoss guys have mixed up both the components and the management aspects. That's why they needed the life cycle management. IMHO this is wrong.
    Actually I have taken this approach and implemented a service provider that use both. First the service itself and the MBeans that manage these services and "glueing" them together with xml configuration files.

    Ok, I am loosing the track....

    As for the support of commons-logging: I would not consider this as a nice feature. Since the developers of commons-logging have somehow apologized for this little project (actually for the abuse of this tiny tool) I would suggest that you get rid of it as soon as possible.

    My 2 cents
  5. Agree, this is the reason I brought up the OSGi point which is specialized in component lifecycle management in a very lightweight way.
  6. My opinion is slight different. Nowadays' applications require 'management'. The applications without management feature cannot appeal users, so there is a management interface where the application goes; The application and management interface overlaps exactly. That's why JMX can be very attrative microkernel.

    Module lifecycle management almost always involves implementation of some lifecycle-related intefaces to track the module's current status in close. But we build a complex system with various components; we can't assure that all 3rd party modules implement those interfaces, and there is also possibility that they provide different lifecycle. So unified lifecycle management looks dangerous to me. IMHO, start() and stop() method invocation is the only thing we can do. Yes, I love POJOs. :)

    I did't look at OSGi yet, so my talk was not specific to OSGi; I just told with my career experiences.
  7. I agree that start and stop should be supported. But I would not define an interface for this but rather give the user the opportunity to define such a start and stop method in the configuration. So the MBeans are still 100% compliant and can run in any JMX enabled server.
    IMHO an ideal JMX enabled microkernel should consist of two parts for every service. The first part is the service itself which should be a regular java class
    with the logic. The other part would be the MBean that will manage this service.
    This way you can still use your services in any other way and you are not bound to
    JMX. Such a microkernel would take the MBeans and these MBean configured with parameters from a configuration file will then instantiate the services and so on.
    You have a nice separation of business logic (service logic so to say) and the
    management logic.
  8. I totally agree with you. Forcing user applications to implement the specific interfaces is a bad idea.

    The separation... you're right, too. IMHO, however, the separation of business logic and management logic is sometimes very ambiguous. It seems to overlap. Is there any example to show how to do it clearly?
  9. Here is an example (taken from one of my projects):

    I have a connection pool which is implemented as a "normal" java class. This is the service itself. In my latest project I have used the famous old poolman.
    Also I have one MBean that manages this connection pool. For example the MBean
    has an attribute that defines which implementation as connection pool should be
    Here I have the separation. I think it is a quite good example since I am using
    an existing tool (poolman).
    Difficult to explain in a few short words.
    Take another example from JBoss. There is the minerva connection pool (at least in JBoss2.x). The connection pool itself and the management logic is inside one MBean. Now you cannot use the connection pool outside this evironment. So I would
    suggest that you separate both parts of the code. Put the connection pool into
    a simple and the rest into an MBean.

    I can share some source code if you are intersted. Contact me if you want.
  10. Ah, now I got it. You mean bridging the pre-existing non-JMX-compliant components, right? It is absolutely true when you program Dynamic or Model MBeans, but when you program Standard MBeans, supporting JMX compliance is very very easy, and it does not bring any compatibility issues with POJOs.

    Thanks for your insightful comments.
  11. Work together?[ Go to top ]

    You're right, I can say that Maxine is reduced verion of JBoss JMX microkernel. To compare with JBoss kernel, Maxine:* is very small* provides reliable codebase downloading and archiving.I'm not sure JBoss kernel provides these feature:* works with any standard JMX implementations* uses Jakarta Apache Commons Logging* can import writable MBean attributes (including Standard MBeans) into the configuration file
    Maybe we should work together? You seem to have some good ideas, and I'm sure our microkernel could be extended to support the features you describe above. We already have a very large userbase and a bunch of tools and services that enhance our microkernel. We're currently putting a plan together to revamp our kernel in the JBoss 4.2 series. Your input an expertise would be greatly welcomed.

    Please contact me: bill at jboss dot org

  12. I am wondering if JMX is used for other purposes that it was intended originally.
    As a result, many JMX implementations differ from one another in the non-functional area.

    I think that OSGi offers a very good basis to build these type of environments (could be JMX, J2EE...) in a very controlled and specified way ( without having any licensing fee. There are many OSGi implementations out there, the one which stands out is OSCAR.
    Eclipse is the first open source platform I know of which makes use of OSGi to dynamically load plugins.

    JBoss or the Apache J2EE project could move toward an OSGi micro kernel and remove the JMX based one (Jboss) which will enable them to standardize the lifecycle and dependency management of bundles (EJB, Servlet, JMX....). OSGi also allow you to have multiple versions of API running in the kernel, allowing smooth migration toward JSR specs as they are ready.

    This is just a suggestion, I think that it is worth looking at these options.