avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future Direction for Avalon
Date Wed, 07 May 2003 17:55:12 GMT
> Regarding personalitites:
> Doesn't this go back to Nicola's old RT of "containers as adapters"?

In my view, the Avalon micro-kernel is a container of container-services.
Container-services, in turn, provide the component containers.

The micro-kernel provides a minimal set of common facilities necessary to
support containment and interaction of container-services.  Such key
facilities would involve loading, locating, and accessing collaborative
container-services.  Perhaps not a whole lot more.  Other key facilities may
be implemented as shared container-services.

This architectural approach, using tiny core and a scalable set of shared
services below the container model exposed to client code, ought to provide
the necessary scalability and adaptability that people have said is desired.

Stephen refers to an API and SPI, similar to what we have in JNDI, JavaMail,
and other such subsystems.  The subtle difference is that the micro-kernel
provides the SPI, and container-services end up provding the API to the
components they contain.  The latter is because even though we have the
Avalon Frameworks, in theory a container could provide a different set of
interfaces to its components.

> A way to nest containers. A component can then be a container
> itself (much like Fortress was designed to be, and Merlin as
> well I believe).

Certainly possible, but I would not overly focus on the micro-kernel
containment of container-services having to reflect a recursive view of
containment.

> A standardized way to publish services from one container to
> another. I believe we settled on JNDI for this.

That would be good, since everyone else is standardizing on JNDI.

> Then whatever laws of nature that apply within one container is
> largely irrelevant - as long as we can take one service that is
> provided by a component in one container and let it be accessed
> by another component in another container in a controlled way.

Right.  The containers manage their components, and the microkernel provides
a means by which containers collaborate to make components available for use
by components in other containers.

Commonality of code within container-services should be fairly high.  They
would differ where they differ in behavior, e.g., if Merlin and Phoenix
implement lifecycle handling differently, their container-services would
have different code managing the lifecycle of their contained components.
HOWEVER, the lifecycle of the container-services would be 100% standard,
because that is specified by the microkernel SPI.

Stephen's guess is that 60% - 80% of the code required to host Phoenix and
Merlin personalities would be common.  I think that's pretty promising,
considering their differences and the fact that all of this is just a
gedanken experiment to date.

	--- Noel


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


Mime
View raw message