avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Service and other Terminology
Date Sat, 31 Aug 2002 16:04:00 GMT

Peter Donald wrote:
> On Sat, 31 Aug 2002 22:38, Paul Hammant wrote:
>>>And we need to come up with a consistent terminology for A, B, F and the
>>>relationships A->F, F->B. Also we may need to define the "B end" of B-F
>>>relationship and the "A end" of A-F relationship
>>>Some options;
>>>A     = Provider or ServiceProvider
>>>B     = Consumer, ServiceUser, ServiceClient
>>>F     = Role, Interface, Service, Work Interface, Facet (as in each
>>>component has many facets)
>>>A->F  = Provides, Implements, Exports
>>>F->B  = Requires, depends, needs, uses
>>>A end = (same terminology as A-F mainly)
>>>B end = Dependency, Receptacle, Need
>>>Any other terminology ? Any preferences?
>>My preference FWIW, is to use terms from those already marketted and not
>>to add any more.
> kool.
>>So +1 to choices from Role, Interface, Service, Implements, Provides &
>>Requires (used in manifests)
> I could live with them. Perhaps the best way to describe it would be via a 
> ComponentInfo-like descriptor. Do you like
> <component>

The top level element <component/> suggest that this is a defintion of a 
component when in fact a component exists as a result of the 
establishment of compoent type in accordance with an instantiation 
profile.  I think the <type/> element name is much clearer and more 
consitent.  Things become a lot easier when talking about different meta 
  if we distinct terms :  type --> profile --> component, etc.

>   <provides>
>     <role>
>       <key>conn-manager</key>
>       <interface>org.apache.avalon.ConnManager</interface>
>     </role>
>   </provides>

Some observations:

    1. Using <provides/> as distinct from </services> feels more
       appropriate - its the collection of outward facing
       functionality without declaring the type of fuctionality.

    2. I don't feel comfortable with the <role/> element - roles
       describe a form of usage of a artifact by a consumer - its
       the consumer that understands a role, not the source of
       the functionality - I would stick to <service/> as the
       subject of what is provided.

    3. The <key/> element is a mig improvement over and above the
       currentl </role> element used in blockinfo, type and
       containrkit DTD - is is much more semantically aligned and
       does not carry any baggage.

    4. Assuming that <role/> used above is equivalent to <service/>
       then the notion of <version/> should be present.  Containers
       can manage multiple versioned interfaces (via classloader
       management) that fully quality the service being provided.

>   <requires>
>      <role .../>
>   </requires>

I would prefer to see <consumes/>.  It is a more natural match to the 
term <provides/>.  The term "requires" is little heavier and does not 
sit so well when we consider optional services.

> </component>
> or maybe
> <component>
>   <implements>
>     <role>
>       <key>conn-manager</key>
>       <interface>org.apache.avalon.ConnManager</interface>
>     </role>
>   </implements>

Implements is missleading because a component type may implement several 
interfaces by only disclose a sub-set.  It's the sub-set we are 
interested in, not what it is implemeting in order to achieve discolse 
of a particular functionality.

>   <requires>
>      <role-ref .../>
>   </requires>
> </component>
> This means that;
> * The term "interface" would be reserved for designating the java interface.
> * Phoenix would adopt Fortress terminology wrt to Roles. ie a Role encompases 
> an interface + metadata (if any).
> * Both containers adopt the terminology "key" for the string they use to 
> lookup role
> I like that. I am less comfortable with the rest. I think I prefer 
> <dependencies/> to <requires/>. (Because dependencies can be optional).
> Replacing Phoenixes <services/> with <implements/> or <provides/> may
> better than sticking with <services/> but I don't really like either of 
> <implements/> or <provides/>. Though I like <implements/> more than

> <provides/>.
>>If we have to obsolete some from the currently used set, then so be it.
>> We're now better at referring to Avalon as Avalon-Framework or
>>Avalon-Phoenix etc, I think the best course of action is term reduction,
>>a terminology page and some coaching on use.
> terminology page is definetly a good idea.

There is some work going on under the Merlin project (yes - it's Merlin 
specific and incomplete).


Cherrs, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message