> Von: Berin Loritsch <[EMAIL PROTECTED]> > > > Consider for a moment the purpose of MBeans. They are to allow a management > console to control aspects of your software. So they were originally created > to provide an end user a way to control the guts of software. They were not > created to provide a direct programmatic interface to the underlying software. > > So if you lookup your components and access them by a direct Java interface, > then you can easily remote that component, control the inheritance structure, > and still have the benefit of what JMX was designed for. >
I think it depends on how much of your application is moved to the JMX model. If you use it as a simple add on (which was the initial intend of JMX, and it looks like you are moving towards that direction) then I would agree. But the JMX spec also contains the agent specification, and thus being said manageable aspects of software can (and in my opinion should) be much more than providing a simple management interface to application components. > MBean != interface, and we should never use them as such. By following that > mantra, dynamic MBeans becomes a viable tool with few drawbacks. Well, this is true if you talk about the instrumentation level only. But if you trust in JMX agents for application management you are moving towards the MBean == interface analogy. In my opinion JMX offers a lot more than management, stuff you need to implement anyway: Dynamic Classloading, Notifications, Monitoring, Relations and Lifecycle of components. In the end it all boils down to whether a system is JMX enabled or JMX based. Interestingly most projects I have seen moved to JMX enabled at some stage, since too much stuff was maintained in parallel. However the transition from one to the other model is something you should avoid (just take a look at tomcat 5). Jens
