You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/09/01 00:16:18 UTC
Re: Service and other Terminology
On Sun, 1 Sep 2002 02:04, Stephen McConnell wrote:
> > <provides>
> > <role>
> > <key>conn-manager</key>
> > <interface>org.apache.avalon.ConnManager</interface>
> > </role>
> > </provides>
...
> 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.
The role is an equally valid concept from either end. The "Harrison Ford"
Component can declare that it will fit into role "Han Solo". The "Fisher"
Component can declare a dependency on "Han Solo" role via key
"love-interest".
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service and other Terminology
Posted by Peter Donald <pe...@apache.org>.
On Sun, 1 Sep 2002 22:56, Stephen McConnell wrote:
> Peter Donald wrote:
> > On Sun, 1 Sep 2002 02:04, Stephen McConnell wrote:
> >>> <provides>
> >>> <role>
> >>> <key>conn-manager</key>
> >>> <interface>org.apache.avalon.ConnManager</interface>
> >>> </role>
> >>> </provides>
> >
> > ...
> >
> >> 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.
> >
> > The role is an equally valid concept from either end. The "Harrison Ford"
> > Component can declare that it will fit into role "Han Solo". The "Fisher"
> > Component can declare a dependency on "Han Solo" role via key
> > "love-interest".
>
> And in both cases it is neither Harison Ford or Carrie Fisher that
> contain the role. The role is defined outside of them - they represent
> components that are defined by something else and only "fit" in terms of
> the matching of their respective sevices and attributes with the outside
> thing. The outside thing in this example is a script.
>
> I.e. a <provides/> context should not be containing information about
> roles.
As I said a few days ago - it wont. The ComponentInfo will only contain names
to implementationKey of ServiceInfo. The ServiceInfo will then container all
information related solely to service interface.
ComponentInfo may indicate extra constraints (ie I need QOS=3) or
implementation strategies (ie I am a QOS=3 implementation) but other than
that the ServiceInfo will contain all the service specific stuff.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Service and other Terminology
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
>
> Sorta ;)
>
<cut/>
>
> Confusing terminology eh? ;)
Will get back to you in a moment. My head just exploded and there's
so much blood and brains and assorted fragments over my desk and
screen that my keyboard is getting difficult to use (keys stuck).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service and other Terminology
Posted by Peter Donald <pe...@apache.org>.
On Sun, 1 Sep 2002 23:10, Leo Sutic wrote:
> Agreed - but I think Peter is using the role here as a shorthand for
> the interface name. In the example given, if my code requires a
> org.apache.avalon.ConnManager, I can declare that I require a
> "org.apache.avalon.ConnManager", or I can use the short form
> "conn-manager".
Sorta ;)
"conn-manager" would be key used in Component implementation to lookup role.
"org.apache.avalon.ConnManager" is the "implementationKey" of the Role
(usually the classname of the interface). The Role may be further defined in
a file /org/apache/avalon/ConnManager-service.xml which would declare all
required metadata for role (if any).
Confusing terminology eh? ;)
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Service and other Terminology
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Peter Donald wrote:
> > On Sun, 1 Sep 2002 02:04, Stephen McConnell wrote:
> >
> >>> <provides>
> >>> <role>
> >>> <key>conn-manager</key>
> >>> <interface>org.apache.avalon.ConnManager</interface>
> >>> </role>
> >>> </provides>
> >>
> > ...
> >
> >> 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.
> >
> >
> > The role is an equally valid concept from either end. The "Harrison
> > Ford"
> > Component can declare that it will fit into role "Han
> Solo". The "Fisher"
> > Component can declare a dependency on "Han Solo" role via key
> > "love-interest".
>
> And in both cases it is neither Harison Ford or Carrie Fisher that
> contain the role. The role is defined outside of them - they
> represent
> components that are defined by something else and only "fit"
> in terms of
> the matching of their respective sevices and attributes with
> the outside
> thing. The outside thing in this example is a script.
>
> I.e. a <provides/> context should not be containing
> information about roles.
Agreed - but I think Peter is using the role here as a shorthand for
the interface name. In the example given, if my code requires a
org.apache.avalon.ConnManager, I can declare that I require a
"org.apache.avalon.ConnManager", or I can use the short form
"conn-manager".
I'd -1 that on the grounds that we'd need a canonical list of
short names, which is yet another thing to keep track of.
Then again I could be wrong and Peter means something else.
Peter?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service and other Terminology
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
> On Sun, 1 Sep 2002 02:04, Stephen McConnell wrote:
>
>>> <provides>
>>> <role>
>>> <key>conn-manager</key>
>>> <interface>org.apache.avalon.ConnManager</interface>
>>> </role>
>>> </provides>
>>
> ...
>
>> 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.
>
>
> The role is an equally valid concept from either end. The "Harrison Ford"
> Component can declare that it will fit into role "Han Solo". The "Fisher"
> Component can declare a dependency on "Han Solo" role via key
> "love-interest".
And in both cases it is neither Harison Ford or Carrie Fisher that
contain the role. The role is defined outside of them - they represent
components that are defined by something else and only "fit" in terms of
the matching of their respective sevices and attributes with the outside
thing. The outside thing in this example is a script.
I.e. a <provides/> context should not be containing information about roles.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>