[EMAIL PROTECTED] wrote:
>>The real solution here is a _common_container_compliance_specification_
>>
>>Something which you can code against with solid confidence that the
>>container will be doing things in accordance with a common spec. For
>>example - what is the "standard avalon container responsibility" when
>>handling the deployment of an object exposing the framework Executable
>>interface?
>>
>
>Isn't Fortress meant to be a *Reference Implementation* of such a compliance
>specification ?
>
I think it is reasonable to say that we don't have a Avalon reference implementation today.
The main issue is not the respective implementations - it's the specifications we have. Currently we have a set of container supplied artifacts (Configuration, Parameters, ServiceManager, etc.) and related lifecycle interfaces. The specification of the sequencing of lifecycle stages is reasonably complete (with the exception of things like Executable). The specification of the artifacts is however somewhat divorced from the notion of a container. For example, if you look at the Avalon spec for Context or ServiceManager you will see the specification of that interface in isolation. You will not find information that presents these artifacts in terms of a containment context.
For the containment context you need to go to the different container specifications. At this point you will find three different notions of what a containment context means. In Fortress the component/container contract is based on some ECM semantics used in the lookup operation combined with data held in roles files. In Phoenix its based on blockinfo meta info combined with assembly, configuration and environmental information defined at the level of an application. In Merlin it's based on meta info (xinfo, xservice) + component deployment profiles (xconfig, xprofile).
Key things needed to get to a *Reference Implementation* are:
(1) definition of a common meta info model (i.e. how a component type declares information about itself such as context and service requirements)
(a) migration of Fortress, Merlin, Phoenix to the common meta-info model (b) delivery of legacy migration tools/APIs
(2) definition of a common meta-data model (i.e. declaration of data that populates a deployment scenario - e.g. a logging channel priority or targets, component configuration and parameter values, etc.)
(3) resolution of common semantics to be provided by a container
(a) definition of the lowest common denominator semantics
(i) definition of standard context keys (ii) declaration of extended context key semantics (via URIs?)
(b) introduction of mechanisms through which meta-info and and meta-data can be extended, and, common semantic for recognition that an extension is present (enabling a container to reject a component it cannot support)
Given the above - you have the potential for a *reference implementation. Once Fortress is out and the consolidated release process out of the way will be able to put more effort into sorting these things out. The first step concerns the establishment of a formal meta-info model for Fortress.
Berin has already done some initial experimenting on this based on the avalon-sandbox meta package. This is the meta-info and meta-data model used by Merlin. If we migration Fortress to the meta package (using meta info readers that understand ECM style roles and conf files) then we very quickly arrive at a situation where Fortress/ECM components will run inside Merlin and Fortress.
The next step is semantics at the level of deployment. Coming-up with a common model here means that Merlin components (which include Phoenix components) will be executable within Fortress and Merlin. The main issue to be dealt with here is pre-emptive versus runtime based service deployment. Merlin is much more focussed on complex service models (i.e. complex arbitrarily deep dependencies, Avalon and non-Avalon component models, and generally a lot a support for how complex systems can be re-abstracted in manageable deployment scenarios). Fortress is quite different - it's driven by runtime requests it typically request intensive environments. What we have to figure out is how to enable the coexistence of these strategies using a common set of container<-->component artifacts and semantics. Once that it sorted - we will have a reference implementation that will run anything using the right semantics, for the right task, at the right time.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
