Defining Composite Asset Types

The relationships between components of a composite asset are defined using relationship attributes available in the appropriate asset type definition(s). A relationship can be defined on the root component or on a sub-component.

In addition to using the predefined composite asset types, you can define your own composite asset types. A user-defined composite asset type consists of the following parts:

other asset types or object types; instances of these types will be related to the root component or to each other by means of relationship attributes.

The definition of a relationship may be changed at any time without affecting any instances.

You set up the associations between the components of a composite asset by using attributes of the data type "Relationship" in the asset type definition. A relationship indicates a coupling between two objects. A relationship has a direction, meaning that one of the related objects is the source of the relationship and the other object is the target of the relationship. When you define a relationship, you define it on the source object, not on the target object.

For information on how to create attributes of the data type "Relationship," see Creating a New Type.

The semantic of a relationship is usually indicated by the name you choose for the association type of the relationship attribute (for example, "hasChild" or "hasParent"). You can think of the association type as a label that does not affect the behavior of the composite asset (technically it is a classification on the relationship attribute), although it makes sense to choose meaningful association types for the relationship attributes. To inform CentraSite about the semantics of the associations in your composite asset type, you need to define the relationship attributes.

CentraSite provides several forms of relationship that allow you to define plain relationships between assets as well as relationships for composite assets.

For our purposes, we will use terms and concepts introduced by UML as follows:

Association. The loosest form of coupling is provided by the association relationship. This is like a cross-reference between two components. It indicates that there is a dependency between the components but no aggregation or composition. In this case, registry operations performed on a component do not cause any operation to be performed automatically on the related component. For example, suppose Asset A contains an association relationship to Asset B and then Asset A is then deleted; in this case, the registry remains in a consistent state without having to delete or modify Asset B in any way.

Note:

When an asset instance has an incoming relationship it may not be deleted until that incoming relationship has been removed or the asset that is the source of the relationship is in the delete set.

Aggregation. A tighter coupling is provided by the aggregation relationship. Aggregation is similar to a whole/part relationship in which components of a structure can also exist independently of the structure; this is like the "contains" semantic, whereby one component contains another component but does not own it. In this case, some operations performed on a component cause the same operation to be performed automatically on the related component. For example, if you want to export an asset, CentraSite automatically extends the export set by adding all of the components that are coupled by aggregation. However, if you want to delete an asset, CentraSite leaves the coupled components unchanged.

Composition. The tightest coupling is provided by the composition relationship. Composition is similar to a whole/part relationship in which components of a structure cannot exist independently of the structure; this is like the "owns" semantic, whereby one component owns another component. In this case, all registry operations performed on a component cause the same operation to be performed automatically on the related components. For example, if you want to delete an asset, then CentraSite automatically extends the delete set by adding all of the components that are coupled by composition.

The form of relationship determines the way in which registry operations performed on one component affect the related components. In the following table, entries marked with "yes" mean that an operation on a component causes the same operation to be performed on the related components, whereas table entries marked with "no" mean that the related components are not changed.

Operation on component	Form of Relationship:
Operation on component	Association	Aggregation	Composition
Move asset to another organization	no	no	yes
Change asset owner	no	no	yes
Delete asset	no	no	yes
Export asset	no	yes	yes
Set instance permissions on an asset	no	yes	yes
Create new version of an asset	no	no	yes

These operations are the primary set which are affected by different forms of relationships and are supported out-of-the-box by CentraSite.

Aggregation and Composition come in two forms, namely "with source" and "with target":

Aggregation/Composition with source. This means that the aggregation or composition treats the source component (that is, the component where the relationship is defined) as the containing or owning component and the target component (that is, the component that the relationship points to) as the contained or owned component.

Aggregation/Composition with target. This means that the aggregation or composition treats the source component (that is, the component where the relationship is defined) as the contained or owned component and the target component (that is, the component that the relationship points to) as the containing or owning component.

You might find the following diagrams useful to illustrate the relationships in composite assets. They are similar to UML diagrams, but allow the aggregation or composition to be on the target component (in UML, they can only be on the source component). The forms "with source" and "with target" are represented using a diamond-shaped symbol to indicate the containing/owning component. Aggregation is indicated by a non-filled diamond symbol and Composition is indicated by a filled diamond symbol. An arrow points from the source component to the target component, with the arrowhead located at the target component. If the diamond symbol and the arrowhead are located at the same component, only the diamond is shown.