A Component is a remotely reachable object that is established using a data Model. Component and model implementations are established via a Controller. A controller is selected based on meta-data included in a stand-alone part datastructure. All components implement the common Component interface dealing with:
- activation: handles assembly of the component
- lookup: used for resolving potential service providers during assembly
- provider: access to runtime service providers
The net.dpml.metro.runtime.DefaultComponentHandler class is the reference implementation of the Component interface. It is created by the CompositionController using either an implicit or explicit remotely accessible ComponentModel that aggregates information about a component type and deployment solution.
Following the separation of model and control concerns, the DefaultComponentHandler has as associated class controller to which a majority of functional concerns are delegated. This internal controller deals with the establishment of the lifestyle handler taking into account lifestyle and collection policies declared under the ComponentModel. The DefaultComponentHandler maintains a map of objects implementing the net.dpml.lang.Instance interface. This map representes the collection of runtime service providers bound to the type/directive combination.
Creation of a new Component is managed exclusively by the top-level controller. An new component may be created via a reference to a network accessible part, or alternatively via a reference to a remote component model. An example of a management system leveraging model-based creation is the DPML Station wherein configuration data is established relative to the component type, deployment profile, and subsequent modified by the Station CLI.
The actual implementation class that is established is a function of the controller declared in a part definition. This mechanism enables the concurrent deployment of different back-end controller implementations. This in-turn enables the potential deployment of components associated with not-yet-created controller implementations. Inversely, an existing controller can incorproate components based on legacy implementations.
Principal interfaces used in the component model include:
| Component | A remotely accessible view of a component. The Component interface exposes information about the component activation policy, access to instance handlers (the Provider) and general operations supporting component assembly. |
| Provider | A remotely accessible view of a managed component instance. The Provider is in effect an component instance with associated deployment state, A given component instance may have 0..n provider instances associated with it (controller by the associated component lifestyle policy). |
Component implementation acting in the capacity of a container (a component with one or more internal parts) can aquire access to privilaged management interfaces enabling fine grain control of a composition. These management interface include:
| PartsManager | The PartsManager interface is a local interface accessible to component implementations that are acting in the role of a container (i.e. a component managing a collection of subsidiary components. Using the parts manager a component implementation can directly access internal components as ComponentHandler instances. The PartsManager may be declared as a component implementation constructor argument. |
| ComponentHandler | The ComponentHandler interface provides a set of operations that enable local management of the component context, configuration and related policies. In addition the component handler exposes operations through which the managing implementation may navigate the structure of its internal parts. ComponentHandler instances may be resolved via the Partsmanager. |