Aaron:
A couple of notes in line:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
