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