avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Constraints on dependencies
Date Thu, 06 Jun 2002 23:43:21 GMT
Hi,

Heres a basic summary of things regarding constraints on 
dependencies.  Consider the following examples.

Terminology
------------------

Component: The object that declares dependency
Provider: The object satisfying dependency
Constraint: Extra conditions that the Provider must satisfy before it will 
satisfy the Components dependency
Kernel: Object responsible for hosting Component and managing lifecycle etc.

Examples
--------------

We have a ClientFrontend component depends on a CORBA Orb and that ORB must 
contain the TimeService and PersistenceStateService (2 standard CORBA 
services).
Component: ClientFrontend
Provider: ORB
Constraint: Must contain TimeService, Must contain PSS

The Myrmidon Executor component depends upon TypeManager component. The 
TypeManager must be thread-safe.
Component: Executor
Provider: TypeManager
Constraint: Must be thread-safe

The Turbine Scheduler component depends upon TimeService. The TimeService 
must be accurate to within 100ms
Component: Scheduler
Provider: TimeService
Constraint: Must be accurate to within 100ms

Design
----------

The next question becomes - how do we design it?

1. Are constraints container specific or not?
2. Is there a subset of constraints that are container agnostic?
3. How do we represent constraints in the system? An opaque string? A 
Configuration tree? An XPath expression?
4. Do the providers or the Kernel validate the constraints?
5. Do the providers get informed that they must conform to certain constraints?
6. Does validation occur at initialization time or assembly time?

My answers would be;
1. Probably
2. Maybe (The <service/> element could be rewritten as a constrain at very 
least)
3. XPath or some expression string is my current favourite
4. kernel
5. No
6. Preferrably assembly time (but that not always possible)

The problem is basically that in some cases it is going to be practically 
impossible for kernel to validate the constraint unless the provider 
conforms to very specific contracts or is self validating.

As for actual code/samples there isn't much at this stage. Merlin allows 
configuration to be contained within a dependency element like

<dependency>
   <service .../>
   <assembly>
     ...arbitrary config data is here...
   </assembly>
</dependency>

And this is merged into components configuration. The component then has to 
be able to understand the configuration and this is effectively interpreted 
as the constraint data.

Rather than freeform config tree I have been playing with elements such as

<constraint type="lifestyle" value="thread-safe"/>

which the container validates by making sure that the component is 
thread-safe.


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


Mime
View raw message