Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

• Overview

• Shared vs Nonshared Components

• Required Objects

• Collectors

• Defining Composite Asset Types

• Semantics of Relationships and Operations

• Extended Rules

• Usage Scenarios

• Propagation of Profile Permissions

• The Predefined Composite Asset Types

Overview

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 (i.e. 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.

Shared vs 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/or schemas might 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 and/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.

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:

• a user-defined asset type; each instance of this type will be the root component of a composite asset, and

• 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.

See the section Creating a New Type for information on how to create attributes of the data type "Relationship".

The semantic of a relationship is usually indicated by the name you choose for the association type of the relationship attribute (e.g. "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.

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 (i.e. the component where the relationship is defined) as the containing or owning component, and the target component (i.e. 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 (i.e. the component where the relationship is defined) as the contained or owned component, and the target component (i.e. 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.

Semantics of Relationships and Operations

Association Relationship

Association relationships are the relationships that were available in later releases of CentraSite v8 and are available with unchanged semantics in the current release.

Aggregation Relationship

The aggregation relationship changes the rules in the following way for operations:

Note:
For Export, the usage of recursive relationships on the type and instance level must be taken into account. Whereby type level does not mean that the same instance is referenced.

Composition Relationship

Composition relationships affect all of the defined operations to varying degrees.

Operation: Deleting an asset

On deletion, if the root component is added to the set to be deleted, then the sub-components will also be added to the set to be deleted. The direction of the association does not play a role in defining the set, only the containing designation. This means it is possible for the deletion to fail if one of the assets added to the deletion set during this processing is referenced via the basic association relationship target rules.

This rule is applied recursively. For example, if we have three assets that have the relationships "A contains B contains C", then the following statements apply:

• When A is deleted, then B will be deleted and finally because B is deleted, C will also be deleted.

• When deleting C, only C will be deleted.

This fails if the deleting user does not have permission on any of the assets in the set acquired by traversing the graph. The delete is considered atomic - either all are deleted or none. This avoids inconsistencies in the outcome of the operation.

The relationship direction always plays a role in the deletion operation. An asset may not be deleted if it is the target of a relationship and the source is not part of the deletion set.

The deletion rules described here apply also when you purge old versions of an asset. In this case, the purge operation will be applied not only to the component being purged, but also to the related sub-components.

Operation: Creating a new version of an asset

On versioning, if the root component is added to the set to be versioned, then the sub-components will also be added to the set. The direction of the association does not play a role in defining the set, only the containing designation.

If you create a new version of an asset that is the root component of a composite asset, and the root component is related to one or more of the other components via composition relationships, CentraSite automatically creates a new version of each of these other components.

Operation: Exporting an asset

On export, if the root component is added to the set to be exported, then the sub-components will also be added to the set. The direction of the association does not play a role in defining the set, only the containing designation.

Operation: Setting instance permissions on an asset

On setting permissions, when the root component is added to the set to which the permissions will be applied, then the sub-components asset are also added if and only if the user has the permission to modify the permission of the target. If the user does not have permission, then the graph traversal for the target is not carried further for this sub-graph.

The permission set that will be given to all sub-component assets is the merge based on what is to be modified. The permissions assigned to the owned asset are the union of the permissions of the owning asset and the owned asset.

Operation: Moving an asset to another organization

On moving an asset to another organization, when the root component is added to the set to be moved, then the sub-components are also added. No permission checks are done during this operation as only users in the CentraSite Administrator role may perform this operation.

Operation: Changing the owner of an asset

On changing ownership, when the root component is added to the set to be changed, then the sub-components are also added to the set. No permission checks are done during this operation as only users in the CentraSite Administrator role may perform this operation.

Extended Rules

This section deals with the extended rules or semantics that have been added to Aggregation and Composition relationships.

Changing Relationships

As part of the support for Aggregation and Composition, CentraSite allows the relationship form to be changed after the type is created. This change affects all current instances and new instances. This means that after a relationship attribute is created, the form (for association the default form, for aggregation (both forms, i.e. "using source" and "using target") and for composite (both forms)) can be changed by an Asset Type Administrator. From that point onwards, the appropriate rules will be applied when performing the defined operations.

Updating Assets

The following asset updates need to be taken into account when implementing models:

1. Adding relationships to existing instances. Given the below model:

   

   It is perfectly legal to create instances of Type A and Type B independent of one another. In fact in CentraSite this characteristic is mandatory, as the creation of multiple assets at the same time is only allowed in a few places in the UI.

   When adding the relationship between an instance of Type A and an instance of Type B, CentraSite will not do any extra operations to guarantee the consistency of permissions at this point.

2. Adding relationships to 2 different composites. Given the below model (which is a legal model):

   

   The following restriction applies to user-defined asset types, but not predefined asset types: At runtime if an instance of Type A creates a composite relationship to an instance of Type C, and then an instance of Type B tries to create a composite relationship to the same instance of Type C, this composition will be rejected. This is because a contained asset (instance of Type C) can only have one owning asset (instance of Type A or instance of Type B).

Usage Scenarios

• Overview

• Delete usage scenarios

• Versioning usage scenarios

• Permission usage scenarios

• Export usage scenarios

• Move Organization usage scenarios

• Change Ownership usage scenarios

Overview

In the following sections, the outcome of each operation is given based on a very simple type and instance configuration.

Unless otherwise stated, the instances that each operation will be performed on will be:

Delete usage scenarios

Association Relationship

Given the type model:

The result of the delete operation will be:

Aggregation Relationship with containing constraint on Type A

Given the type model:

The result of the delete operation will be:

Aggregation Relationship with containing constraint on Type B

Given the type model:

The result of the delete operation will be:

Composition Relationship with containing constraint on Type A

Given the type model:

The result of the delete operation will be:

Composition Relationship with containing constraint on Type B

Given the type model:

The result of the delete operation will be:

Composition Relationship with permission scenario

Given the type model:

With the constraints:

• User who will perform the deletion is Fred

• Fred has Full permission on IoA

• Fred has Read permission on IoB

The result of the delete operation will be:

Versioning usage scenarios

Versioning for Association Relationship and Aggregation Relationship are the same and do not change from previous versions, therefore only Composition Relationship are shown below.

Given the type model:

Note:
Both variants of a composite relationship (source and target) are supported and are orthogonal.

Based on the instances given above, the following scenarios are considered relevant.

Versioning of IoB

This causes just IoB to be versioned, and the IoA version is left unchanged. Pictorially, this looks like:

Versioning of IoA

Versioning of IoA will result in the composite relationship being used to work out which other assets should be versioned at the same time. This will result in IoA and IoB being versioned together (if we fail to version either then neither will be versioned).

This pictorially looks like:

Permission usage scenarios

For the permission scenarios, the following instances with the annotations for the owner and permissions will be used as basis.

Association Relationship permission propagation

When an Association Relationship is used, the permission propagation does not take place. This means that if an instance permission is set, then only that instance's permission is affected. This means that if user Mary adds Read permission for user Mark on IoA, then Mark only gets permission to Read IoA. He does not get permission to Read IoB. Pictorially this looks like:

Composition/Aggregation with weak propagation

One of the key points of permission propagation is what happens if a user only has a Full permission on a subset of the assets to which the permissions need to be propagated. In this case, the usage of the so-called weak propagation rule comes into effect. The rule states that if a user does not have permission to propagate to all instances in the set, then the permissions will be propagated to only the instances which are allowed.

For this scenario the following model will be used:

Based on this model, the instances and the permissions to start with should be:

Now if user Paul adds Read permission for user Jack to IoA, Jack will only get this permission on IoA as Paul does not have the rights to give Jack the permissions on IoB. Even though Paul has Full permission on IoC, because it is a child of IoB, Jack does not get the permissions for IoC because of weak propagation. We trim/terminate the propagation at IoB.

This pictorially looks like:

Composition/Aggregation Relationship updating sub-component

Updating the permissions of a sub-component without affecting the overall composition/aggregation is not affected with the changes. Therefore if user Fred wants to explicitly add Read permission for Jack on IoB, this is possible.

This pictorially looks like:

Composition/Aggregation Relationship with full propagation

Full propagation happens when all sub-components can be updated by the instigating user. As example, Mary wants to give Read permission to Simon on IoA with permission propagation via the Composition/Aggregation relationship. As Mary has Full permissions on IoA and IoB, the permissions are propagated over the relationship.

This pictorially results in:

Export usage scenarios

Export with Association Relationship

Export will work the same as in previous versions - the usage given here assumes that no additional options are chosen.

Given the model:

The result of the Export operation will be:

Export with Composition/Aggregation Relationship

For both Composition and Aggregation Relationships, the rules are exactly the same. When such a Relationship with the appropriate containing rule is found, then traverse the relationship and add sub-components to the set.

Given the model:

OR

The result of the Export operation will be:

Move Organization usage scenarios

Move organization is an administrative task and may only be performed by someone with appropriate administration rights. This means that permissions and ownership do not play a role when performing the move operation.

Move Organization with Association/Aggregation Relationship

When moving an asset from one organization to another, the Association and Aggregation Relationships do not change any related assets. This is because both of these relationships are considered to be loosely coupled.

Given the model:

OR

The result of the Move Organization operation will be:

Move Organization with Composition Relationship

When a Composition Relationship with the appropriate containing rule is found, then traverse the relationship and move the sub-components to the new organization.

Given the model:

The result of the Move Organization operation will be:

Change Ownership usage scenarios

Change Ownership is an administrative task and may only be performed by someone with appropriate administration rights. This means that permissions and ownership do not play a role when performing the change ownership operation.

Change Ownership with Association/Aggregation Relationship

When changing an asset's ownership from one user to another, the Association and Aggregation Relationships do not change any related assets. This is because both of these relationships are considered to be loosely coupled.

Given the model:

OR

The result of the Change Ownership operation will be:

Propagation of Profile Permissions

In addition to propagating permissions that control the access to an asset instance (as described above), it is also possible to propagate permissions that control the access to the asset instance's profiles.

Profile permissions of the root asset of a composite asset can be propagated to the other components if the components have the same type as the root asset. This restriction arises because different asset types can have different sets of profiles, whereas assets of the same type have the same set of profiles.

Propagation of profile permissions is activated when you mark the checkbox Propagate profile permissions in the asset's Permissions tab. This checkbox can only be selected if you have also marked the checkbox Propagate Permissions to dependent objects.

The Predefined Composite Asset Types

The following identifies the nonshared components, shared components, and required objects that are associated with each of the predefined composite types installed with CentraSite.

• Service

• Virtual Service

• XML/REST Service

• Virtual XML/REST Service

• XML Schema

• BPEL Process

• WS-Policy

• BPM Process Project

• BPM Process Step

• IS Package

• IS Service Interface

• Process

• Process Pool

• Process Swimlane

• Web Application

• Portlet

• CAF Task Type

• TN Group

• Business Rules Project

• Data Model

Service

Virtual Service

XML/REST Service

Virtual XML/REST Service

XML Schema

BPEL Process

WS-Policy

BPM Process Project

BPM Process Step

IS Package

IS Service Interface

Process

Process Pool

Process Swimlane

Web Application

Portlet

CAF Task Type

TN Group

Business Rules Project

Data Model

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT