On Tuesday, Aug 12, 2003, at 07:07 Europe/London, [EMAIL PROTECTED] wrote:
I'm sure we could all debate the perfect container framework and compare and contrast the intricacies of the various flavours of Avalon containers, PicoContainer, JMX & Java Beans until the cows come home. However what is really important right now is we start writing lightweight, pluggable services ASAP to start filling in the J2EE stack for Geronimo.
Definitely concur with this one.
So initially I think the component model should be JMX MBeans. These are simple, lightweight components that have no compile time dependencies on anything. The MBeans themselves should follow the Inversion of Control pattern - i.e. the container instantiates & configures the MBean. In addition we should try follow the MBean interface pattern such that we can do efficient interception easily with dynamic proxies - also note that MBeans do not need to use JMX at all - any container mechanism can be used to configure & wire together the components.
The only problem with this approach is that there isn't a suitable abstraction layer in the Geronimo kernel to allow for easy refactoring at a later stage. It would be much better, for example, to create an interface called 'Service' (for example) that implements MBean initially, but ensure that any code written for Geronimo doesn't depend on MBean. That way, refactoring at a later stage will be much easier.
Already today Geronimo can handle MBeans. It must always be able to handle MBeans. Indeed whatever Geronimo's container framework becomes it should be easily cable of working with the plethora of J2EE MBeans that are out there. (MBeans are essential to J2EE).
I've not found the section in the spec that says this. What I've found is:
J2EE.2.6.15 Management: The JMX API is also used to provide /some/ management support -- not that it must be implemented using MBeans.
J2EE 6.17 JMX requirements: The only JMX support is specified in hte J2EE Management specification. In particular, applications will not typically have the security permissions required to access or create MBean servers
And the JavaManagement pages say that it's used for management.
So I challenge the statement that MBeans are essential to J2EE -- I don't believe that they are according to the spec.
What the spec does say is that the JMX API is available, and that optionally, components may be managed through the JMX API. It doesn't say anything about them being implemented or managed as MBeans in a server.
There also isn't any requirement for a J2EE server to be able to run MBeans out of the box. JMX was designed as a management interface to allow remote systems to be managed, in much the same way that SNMP was designed for.
So in summary
* lets start writing J2EE services as MBeans that we can plug into Geronimo today.
I think the more services that are created sooner, the better. However, I would strongly suggest that we create an abstraction API that we can use in Geronimo to make the services available, that decouples the implementation of the services from JMX sooner rather than later. Otherwise, if we write and build heavily on the assumption that everything-is-an-MBean then it will be a lot more difficult to change/remove that assumption later on. A few abstract APIs would solve this problem immediately.
* in parallel to this activity folks can help improve & innovate inside the Geronimo kernel - without adversely affecting the progress of the component authors - we can all work in parallel
Absolutely. In fact, it would be great if there was an 'experimental' spike doing this now, either by having a set of packages in the Geronimo core, or a different module, or a different CVS tag to allow this to occur in parallel now. However, since most of us don't have commit privileges, (and thus can't control the experimental/head checkins) it might be more advisable to have an experimental package/module, which would then fit in with head
* those Avalon fans could package up one or more Avalon containers as MBeans then any Avalon components could be easily deployed inside an actual Avalon container inside Geronimo. Ditto for PicoContainer too. i.e. this strategy allows for a diversity of containers to be > deployed.
This still doesn't address the heavy coupling of the entire framework to MBeans/JMX, which is essentially the point I'm making. It would be more sensible, for example, to build an Avalon framework kernel that could allow legacy MBeans to be instantiated.
* once all the required deployment options are available (EAR, WAR, SAR) and the ClassLoader stuff is working along with the interceptor stack; folks can then refactor the container using some real J2EE services to improve the manageability & codebase - based on real refactoring of working code rather than too much up front design. Indeed we can take a TDD approach to refactoring the container. So rather than guessing what a J2EE container should look now, we can refactor as we get there to improve it.
And one of the goals about refactoring is to set up easier migration paths. Importantly, refactoring can be done at any time, and abstracting/decoupling the implementation from JMX (wherever possible, not necessarily as a major rewrite) will aid in that. So I'd suggest creating abstract interfaces (Service, Container etc.) that developers can write to, and not MBeans. (However, the Service can initially implement an MBean to facilitate migration.)
* we should make great progress, getting J2EE coverage fairly soon - yet we won't really be tied to JMX at all - the MBeans could be used in any container implementation.
Again, the J2EE spec in no way requires MBeans to be used as the container implementation. Indeed, the spec is specifically implementation agnostic on this and almost all other points regarding implementation of containers. I'd find it quite unlikely that an implementation of something built for one server (e.g. WebLogic/WebSphere) would stand a chance of running in another (e.g. JBoss, Geronimo).
Building everything now implementing MBean is a sure way to be tied to JMX. Building an abstract API for Geronimo is a sure way to allow things to be changed later.
* if in the future we come up with some other component model to be supported, it should be trivially easy to plugin MBeans anyway, or a simple refactor to support them
Why do we need to support plugging in of MBeans? The JMX introduces it self as:
"The Java Management Extensions (JMX) technology represents a universal, open technology for management, and monitoring that can be deployed wherever management and monitoring are needed. By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions and plugging into those of the future."
It's about management. It's about being able to talk to a service and manage/configure it remotely. It never said that everything needs to be built with JMX -- the 'deployed wherever management and monitoring are needed' is the /management/ that's deployed, not the implementation of the service.
I challenge the notion that MBeans are even a necessary part of this implementation. It should be an externalised API, using the Facade/Bridge patterns, not everything-must-be-an-mbean.
Thoughts?
I agree with your main point of this message; that there is an initial code base, and that 'purist' views may not be helpful for moving the project forward quickly.
I also agree that the sooner there is a framework to allow new code to be written, the better.
I disagree that everything-must-be-an-MBean, and I also disagree that the J2EE spec has anything to say on implementational aspects using MBeans.
I disagree that a J2EE server must be an MBean container.
I believe that an approach where everything-is-an-MBean introduces unnecessary high coupling between the application server and the components within. I also assert that if many services are developed that directly are MBeans, then it will be much more difficult (to the extent that it becomes impossible) to refactor out these dependencies later on.
In short, I believe that to keep our options open for longer, and to support migration away from a JMX kernel later on, we should introduce abstract types/interfaces/classes to represent the generic components within Geronimo. Then services should be written entirely in terms of this abstract API and not depend on JMX at all.
This will allow initial code to be developed and the project moved forward, and alternative approaches for managing the Service or Container APIs can be developed in parallel, rather than a big refactoring initially that holds up the development of new services.
Alex.
