geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 11:43:48 GMT

On Tuesday, August 12, 2003, at 10:00  am, Alex Blewitt wrote:

> On Tuesday, Aug 12, 2003, at 07:07 Europe/London, 
> 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.

I think you're missing the point I'm making - more below...

> 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.

Having the Geronimo container depend on JMX is not the issue. Its what 
should component developers depend on. I'm saying - have no 
dependencies (not even JMX) just write interface based MBeans which are 
not dependent on *anything*...

>> 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.

Have you read JSR 77 and JSR 88?

>> 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.

Like I said - we don't need an abstraction API. An MBean interface has 
no dependencies on JMX.

>  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.

Why - an MBean (interface) is just a POJO with an interface. Why should 
we make component authors dependent on yet-another-abstraction-API when 
we don't need to?

>> * 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

There are already many MBeans in the CVS repository. Go take a look. 
Search for files matching *

>> * 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,

There is no heavy coupling. How the MBeans get used and whether or not 
JMX is used is purely internal to the container.

> 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.

I disagree that this is more sensible. I'm not ruling it out in the 
future - but what is sensible is today using the JMX kernel we have 
today and creating the necessary J2EE services in accordance with the 
full J2EE 1.4 spec (which includes JSR 77 & 88).

When we have a plethora of services all following all of the J2EE 
specifications for management, deployment, classloading and so forth 
then Avalon folks will have a chance to demonstrate how Avalon could 
implement the core container better than the one we've got. Until then 
- lets focus on getting the services integrated in the simplest, 
loosest coupling way forward.

>> * 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.

JMX is only used inside the container right now. Its hidden inside the 
container - so can easily be refactored later. There is no JMX in the 

> 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've already got that in CVS though its use is totally optional to 
component / service authors. Also following JSR 77 for lifecycle APIs 
is probably a good idea going forward too.

>> * 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.

Please double check you table of contents of the J2EE specification.

> 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.

No its not!

>> * 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?

Because JBoss, Tomcat, Jetty already do this and we want to reuse their 
MBeans. Also because our codebase already does this. Thirdly because 
there's a plethora of reusable MBeans out there that just drop into 
containers like JBoss.

> 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.

Point taken - though you're still missing my point - using MBeans does 
not mean we must use JMX.

>> 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.

There already is - its in CVS.

> 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.

Rather than repeating myself again I'll just conclude with - by using 
pluggable MBeans we're not tying ourself to any particular server 
framework - not even JMX. An MBean can be used inside Geronimo today as 
well as in PicoContainer or in an Avalon container with some adapter 
layer or some-other-container-not-invented-yet.

In this thread - please take off your container developer hat and put 
on your service developer hat. In this thread I was purposely not 
discussing the container at all. I was discussing what component 
authors should do. The container should be totally invisible from a 
component developers perspective, then IoC and the container does the 
rest. If you don't believe me - look at some MBeans or PicoContainer 

The only API that might be a possible container API for component 
developers could be a lifecycle interface in Geronimo - or using JSR 
77's lifecycle API which if the latter works I'd prefer then component 
developers are only dependent on J2EE APIs and so their code runs in 
any container, not just Geronimo.


View raw message