cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject block perspectives
Date Wed, 01 Oct 2003 08:33:12 GMT

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?


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 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.

  * 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.

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
  * 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 J. McConnell

View raw message