Leo:
Excellent post! Could you put this into some sort of proposal document as a reference point because this listing will probably swawn a bunch of different threads and it would be great if we have a point of reference we can focus on changing, qualifying, evolving, etc. Additional notes in-line. Leo Simons wrote: > My take: > > Definitions > ----------- > > avalon lifecycle interface: a well-known lifecycle interface defined in > the org.apache.avalon namespace supported by all avalon containers +1 > block: deprecated alias for component +1 > component: A passive entity that performs a specific role Only thought here is if the definition which include ".. one or more roles." > container: An active entity that manages component lifecycles and > performs low-level functions +1 > consumption: the usage by a component of a service +1 > dependency: the specification of the consumption requirements of a > component +0.5, could be cleaner > entity: part of the computer hardware and/or software system +1 (taking into the account the definition of resource below) > lifecycle: specification of the phases and stages applicable to a > component +1 > lifecycle interface: an interface specifying one or more lifecyle stages One or more - or just one? My impression is that the lifecycle interface specifices exacly one stage. A ordered collection of stages make up a lifecycle phase (such as startup or shutdown). > lifecycle extension: the combination of an application-specific > lifecycle interface and the resources required by a container to support > components that implement that interface +1 > metadata: the complete set of specifications of component types, > component profiles and service definitions Sounds like you defining a meta model. I generally use metainfo to refer to the type level information (typically criteria), and metadata to refer to the deployment information (typically constraints and directives). > phase: ? An ordered sequence of stages. > profile: the combination of the specification of resources consumed by a > component at runtime and the type applicable to the component Ummm,... I not dissagreeing - but here is an alternative to consider. profile: the specification of the resources to be applied to a component of a particular type by a container. > provision: the supplying of a service implementation "of a service implementation" or "of a service" ? > resource: any entity or combination of entities +1 > role: the key by which a service is referenced at runtime +1 > service: the combination of a work interface and a version. +1 > We give each > service a unique name by which it can be identified and referenced But this isn't in the definition of a service. A unique name is more typically used in a dependency declaration (currently refered to as the role in Merlin and Phoenix). > stage: ? An active entity that is handled within the scope of a particular phase of execution. A stage performs some function on some target. A stage is managed as part of a set of n ordered stages, that collectively make up a phase. Example: lifecycle-startup-phase is a phase in which the stages LogEnabled, Contextualize, Parameterise, Configurable, Initializable and Startable may be applied to a component. > type: the combination of a service specification and a dependency > specification It also includes the implementation specification (the classname). type: the combination of a service specification and a dependency specification and an implementation specification > work interface: a java interface specifying component functionality (as > opposed to specifying component behaviour) +1 > Notes > ----- > - I don't like the definition of phase or stage (couldn't figure it out) See above notes - hope that helps. > - 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> Don't see any benefit in placing consumption and production service definitions into a separate structure. It seems much more natural to include these definitions within the scope of the <provides/> and <consumes/> elements. In addition, you will see different information in a service supply statement to a service consumption statement. Supply statements will/can/could contain attributes qualifying quality-of-service availability, whereas consumption service references will/can/could contain information about quality of service requirements. However, under the influence of Paul (on interface/impl separation), Leo and Berin (on publication of services) and Pete (wrt separation of service declaration from type declaration), I have been thinking the benefits of separation of the service definition and how it plays into classloading management and publishing. Imagine a .xservice resource, packaged under <classname>.xservice where classname is the class name of the service interface. This would allow client access to the service definition in a separate classloader from the implementation classloader. It also allows us to separate assembly concerns inside a container (currently component implementation and the service are closely bound relative to a container scope because the definitions are bound to the same classloader). I.e. <provides/> should *reference* service resources. The <consumes/> tag should *contain* service dependency declarations. Cheers, Steve. > <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]> > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
