avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Resolving Services
Date Wed, 18 Sep 2002 14:21:08 GMT

Berin Loritsch wrote:

> 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.

I agree that the Service should be defining rules - but it is still the 
DepedencyDescriptor (which references the Service) that defines the 

>>  * 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. 

Ok - in my head I'm assuming that a DepedencyDescriptor will already 
have a reference to the Service instance it is qualifying.

>>  * 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.

Wrong.  I have several components that declare and implement particular 
services, however, this does not imply that the component Type 
physically implemenmts those interfaces. Merlin assumes that the default 
"protocol" for service access is based on a types implementation of an 
interface, however, Merlin also recognizes alternative protocols.  For 
example, Merlin can handle company X that provdies service Y via 
protocol Z.  Giving the ability to a componet to declare that it is the 
source of service establishment is not the same as saying that it is the 
source of service access (although the majority of cases this is true).

>>  * 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.

The implementation isn't in place yet but I was planning on assigning 
the Servive instance when constructing the DepedencyDescriptor instance. 
 As such, the DepedencyDescriiptor would already have a direct reference 
to the context infurred by the Service defintion.

>> 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.

Let's dig into this a little more.

Firstly - I'm assuming that Stage can be folded into a 
DependencyDescriptor + attribuite and that Extension can be folded into 
a ServiceDescriptor + attribute.  By folding Stage and Extension we end 
up with two distinct and functionally different meta level classes - 
Type and Service.  A Type declares its relationship to a Service via (a) 
a DependencyDescriptor and/or a (b) ServiceDescriptor.

  Type != Service.

Secondly - the term "componet" - I belive (at this level) the term is 
simply too generic.
Consider the following:

   component Type (class, attributes, dependecies, service delcarations, 
   component Profile (Type populated with data concerning instantiation 
criteria and policy)
   component instance (Profile instantiated relative a lifestyle policy)

A Type may by used by many Profiles
A Profile may be used by many Instances.

When we use the term "component" I basically thinking "an instance of a 

> 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>

I'll check the docs - I know there is stuff that still reflects the 
assumption that the service is defined within the 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.  

Not totally following - the <type><services><service><reference> points

to a service descriptor.  It is statement that a component derived from 
the type will establish a service referrd to by the reference.

> I would be
> happier for a service XML descriptor to be declared like this:
> <service>
>   <!-- All the stuff about the service -->
> </service>

Ummm, it is!

A <classname>.xservice contains:

        <attribute key="a-key" value="a-value"/>

But the xdocs are not in place yet :-(

Been too busy with an embedded version of Tomcat running inside Merlin 
as a component - I'm also playing with component based servlets (i.e. 
Servlet's implemeting Avalon lifecycle interfaces).  Some interesting 
aspects arise with respect to the overall containment management 
principals which I'm looking into now.  Basically in the Tomcat scanrio 
you have a container that is instantiating the component and I'm working 
on leveraging Merlin assembly to take the instantiated component 
(Servlet) and applying lifecycle processing to it before it enters into 
the classic Servlet lifecycle.

Cheers, 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