Return-Path: 
 <geronimo-dev-return-800-apmail-incubator-geronimo-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org
Received: (qmail 22292 invoked by uid 500); 12 Aug 2003 14:02:09 -0000
Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:geronimo-dev-help@incubator.apache.org>
list-unsubscribe: <mailto:geronimo-dev-unsubscribe@incubator.apache.org>
list-post: <mailto:geronimo-dev@incubator.apache.org>
Reply-To: geronimo-dev@incubator.apache.org
Delivered-To: mailing list geronimo-dev@incubator.apache.org
Received: (qmail 22263 invoked from network); 12 Aug 2003 14:02:09 -0000
Received: from dsl-217-155-97-60.zen.co.uk (HELO dsl-217-155-97-61.zen.co.uk)
 (217.155.97.60)
  by daedalus.apache.org with SMTP; 12 Aug 2003 14:02:09 -0000
Received: from apple.air.bandlem.com ([10.0.1.20] helo=ioshq.com)
	by dsl-217-155-97-61.zen.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 19mZj0-0000Z0-00
	for <geronimo-dev@incubator.apache.org>; Tue, 12 Aug 2003 15:02:10 +0100
Date: Tue, 12 Aug 2003 15:02:09 +0100
Subject: Re: [services] getting service developers started - the initial
 component model
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Alex Blewitt <Alex.Blewitt@ioshq.com>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F38EF93.5070105@apache.org>
Message-Id: <90616EB4-CCCD-11D7-A6C3-0003934D3EA4@ioshq.com>
X-Mailer: Apple Mail (2.552)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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.