Composite Asset Types
The CentraSite data model provides a means of representing composite assets and allows operations to be performed on the entire composite asset or on sub-components in a consistent and well-defined manner.
The following operations take the composition definitions into account:
Deleting an asset
Exporting an asset
Creating a new version of an asset
Setting the instance permissions on an asset
Changing the owner of an asset
Moving an asset to another organization
Note:
Lifecycle state propagation is not included in the above list, as such models can cause major problems in their definition and consistency rules. If such a model is required, then it should be implemented through a custom pre-state change or post-state change policy.
Shared and Nonshared Components
Sometimes a component can serve as a constituent of multiple composite objects. For example, XML schema, ABC, might contain schema, XYZ, as one of its components. Other services and schemas may also include schema XYZ as a component. Components that can belong to more than one composite object are referred to as shared components. Components that can only belong to a particular instance of a composite object are referred to as nonshared components. For example, the operations, bindings and interfaces associated with a Web service are considered nonshared components. These objects belong solely to the service and cannot function as constituents of other composite objects. Schemas, however, are considered sharable, meaning that they do not belong exclusively to a particular composite object.
Required Objects
Besides components, a composite object can also have required objects. Required objects are registry objects or repository items that are not actually part of the composite object itself, but support or augment the composite object in an essential way. For example, if a Service object has a WS-Policy attachment, the attached policy is treated as a required object because it specifies the WS-Policies that must be applied to the service when it is deployed.
Required objects, while not actually part of the composite object, must be present in the registry to make the object wholly complete or usable. (An asset's required objects are generally objects that the export process must bundle with the asset in order for the asset to be wholly represented and functional in another registry.)
Collectors
A collector is an internal process within CentraSite that identifies all of the constituents of a composite object. A collector examines a given object and returns lists that identify:
The nonshared components associated with the composite object
The shared components associated with the composite object
The required objects associated with the composite object
Each composite type has its own collector. The lists produced by a collector are used by handlers that operate on instances of composite objects. For example, when you delete an XML Schema, the delete handler for schemas deletes the schema itself and all of the schema's nonshared components as identified by the collector for XML Schemas.