On Mon, 2 Sep 2002 21:21, Binary Runner wrote:
> I'm adding notes as a pure observer although
> I think it could help to cast light on some terms
> (at least for me).
I think you see it identically to me ! ;)
>
> how I understand "service":
>
> service is for me an abstract concept,
> let's say "a set of presumptions we suppose
> to be met" -- these presumptions can be
> both dynamical (the service provides certain
> functionality) or statical (the service is
> accessible via certain interface -- call it
> contract, if you want)
>
> so term service is closest to abstract class maybe
>
> what provides the service is not service but
> a service implementation -- class in oo terminology
>
> the particular instance is service instance or
> service provider
I tend to use the term ServiceProvider ;)
> word "role" has a different meaning for me
>
> as I understand you use a ROLE property to identify,
> that the given class implements the particular
> service interface (please tell me if I'm wrong!),
> so why do not call it e.g. IMPLEMENTS[_SERVICE]
> instead ? it would be a lot more readable
>
> I understand "role" as something what put some
> constraints to the environment usage by the
> particular entity -- e.g. entity 'chicken' is
> in the role 'meal' what puts on it the constraint,
> that it should be fast moving and quiet or the
> 'fox' (you know the service consumer;) will eat
> it
right again.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
