avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Future Direction for Avalon
Date Mon, 05 May 2003 21:44:46 GMT
Noel J. Bergman wrote:
> Here is a strawman for the scalable container:

deja-vu! You describe nearly exactly the ideas that we tried to 
incorporate into phoenix 4.0 :D. These ideas were then pretty much 
captured in a seperation of (Embedding Environment)/(Services used by 
the Kernel)/(Kernel)/(Userspace code deployed on top of the kernel). For 
fun, lets see where we got....

> I believe that a scalable container can be built around a tiny container
> micro-kernel;

org.apache.avalon.phoenix.components.kernel.DefaultKernel

http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/DefaultKernel.java?rev=1.90&content-type=text/vnd.viewcvs-markup

about as small as it gets.

> a core set of container interfaces (not for public
> consumption)

org.apache.avalon.phoenix.interfaces

http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces/

> that allow container services to installed and bound.

you can install and bind "container services" at startup time 
(kernel.xml) or through JMX in phoenix:

http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/src/conf/kernel.xml?rev=1.39&content-type=text/vnd.viewcvs-markup

> Container services are my term for packages that actually implement
> container behavior.  Implementing a new (or compatible) container behavior
> means implementing the necessary container service(s).

The phoenix "container services" are at

org.apache.avalon.phoenix.components:

http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/src/java/org/apache/avalon/phoenix/components/

> IoC provides a clean way to ensure that client objects are given whatever
> objects they need to see, without regard for how that happens.  Container
> services will be responsible for that behavior, providing a roadmap for
> hosting existing components in new containers, e.g., Phoenix components can
> see a Phoenix environment provided by container services.

Phoenix by default provides a phoenix-specific environment. You tie in 
different components (usually extensions of the existing components) by 
modifying kernel.xml to reference your custom components. The 
environment components see is completely determined by the services you 
load into phoenix through the kernel.xml file; components never access 
the kernel, embeddor, launcher, classloader, dependency graph, etc, 
themselves.

> You mentioned a
> case where someone had a unique notion of some aspect of containership.  A
> container service would implement that, and provide those public interfaces
> to client components.  Container services are also responsible for semantic
> compatibility, i.e., any compatibility issues between components using
> different interfaces in a similar semantic area would have to be managed by
> the container services responsible for each component.  That might (or might
> not) mean some cooperation between the container services, but it should be
> fully transparent to client code.

all this is fully accomplished and works well within phoenix. The 
default environment the default components plugged into the phoenix 
kernel provide add/modify just a few additional semantics above and 
beyound those provided by avalon-framework (BlockContext and ignoring 
SingleThreaded but always acting as if hosted components are ThreadSafe).

So, are we there already? Am I saying we achieved everything we wanted, 
and that all uses are satisfied? I told you so?

Nope!!! Some observations:

1 -  It is difficult to write replacement "container services" for phoenix.

2 - There is no documentation on how to do it. No samples.

3 - Phoenix as currently used is pretty static in setup, and pointers on 
how to support more dynamism are not available.

4 - The phoenix distribution does not split out the various container 
services into multiple jar files, making it difficult to figure out how 
you can replace what parts.

5 - There is a lot of material sort-of nonvital to phoenix which gets in 
the way for developers looking at the internals

6 - Phoenix doesn't really have a true plugin architecture, rather a 
this-is-a-required-container-service-provide-your-impl-here architecture.

7 - Phoenix makes assumptions as to the availability of a filesystem to 
work with, and some others, which we have found do not always apply to 
avalon-based systems

......and so on. The new developments in various areas, like advance of 
interceptor architecture, aspect-oriented programming, lots more 
experience with developing avalon-framework based and styled 
applications, rise of the scalable event/message-based systems in 
enterprise java, better availability and acceptance of scripting tools 
for java, input of the now much larger developer pool, lots more 
knowledge about the typical usecases, rise of extreme programming 
methodology, availability of refactoring tools, lessons learned from new 
container developments, etc etc.....

....those make many people itch to try the same basic thing once more, 
and believe it is possible to do a better job. Yet the basic 
kernel/container pattern and design idea have been around for a long 
time, to the point of making me think "well, doh, totally!" reading your 
e-mail :D

are you itching to do that? I am!

cheers,

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message