geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 13:45:55 GMT
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.

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.

Does that sound like a workable compromise?

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message