Working with Composite Types
Certain assets can be stored in CentraSite as a set of related registry objects. Such assets are called composite assets. For example, if a web service provides several operations, this is stored in CentraSite as a composite asset consisting of the Service asset plus a separate Operation object for each of the web service's operations.
The objects that are constituents of a composite asset are referred to as components. In a composite asset there is a root component and one or more sub-components that are related to the root component. In the above example, the Service asset is the root component and the Operation objects are the sub-components. A sub-component of a composite asset can itself be a composite asset.
Depending on the relationships defined, registry operations (such as deleting an asset or exporting an asset) performed on a component of a composite asset can cause the same operation to be performed automatically on other components of the composite asset.
The concept of relationships between different objects in a SOA environment follows the UML idea of association relationships. This is only one of several forms of relationship supported by UML, but most SOA Registry Repositories only offer this form. CentraSite extends this scope to provide "aggregation" and "composition" relationships in addition to the existing association relationships. Each of these relationship forms provides its own semantics that affect specific operations that can be performed on composite assets.
You can define composite assets for all asset types, including custom (that is, user-defined) 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 experience has shown that such models can cause major problems in their definition and consistency rules. If such a model is required, then it should be implemented via a custom pre/post-state change policy. |