geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 14:02:09 GMT
Agree totally with these points. And now, I'll shut up :-)

Alex.

On Tuesday, Aug 12, 2003, at 14:45 Europe/London, Berin Loritsch wrote:

> jastrachan@mac.com wrote:
>
> <snip type="work with what we have"/>
>
>> Thoughts?
>
> Yep.
>
> I don't want to argue till I'm blue in the face, nor do I want to 
> create
> negative energy.  However, Alex does have some good points.  JMX is a 
> good
> tool, and we don't want to loose its value.  I believe in doing the 
> easiest
> thing first.  So, should we start with what we have?  Yes, but....
>
> I outlined some minimal component requirements that would allow us to 
> play
> with other container projects just as easily as the all JMX thing we 
> have
> in CVS now.  If we follow those minimal requirements, then we can 
> revisit
> the container question at a later time and not force one framework over
> another.
>
> Those requirements are:
>
> 1) Separation of interface and implementation.  We are talking a simple
>    Java interface.  All code that uses a service/component uses it 
> according
>    to that interface.
>
> 2) Inversion of Control.  This comes in many forms, but the bottom 
> line is
>    that we never rely on static accessors to gain information for a 
> service/
>    component.  Everything the component needs is passed in by the 
> server.
>    The actual implementation of this is really irrelevant as long as 
> we work
>    with this goal.  Most open source containers can be adapted to work 
> with
>    the way you do things.
>
> 3) Separation of Concerns.  Each service/component should do one 
> thing, and
>    do it well.  Even if a service represents another complete set of 
> components
>    to do its job, it is there for one purpose.  An EJB Container can be
>    considered a service, as well as the persistence manager used 
> inside of it.
>
> If we can follow these simple requirements, then we can swap 
> containers to our
> heart's content and still work with the same system.
>
> The JMX MBeans would take care of setting up and managing the 
> components (as
> it probably already does), but instead of the service directly being 
> an MBean,
> it should be managed by an MBean.  That would allow us to have a small 
> number
> of MBeans to provide a consistent interface for all components, and 
> have generic
> services that can be used in other systems.
>
> No commitment to Avalon, PicoContainer, JMX, etc.  Just some simple 
> services.

I agree. I've never been directly pushing Avalon over JMX, but rather a 
more micro-kernel based architecture than JMX allows. There may be a 
new container framework just around the corner ...

> Since we are talking about a J2EE server, all components would be 
> bound to
> JNDI, although we might have a J2EE server namespace to look them 
> up--that
> way they are not confused with EAR based components.

In order for this to work, naming conventions (the JNDI contexts, 
subcontexts etc. -- not Java coding ones) needs to be ironed out in 
more detail. Sounds like a Wiki page in the making ...

> Does that sound like a workable compromise?

Absolutely.


Mime
View raw message