Geoff Howard wrote:
Stephen McConnell wrote:
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the last two weeks) you really should. Stefano has put a good series of pages up detailing the plan and the current implementation ideas.
Just a couple of observations -
The usage of /BLOCK-INF may conflict with the Avalon Merlin container /BLOCK-INF which is used to hold avalon block descriptors and related configuration profiles. Usage of "block.xml" also conflicts with block.xml used with the Merlin container which is not the same as block.xml used with the Coocon context.
As it seems you've been reading up on those docs can you give your perspective on where our needs differ from what the various Avalon options offer as they exist now and where they seem to be going in the near future?
Geoff:
Going back to early discussions on the notion of a block (RT-V2 from memory) a common set of requirements could be asserted. These requirements focus on the abstraction of Cocoon requirements to a more general service management viewpoint relative to composite component management.
* management of a running composite system * functional and service modularization through packaging * dynamic composition to create new functional units
Released Avalon facilities that collectively address all of the above include the following packages/systems:
* Avalon Meta - a meta info model to describe a component contract (service dependencies, context casting assumptions, context entry dependencies, configuration schemas, parametirization and logging assumptions) for a given component type - represented as a serializable Type instance. http://avalon.apache.org/meta
* Avalon Composition - this is the meta-data model that describes units of deployment and units of composition. A unit of deployment associates a Type with a complete model describing how to deploy and manage instances of the type. A unit of composition describes the aggregation of a set of deployment units to form a virtual deployment unit. As such, a unit of composition appears as a unit of deployment. The composition model includes meta data directives for classloader management, block composition by reference, and service publication.
* Avalon Activation - the activation framework is the runtime system within which serialized deployment and composition models are established within the runtime environment (classloaders, devices, ports, etc.). The activation framework provides support for assembly of runtime managers (an Appliance that manages a deployment model, and a Block that manages a containment model), the deployment of managers, decommissioning, and potential recommissioning.
* Avalon Merlin - the Merlin platform is a container based on the above packages and a number of Excalibur utilities that provides support for the establishment of kernel level systems (logging, jmx management, repository management, block archive (.bar) installation, etc. The platform is designed for embedding within different application scenarios. http://avalon.apache.org/merlin
In order to address the part of your question concerning where things are going, I'll take a jump back to the original three bullet points I referenced at the beginning and use this to throw some light on current status and forward looking plans.
* management of a running composite system
What we have in place today is the ability to deploy and decommission a kernel (i.e. an all of nothing solution). However, the entire architecture, meta-model and runtime framework is designed to support fine-grain management such that we will be able to redeploy containment or deployment units anywhere within a hierarchy with full consideration for implicit and explicit dependencies. This will be exposed through JMX management points and will provide support for custom component management points.
A second aspect of management concerns the federation of different runtime kernels relative to a single management point. For example a kernel running inside a web-app would register itself with a management server. From the management server you see the set of runtime kernel instance. Each kernel exposes a containment hierarchy and the respective managers (Appliance and Block instances) which in turn expose manageable component instances.
* functional and service modularization through packaging
The meta-info, meta-data, composition and activation framework
provides excellent support for the representation and micro-
level packaging of components at a system level. Complementing
this a repository framework that is structurally equivalent to
the Maven repository model (which provides some interesting
benefits when developing in the Maven environment). The
repository model is possibly the structural part of what is
refered to as a librarian in Cocoon.
Supporting repository management is the bar file. A bar file
(block archive) provides a packaging model that lets us associate
containment and deployment information into a single entity, along
with resources that must be packaged (for example - to meet
particular licensing requirements). Bar file structure mirrors
the structure of a repository for a particular group within a
repository. Current implementation provides support for bar
install. Bar execution is planned but requires some additional
work.
* dynamic composition to create new functional units
This subject is central to the composition, activation and Merlin system. We can do dynamic creation of new service models via composition of existing blocks. For example, each cornerstone component is available in form that can be imported into a composite definition. We have examples available of James as a composite component, the recent release of the OpenIM instant messaging platform, sharing many of the same components that james uses - all using composition as the structural backbone on which each is exposed as new dynamically created service.
However - there are some features of the Cocoon block vision that have not been addressed at this time - and require more than a moments thinking. The first of these is the notion of block inheritance. This functionality is desirable from a service management perspective but will not appear until the fundamentals are rock solid.
Aside from all of that - I have been lurking here off and on for several months - and see overwhelming reasons for collaboration (and equally overwhelming reasons why this could be a bad thing to do). In the short terms there are items that need to be addressed over in Avalon land that will priority in the short term. These include the incorporation of a some additional functionality to complete the legacy Phoenix support (Block listeners and JMX registration, and more comprehensive logging support); work to bring the meta package, composition and activation packages up to the point where we can handle ECM/Fortress components with minimal transition overhead.
Once past the ECM/Fortress/Phoenix function support point - the roadmap lays out a bunch of immediate priorities - management, federation, distribution, and security.
Finally, I am aware that the above does not necessarily answer your question concerning your needs - largely because its kind of difficult to appreciate the needs (mainly a terminology background thing that makes it hard work (for me) to unwind/translate concepts here into the corresponding notions that I'm dealing with. Apologies for that and hopefully this will provide at least a starting point.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
