Metro uses the notion of a component "type" to describe characteristics of a class that collectively make up a component. These characteristics include service dependencies, service production, thread safe capability, lifestyle characteristics, garbage collection policy, logging channel assumptions, and so forth.
From a functionally point-of-view the component type describes the operational criteria. The following table summarises the respective classes used in a component type definition and their role within the runtime container.
| Descriptor | Description |
|---|---|
| Type | The Type class is a serializable object that fully supports encoding and decoding operations specificed by JSR57 (the JDK 1.4 Encoder/Decoder services). It is used to suppliment class infomration with details about the component class such context dependnecies, spevice production and so forth. Types are noprmally stored as encoded XML files collocated with the associated component class using the filename suffix .type. |
| InfoDescriptor | The InfoDescriptor class holds information about component name, the component implementation classname, the implementation version, the component lifestyle, and garbage collection policy. |
| CategoryDescriptor | A Type may declare multiple logging categories using the CategoryDescriptor class. This primary function of this class is the assertion by the component that a logging category is used by the component. This information can be used by mangement applications in the control of logging channel targets and priorities. This information may also be using in the validation of logging category directives by ensuring the category directives are not created for non-existent channels. |
| ContextDescriptor | The component class declares operation dependencies through a Context inner class. Build time validation of class checks for compliance with particular patterns and rules ensuring that the context definition is valid. During this process information about the components content dependnecies (opional/required status, return type classname, key, etc.) is packaged within the context directive using an array of EntryDescriptor instances. Technically speaking this information is duplicating information already available via introspection of the context class - however, maintaining the information within the type reduces runtime overheads. |
| ServiceDescriptor | A component type may assert is capability in terms of service delivery. This is achived through the declaration on one or service descriptors. Each service descriptor associates a version, interface classname, and property set. This information is used when the container is called upon to resolve inter-component dependencies, and is used as the source information when constructing isolated service instances. |
| PartReference | The final aspect of a component type is the declaration of its internal parts. A type can declare 0..n parts. Each part is an assoication of a name (the part key) with component definition. Using parts we can construct composites that are themselves components. This techique enables effective scaling of componet-based-solutions. Internally within a container a composite component appears as a simple case of wiring, assembly, and ordered deployment. No special handling is needed for components that are themselves composites. During part assembly, sibling components (parts) are considered as the primary provider candidates. |
A type Ant Task handles the construction of externalized type descriptors based on a combination of supplied information and component class introspection.