Peter Donald wrote:
The general pattern in most newer containers is to separate info out data different layers;You probably remember Berin's request for refactoring of the assembly/profile/type management in Merlin Based on that, together with feedback on avalon-users, I started work on a set of container indepedent services under the excalibur/assembly package (org.apache.excalibur.assembly as distinct from .merlin). This work is attempting to put in place a set of interfaces that deal with management of (1), (2) and (3) in a way that allows pluggable implementations, and, maintain container independence.
1. information about component type (aka ComponentInfo)
2. information about how to a assemble a component instance (aka ComponentMetaData)
3. information about runtime state of component (or components in case of pooled components) (aka ComponentEntry)
Now (1) can be cross container relatively easy. (2) is likely to be about 70% portable between containers and (3) will most likely be completely container dependent.
The basic seperations are:
* service management
Interfaces and default implementation of
a service manager - basically provides a
hierachical repository of information about
services (independently of component
types capable of providing these services).
The service manager manages Service instances
and allows a clean seperation of service
defintion from service provision by a component
implementation.
* type management
Interfaces and default implementation of a
type manager that provides a hierachical
repository of the component implementations
(types) that are available.
A type manager uses a service manager to
locate and/or create additional service
defintions implied by component meta-info.
* profile management
Interfaces and default implementation of a
profile manager that provides a hierachical
repository of deployment profiles (i.e.
deployment scenarios).
A profile manager handles the registration of
profiles based on container supplied information
and package profiles that are bundled with
coponent implementations.
* appliance management
Interfaces and default implementation of an
appliance manager that provides a hierachical
repository of established appliance instances,
and the defintion of an Appliance which is the
encapsulation of:
* a deployment manager
* a lifestyle manager
* a lifecycle manager
The objective is to provide a default implementation
of each of the above managers. Using the default
implementation, container can declare and alternative
manager, or managers, and components can declare
equivalent deployment, lifecycle and lifestyle
strategies. This will enable a common API, while
allowing specilization and/or alternative
implementations.
While this work is far complete - I do like the fact that all of the above is positioned as facilities that can be used across the spectrum of possible containers. It does not say anything about "containement" and in this respect is very container neutral.
I can imagine different default implementations for particular environments (e.g. J2ME versus J2EE), however, the overall strategy/object-model could be applied across any container solution. This would result in a lot more focus, attention and cohesion on the interfaces and default implementations and put in place the notion of a framework architecture that can be much more rigorous than what we have today. This would lead to improvements in the communication of Avalon with respect to component management and make the overall marketing of what we are about a much simpler and coherent proposition.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
