avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Resolving Services
Date Wed, 18 Sep 2002 13:10:23 GMT
Stephen McConnell wrote:
> 
> 
> Berin Loritsch wrote:
> 
>> In order to satisfy my RT about service attributes used to provide 
>> automated assembly logic, we need to make some API changes to Meta. 
>> What we are comparing is a Service Reference (i.e. requires service) 
>> to a component (i.e. Type) implementation.  The Service descriptor 
>> with all the attributes provides the rules to interpret the 
>> attributes.  To that end, we need the Service to generate a Comparator. 
> 
> 
> 
> Is it Service or DepedencyDescriptor that generates the comparitor?


It is _Service_.  Service defines the rules for which attributes it will
allow for the decision process, and how it interprets them.  We use the
Comparitor from the Service to compare a DependencyDescriptor against
the list of Components.


>  * A Container is handling selection of a Type from possibly
>    multiple alternatives based on an unresolved dependency.

Right.  And the Comparitor that the Service creates assists in the
decision process.  We *could* have it built from a utility class
that accepts the Service and the DependencyDescriptor.  The two
put together will allow us to have one Comparator that does what we
want.

>  * The dependency is declared through a DependencyDescriptor
>    that uses a ReferenceDescriptor to point to a Service.

Right.

>  * A Type is consider a candidate by virtue of the fact that
>    it declares that it provides the service through exposure
>    of a ServiceDescriptor

Right, and I am saying that the ServiceDescriptor should be pulled
*out* of the generic Type and made its own entity.  If a component
implements a Service, we will know because it implements the interface.


>  * Ranking of candidate types is achieved by the application of
>    "constraints" declared under the DependencyDescriptor relative to
>    the attribute values declared under the ServiceDescriptor exposed
>    by the candidate Type.

The ServiceDescriptor (which should be declared *once* for all
implementing types) provides the basic rules of interpretation.  The
DependencyDescriptor provides the values we are concerned with.  So
we probably need our Comparator generated from both the Service and
Dependency Descriptors.

> So considering we has two service descriptors SD1 and SD2 and we want to 
> compare these for order.  The Comparitor implemetation needs the 
> DepedencyDescriptor as the source of criteria for ranking.  The compare 
> operation is invoked such that:
> 
>   int j = comparitor.compare( SD1, SD2 );
> 
> In which case it seems to me that the Comparitor factory is the 
> DependencyDescriptor class - not the Service class.  Alternatively, you 
> could also look at the DepedecyDescriptor as a comparator. 
> Anyway - yes - this would be a usefull addition to the meta package.

Actually it would be a separate utility class.  It needs the *rules*
from the ServiceDescriptor, and the *values* from the 
DependencyDescriptor to arrive at the subset of components we can
consider.

Thank you for the clarification.

BTW, one thing that bugs me about the whole "Type" thing is that while
the meta package is implemented to work with generic Types does not mean
that the programmer does.  I don't like everything being a generic 
"Type" because then I can't easily separate and group processing on
whole classes of Types like Service, Component, Stage, and Extension.
I have to parse all of them as a "Type" and then manually separate them
out later.  I find that annoying.

PS, can you fix the ServiceDescriptor?  On your site docs you have 
something like this:

<type>
   <services>
     <service>
       <!-- All the stuff about the service -->
     </service>
   </services>
</type>

If this type is supposed to describe a Service, which maps to an 
interface, then there is only *one* service possible.  Also, I think
the "type" element is unnecessary--it should be implied.  I would be
happier for a service XML descriptor to be declared like this:

<service>
   <!-- All the stuff about the service -->
</service>

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message