CentraSite Documentation : CentraSite Administrator’s Guide : Object Type Management : Working with Composite Types
Working with Composite Types
 
Shared vs Nonshared Components
Required Objects
Collectors
Defining Composite Asset Types
Semantics of Relationships and Operations
Extended Rules
Usage Scenarios
Propagation of Profile Permissions
Predefined Composite Asset 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.
Copyright © 2005-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback