On Tuesday, August 12, 2003, at 12:51 pm, James deGraft-Johnson wrote:
I agree with this.
By structuring the kernel architecture like JMX/MBeans we will simplify the
design task, have less changes (refactoring) to make to existing kernel,
which is based on JMX/MBeans. However it is important not to tie the design
tightly to JMX/MBeans, (or implement the kernel strictly as JMX/MBeans) as
pointed out). Note that JMX/MBeans is meant to be a feature (management
extension) of the J2EE container not an architecture for design of the J2EE
kernel. By not tightly coupling kernel architecture to JMX/MBeans we can
incorporate design ideas from outside JMX/MBeans and also allow the
component to be changed later.
Agreed.
we have
components <-> container <-> JMX
The container in the middle could be based on JMX or could be based on some other model and just adapt to JMX. But thats the containers job to figure that out.
For all the services & component developers we should adopt the standard MBean programming model as the first convention for developers. In the future we may have other options for component authors to follow (e.g. Pico components or Avalon components etc). However for now following the MBean convention is a no brainer since its already being used & supported.
If developers of a service wish to use some new wizzy abstraction API or to write Pico components or to use some Avalon container or whatever - then we can just deploy the container inside Geronimo via MBeans. So we could have..
avalon component -> avalon container -> avalon MBean -> geronimo -> JMX
James ------- http://radio.weblogs.com/0112098/
