HI, I am joining this effort with the hope of being a code contributor.
I think this (MBean component model) is a good idea. It would be helpful if a sketch or example MBean can be created, so those of us who are new to open source development and MBean development can understand exactly what this component model entails. (This example does not have to be throw-away as it could be a live component.) There are two other suggestions I would like to make. One is that a decision on the base (kernel/framework) code be made and moved to CVS assuming it hasn't already. Also, whatever this MBean component model involves, it essential that we move ahead to porting the existing containers/services to this model to identify any risks in the approach we are taking. James deGraft-Johnson 3419 Hampton Hollow Drive, Apt G, Silver Spring MD 20904. Tel: (301) 847-1694 Fax: (301) 847-8025 Mobile: (240) 475-1444 ([EMAIL PROTECTED]) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 2:07 AM To: [EMAIL PROTECTED] Subject: [services] getting service developers started - the initial component model 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. Up to now the Geronimo codebase has assumed a JMX micro kernel, following in the footsteps of JBoss, Tomcat 5 and Jetty. I'm sure this can be improved with time though this strategy has been proved to work. Before we get bogged down in months of upfront design for what the perfect container should be - I'd like us to be able to make good progress integrating the various services - of which there are many. Then we have some real use cases that can help us as we refactor the Geronimo container. What I'd like to do as an initial step is choose a default component model for service developers to follow as they write Geronimo services. For some time most of the main services in Geronimo are going to be fairly course grained (web container, Axis, JMS provider, JTA etc). In addition at the time of writing Geronimo can deploy MBeans. 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. 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). So in summary * lets start writing J2EE services as MBeans that we can plug into Geronimo today. * 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 * 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. * 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. * 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. * 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 Thoughts? James ------- http://radio.weblogs.com/0112098/
