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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
