You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jonathan Hawkes <jh...@adsnm.com> on 2003/11/20 16:38:53 UTC
[proposal] Avalon Container Framework
This is a follow up to the threads:
[RT] IoC Type Who Cares?
[proposal] IoC type 3.14 extension to the Avalon Framework
If you are coming into this discussion late in the game, you may want to review the above threads for more detail.
The Avalon Framework is a component framework that defines a conversation that can take place between a component and its container. Its definition of a container is currently very loose, which is ideal. However, there are advantages to defining an optional container framework. Take PicoContainer for example; Pico's "type 3" components may operate (conceptually) in many different containers, and PicoContainer can be extended/implemented/mix-n-matched to come up with a wide variety of containers that can run type-1, type-2, or type-3 components. It is very flexible, and the Pico folks have come up with a lot of great ideas. However, the framework (Pico's), in my opinion, has some short-comings. In addition, many developers will want to work with a "pure Avalon" solution or a framework that is more tightly bound to the Avalon way of doing things. It it my proposal that we give them one.
public interface RoleResolvableServiceManager
extends ServiceManager {
/* BEGIN from ServiceManager **
boolean hasService(String role);
Object lookup(String role)
throws ServiceException;
void release(Object service);
** END from ServiceManager */
String resolveRole(Class serviceInterface)
throws ServiceResolutionException;
}
public interface ServiceConstructor {
String getServiceRole();
Class getServiceInterface();
Object newService(RoleResolvableServiceManager serviceManager,
Context context)
throws ServiceResolutionException,
ServiceInstantiationException;
void verify(RoleResolvableServiceManager serviceManager)
throws ServiceResolutionException;
}
public interface ServiceContainer
extends ServiceManager, Disposable {
String ROLE = ServiceContainer.class.getName();
ServiceConstructor getConstructor(String role);
void registerService(ServiceConstructor sc)
throws ServiceRegistrationException;
void unregisterService(String role);
/* BEGIN from ServiceManager **
boolean hasService(String role);
Object lookup(String role)
throws ServiceException;
void release(Object service);
** END from ServiceManager */
Collection getServices();
Set getServiceRoles();
// Uncertain about this method...
// The List can be modifiable/unmodifiable
List getChildContainers();
void verify()
throws ServiceResolutionException;
// from Disposable
void dispose();
}
Now, I AM NOT advocating the above framework carte-blanche. It is a brainstorm. What I AM advocating is simply the existence of a container framework. But since I am brainstorming, I will attempt to give a walk-through.
The two crucial pieces of this puzzle are ServiceConstructor and ServiceContainer. These are intended to be as loosely coupled as possible. My goal was that ServiceConstructor(s) could be plugged in to ServiceContainer implementations, regardless of the vendor.
A ServiceContainer is an abstraction that defines the ability to register a service, to lookup a service (it extends ServiceManager), to list all available services within the container, and to verify all dependencies within the container. I borrowed heavily from PicoContainer, but I believe that my design is more straightforward and more easily implemented. And while I do like the idea of PicoContainer.getComponentMulticaster*, I don't think it belongs within the container interface itself. A better idea (IMHO), would be something like:
multicasterFactory.createServiceMulticaster(container);
As you may notice in ServiceContainer, I have stuck with the notion of Avalon roles. This complicates things slightly when using IoC type 3. These roles need to be able to be mapped with their service interfaces. This is the reason for the RoleResolvableServiceManager and resolveRole. A straightforward RoleResolvableServiceManager.resolveRole implementation would be simply to attempt to find the static field "ROLE" or to use the fully qualified interface name and then invoke ServiceManager.hasService.
A ServiceConstructor is where the IoC type implementation is buried. It may support type-1, type-3, type-3, or type-X components. A ServiceConstructor exposes the role that a service is to fulfill. It also exposes the interface a service is to implement, but it does not expose the implementation class itself. I feel that this is more flexible. It provides a verify() method which can be used to check if the given ServiceManager can resolve all of its dependencies. It also, quite naturally, provides a newService() method which can be used by the ServiceContainer to instantiate a registered service. The arguments provided to newService(RoleResolvableServiceManager,Context) allow the constructor to resolve all services (using ServiceManager) and/or container-dependent instruments (using Context).
The entire framework was designed primarily with ease-of-implementation in mind. A straightforward ServiceContainer implementation would extend RoleResolvableServiceManager and pass along itself into the ServiceConstructor methods. A more security conscious implementation might differ.
Any questions, comments, criticisms?
Thanks!
Jonathan Hawkes
Re: Avalon Container Framework
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Jonathan Hawkes wrote:
<snip/>
> <snip type="implementation stuff"/>
>
>> What I AM advocating is simply the existence of a container
>> framework.
lets call it 'containerkit'! <ducks/>
Seriously, lets not call it "container framework". Let us just build an
extensible container, and hope its pieces are reused :D
> There are some pieces that are missing from your overview.
disagree! Jonathan is right on the mark with not specifying the missing
pieces right away. Start small; incremental design :D
> [Specification/Implementation of dependency resolution policy]
Actually, I believe there's only a few people who feel like customizing
dependency resolution. Looking at all the existing implementations of
IoC, none is really built for customizing the dependency resolution
policy. Sure, its *possible*, but it is quite an uncommon usecase.
Furthermore, this is a usecase that will automatically be addressed by a
good decomposition (as long as we consistently seperate api from policy,
or consistently allow pluggable implementations).
> [Metadata access]
Important question: what metadata are you talking about? I believe you
are talking about the information the factory/adapter needs from the
kernel/registry in order to fulfill its contract.
What kind of data is that?
I am strongly leaning towards making the contract between kernel and
factory very minimal, placing most of the responsibility inside the
factory. Coupled with a clean SPI, a usable abstract base and a pattern
like Delegate, this allows for lots of reuse without requiring rocket
science.
> [Component configuration and container constants]
<snip/>
> the "big" container can take care of getting all the components set
> up.
eh? Why would you want to do that?
> [Instrumentation]
all the AOP frameworks out there have Instrumentation as a standard
example. It works well. The cool thing (and the bad thing) about AOP is
that you can mix it in at any time in the design process. So again, I
believe this is a topic best left for later.
Berin, what are you thinking about? A big container, a small container,
a framework, a kernel, metadata? It doesn't compute.
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] Avalon Container Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
What you're are talking about is container internals, am I right? My
outline is much more abstract (probably too abstract). Probably the best
way for us to figure out what we can make "plug and play" is to begin
implementing with plug-and-play functionality in mind, and then pull out
interfaces as we go. You would know a lot more about this that me. I have
never even played with Merlin, Fortress, etc.
However, I want to be careful not to make things too concrete.
Implementation should be easy, but should be able to be done more than one
way :)
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Thursday, November 20, 2003 11:21 AM
Subject: Re: [proposal] Avalon Container Framework
> Jonathan Hawkes wrote:
>
> > This is a follow up to the threads: [RT] IoC Type Who Cares? [proposal]
IoC
> > type 3.14 extension to the Avalon Framework
> >
> > If you are coming into this discussion late in the game, you may want to
> > review the above threads for more detail.
> >
> >
>
> <snip type="implementation stuff"/>
>
> There are some pieces that are missing from your overview.
>
> The thing is that the container needs to know where it can find things.
In
> order to do that, we have to specify how to resolve things within the
kernel.
>
> Meta data is very important, and all containers rely on it. Some
containers
> rely on *implicit* meta data by defining the values for certain aspects of
> the system. Other containers are more flexible and let the user define
the
> meta data. The critical thing here is not so much whether to have it, but
> how to access it.
>
> For instance, merlin has one meta model, that is fairly robust--but also
very
> well defined. Fortress and ECM are examples where much of the metadata is
> implied or assumed.
>
> As long as we have a consistent interface to get metadata for a particular
> class, I really don't care how it is implemented. This will allow us some
> flexibility in testing or pursuing new ways to store metadata. It is the
> mini-container (the small component container that you were outlining)
that
> needs to know how to resolve the information.
>
> The second important issue is how to resolve other components. As long as
> we have a service type, we should be able to resolve based on what
> implementations we have. The "big" container (or kernel) will take care
of
> the best-match algorithm, even if that best match algorithm is based on an
> assembly file.
>
> Lastly is the subject of component configuration and container constants.
> For this, the best approach I can think of is sort of a "registry" of
sorts.
> We need a way of automatically matching a configuration element to a
particular
> component, but once that is solved, the "big" container can take care of
getting
> all the components set up.
>
> I suppose another point to concider is instrumenting the components. For
> example, if I want to know how long it takes to perform certain functions
> on average, the container should be able to automatically add
instrumentation
> points on any publically accessible item. Or even insterceptors on the
method
> calls.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] Avalon Container Framework
Posted by Berin Loritsch <bl...@apache.org>.
Jonathan Hawkes wrote:
> This is a follow up to the threads: [RT] IoC Type Who Cares? [proposal] IoC
> type 3.14 extension to the Avalon Framework
>
> If you are coming into this discussion late in the game, you may want to
> review the above threads for more detail.
>
>
<snip type="implementation stuff"/>
There are some pieces that are missing from your overview.
The thing is that the container needs to know where it can find things. In
order to do that, we have to specify how to resolve things within the kernel.
Meta data is very important, and all containers rely on it. Some containers
rely on *implicit* meta data by defining the values for certain aspects of
the system. Other containers are more flexible and let the user define the
meta data. The critical thing here is not so much whether to have it, but
how to access it.
For instance, merlin has one meta model, that is fairly robust--but also very
well defined. Fortress and ECM are examples where much of the metadata is
implied or assumed.
As long as we have a consistent interface to get metadata for a particular
class, I really don't care how it is implemented. This will allow us some
flexibility in testing or pursuing new ways to store metadata. It is the
mini-container (the small component container that you were outlining) that
needs to know how to resolve the information.
The second important issue is how to resolve other components. As long as
we have a service type, we should be able to resolve based on what
implementations we have. The "big" container (or kernel) will take care of
the best-match algorithm, even if that best match algorithm is based on an
assembly file.
Lastly is the subject of component configuration and container constants.
For this, the best approach I can think of is sort of a "registry" of sorts.
We need a way of automatically matching a configuration element to a particular
component, but once that is solved, the "big" container can take care of getting
all the components set up.
I suppose another point to concider is instrumenting the components. For
example, if I want to know how long it takes to perform certain functions
on average, the container should be able to automatically add instrumentation
points on any publically accessible item. Or even insterceptors on the method
calls.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: AMMENDMENT: [proposal] Avalon Container Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
On second thought, the Disposable interface is no longer necessary since a
ServiceContainer is now marked as a service itself. The container could be
shutdown by invoking ContainerUtils.dispose(container).
> Please remove the ServiceContainer.getServices() convenience method. It
> assumes too much.
>
> public interface ServiceContainer
> extends ServiceManager, Disposable {
>
> String ROLE = ServiceContainer.class.getName();
>
> Set getServiceRoles();
>
> ServiceConstructor getConstructor(String role);
>
> void registerService(ServiceConstructor sc)
> throws ServiceRegistrationException;
>
> void unregisterService(String role);
>
> /* BEGIN from ServiceManager **
> boolean hasService(String role);
>
> Object lookup(String role)
> throws ServiceException;
>
> void release(Object service);
> ** END from ServiceManager */
>
> // Uncertain about this method...
> // The List can be modifiable/unmodifiable
> List getChildContainers();
>
> void verify()
> throws ServiceResolutionException;
>
> // from Disposable
> void dispose();
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
AMMENDMENT: [proposal] Avalon Container Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Please remove the ServiceContainer.getServices() convenience method. It
assumes too much.
public interface ServiceContainer
extends ServiceManager, Disposable {
String ROLE = ServiceContainer.class.getName();
Set getServiceRoles();
ServiceConstructor getConstructor(String role);
void registerService(ServiceConstructor sc)
throws ServiceRegistrationException;
void unregisterService(String role);
/* BEGIN from ServiceManager **
boolean hasService(String role);
Object lookup(String role)
throws ServiceException;
void release(Object service);
** END from ServiceManager */
// Uncertain about this method...
// The List can be modifiable/unmodifiable
List getChildContainers();
void verify()
throws ServiceResolutionException;
// from Disposable
void dispose();
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] Avalon Container Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
That's the whole point. I'm not a big fan of reliance on external
meta-data. I don't mind using it. Infact, I like it. I just don't want to
be dependent on it. I believe Avalon has a need for simple container
implementations. I would like for it to be usable "out of the box". Also,
if there was a formal container specification, it would make it simpler to
pick and choose from different container implementations and put something
nice together piecemeal (like Pico).
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Thursday, November 20, 2003 10:40 AM
Subject: Re: [proposal] Avalon Container Framework
>
>
> Jonathan Hawkes wrote:
>
> >Any questions, comments, criticisms?
> >
>
> Jonathan :
>
> I don't understand the need for additional interfaces. As far as I can
see any of the Type-X semantics can be implementated within an Avalon
container by leveraging meta-info.
>
> Stephen.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/ |
> |------------------------------------------------|
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] Avalon Container Framework
Posted by Stephen McConnell <mc...@apache.org>.
Jonathan Hawkes wrote:
>Any questions, comments, criticisms?
>
Jonathan :
I don't understand the need for additional interfaces. As far as I can see any of the Type-X semantics can be implementated within an Avalon container by leveraging meta-info.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org