avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Apache Avalon Wiki] New: WhichContainer
Date Fri, 09 Jan 2004 19:08:26 GMT


A couple of notes in line:

site-cvs@avalon.apache.org wrote:

>    URL: http://wiki.apache.org/avalon/WhichContainer

> So in this sense, Components ARE Services.  But now the Avalon 
> community had two names for the same thing and this is generally 
> were confusion arises.

I disagree with this.  A "component" is an implementation artifact that 
exposes 0..n services.  A "service" is computation contract exposed by a 
component.  A component may include many other features that are not 
exposed through the services that is publishes.

A "service" is typically represented by a Java interface and possibly 
supporting meta-info (such as a version, attributes, etc.).

A "component" is an example of a "service-delivery-strategy".

> Secondly, each container (currently) uses its own meta-data format.
>   Phoenix = .xinfo file + block level assembly files
>   Merlin  = .xinfo, .xtype + block level "block.xml" files
>   ECM     = single XML file for all roles,
>             single XML file for all implementations
>   Fortress = can use ECM style configuration
>              also uses simple 'meta-data' format with a services list
>              that lives in the META-INF directory of a jar file

It's important here to separate out meta-info and meta-data.

Container Meta-Info Matrix (standard are critical)

     Container       Meta-Info Strategy
     Phoenix         Container specific <blockinfo> descriptors.
                     Contains information about service publication
                     and service dependencies.

     Merlin          Uses the standard Avalon Meta package. Avalon
                     Meta descriptors expose information about service
                     publication, runtime dependencies, context
                     dependencies, deployment dependencies,
                     deployment extension support, and a framework
                     for general attribute association.

     ECM             Uses marker interfaces to derive meta-info.

     Fortress        Uses a combination of marker interfaces and
                     a service to component mapping table.

Container Meta-Data Matrix (solutions reflect container features)

     Container       Meta-Data Strategy
     Phoenix         Maintains a list of components under a
                     config file which are assembled based on a
                     static mapping declared under an assembly
                     file.  System configuration is archived through
                     a facilities file.

     Merlin          Meta data for the kernel definition is contained
                     under a kernel configuration (kernel.xml) which
                     defines internal facilities defined under a
                     system block. Component meta-data used for
                     internal facilities and application components
                     are described in a block directive. A block
                     directives may contain component and container
                     declarations, and include other from local or
                     remote locations.  Block directives may be
                     configured to simulate components.

     ECM             Uses roles files to map names to configurations.

     Fortress        Uses roles files to map names to configurations
                     and provides support for container level

Cheers, Steve.


| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |

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

View raw message