You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/01/09 20:08:26 UTC
Re: [Apache Avalon Wiki] New: WhichContainer
Aaron:
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
configuration.
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