My take:
Definitions
-----------
avalon lifecycle interface: a well-known lifecycle interface defined in
the org.apache.avalon namespace supported by all avalon containers
block: deprecated alias for component
component: A passive entity that performs a specific role
container: An active entity that manages component lifecycles and
performs low-level functions
consumption: the usage by a component of a service
dependency: the specification of the consumption requirements of a
component
entity: part of the computer hardware and/or software system
lifecycle: specification of the phases and stages applicable to a
component
lifecycle interface: an interface specifying one or more lifecyle stages
lifecycle extension: the combination of an application-specific
lifecycle interface and the resources required by a container to support
components that implement that interface
metadata: the complete set of specifications of component types,
component profiles and service definitions
phase: ?
profile: the combination of the specification of resources consumed by a
component at runtime and the type applicable to the component
provision: the supplying of a service implementation
resource: any entity or combination of entities
role: the key by which a service is referenced at runtime
service: the combination of a work interface and a version. We give each
service a unique name by which it can be identified and referenced
stage: ?
type: the combination of a service specification and a dependency
specification
work interface: a java interface specifying component functionality (as
opposed to specifying component behaviour)
Notes
-----
- I don't like the definition of phase or stage (couldn't figure it out)
- I don't like the term "type". I use it because that is what is
currently in use for merlin.
- I have not stated component == service. While this is currently
usually true when you actually look at the actual code, the words are
conceptually very different.
- It is useful to do a lookup of the terms "component", "service",
"entity", "element" etc in your dictionary (or dictionary.com). You will
notice "service" has a definition very different from the others
Example
-------
Since y'all have been throwing metadata snippets in with the discussion,
I'll do so to:
We have a *type* that *provides* "my-service" and *consumes*
"my-required-service" and optionally "my-second-service" for
additional/improved functionality.
<services>
<service name="my-service"
version="1.0"
interface="com.blaat.MyService"/>
<service name="my-second-service"
version="1.2"
interface="com.blaat.MySecondService"/>
<service name="my-required-service"
version="1.1"
interface="com.blaat.MySecondService"/>
</services>
<type name="my-component"
version="1.0">
<provides>
<service refid="my-service"/>
</provides>
<consumes>
<service refid="my-second-service"
optional="true"/>
<service refid="my-required-service"
optional="false"/>
</consumes>
</type>
<component name="my-component-instance">
<type refid="my-component"/>
<configuration>
<!-- blah -->
</configuration>
<context>
<!-- blah blah -->
</context>
</component>
cheers,
Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
