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 be
> 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).
http://jakarta.apache.org/avalon/merlin/dictionary.html
Cherrs, Steve.
--
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]>
