Design and change-time polices provide governance controls that you can use to effectively administer and manage web services and other assets within your SOA environment. Design-time policies enable you to control the acceptance of assets into the registry and manage their deployment into the runtime environment. You can use Design/Change-Time policies to ensure that assets entering the SOA environment conform to organizational standards and conventions, meet the architectural requirements of your enterprise, and adhere to industry best practices. You can also use policies to execute standard procedures, such as, initiating review processes, issuing notifications, and granting instance-level permissions at key points in an asset's lifecycle.

Design/change-time policies specify a set of actions that are to be executed when a specified event occurs to an instance of a specified object type. You use design/change-time policies to customize the behavior of CentraSite when certain events occur on assets and other objects in the registry (for example, during creation, modification, and/or deletion events). You can use design/change-time policies to perform tasks such as obtaining approvals, executing automated tests, issuing notifications, and imposing organizational standards when assets or other objects are created, modified, or deleted.

For example, a policy could instruct CentraSite to perform any of the following tasks:

A design/change-time policy has two major elements:

A policy action is a programmed task written in Java (a scripting language). A policy action can perform any type of work you require for example, sending an email, validating an attribute setting, submitting an approval request, updating a database. It can have one or more input parameters. An action that sends an email message includes input parameters that specify the text of the message and to whom it is to be sent. A policy action returns a completion code that indicates whether it completed its task successfully.

The action list in a policy can contain one or more actions. CentraSite executes the actions in the order that they appear in the list. If an action does not complete successfully, CentraSite immediately exits the policy and skips any remaining actions in the list. Policy failures are recorded in CentraSite's policy log.

CentraSite is installed with a library of built-in policy actions that you can use to construct policies. You can also develop your own custom actions using Java

The policy scope specifies the conditions under which CentraSite is to execute the policy. It consists of two main parameters: Event Type and Object Type.

Together, the event type and the object type determine when the policy executes. You can make the scope as narrow or as broad as you need. That is, you can target the policy for one particular type of event and object (for example, a PreDelete event on an XML Schema) or apply the policy to multiple events and objects (for example, a PreCreate, PreUpdate, PreDelete event on a Service, an XML Schema, a BPEL Process).

You can optionally refine the scope of a policy to narrow the set of objects to which the policy applies. To do this, you include additional selection criteria based on an object's Name, Description, or Classification properties. For example, you might create a policy that applies only to Application Servers whose name includes the string myDomain.com or to Application Servers that are classified as Software AG Runtime.

The ability to execute policies based on object classification is an especially effective way to selectively apply policies to objects.

A policy action also has a declared scope. The action's scope specifies the object and event types with which the action can be used. Some actions have very specific object-type and event-type requirements. For example, you can use the Validate Policy Deactivation action only during a PreStateChange on a policy object. Other actions support a broad range of object and event types.

A policy can contain only actions that support the full set of object types and event types specified by the policy's scope. For example, if you create a policy that executes on the PreCreate and PreUpdate events for XML Schemas, it can only contain actions whose scope includes the PreCreate and PreUpdate event types and the XML Schema object type.

When you create a policy, CentraSite's user interface only allows you to select actions that satisfy the specified scope of the policy. If you subsequently change the policy's scope, CentraSite does not allow you to save the updated policy unless all of its actions support the policy's new scope.

Design/change-time policies operate on the objects that CentraSite manages. The types of objects to which you can apply design/change-time policies are:

The type definition for an asset includes a property setting called Policies Can Be Applied. This property determines whether assets of the given type are policy-enabled (that is, whether design/change-time policies are to be executed against them). When this property is enabled, you can create policies that are specific to the assets of that type. Additionally, instances of that type are capable of triggering design/change-time policies that target "assets" in general.

By default, the Policies Can Be Applied property is enabled for an asset type. If you do not want instances of particular asset type to be affected by design/change-time policies, disable this property in the asset's type definition.

When an asset is an instance of a virtual type, the set of policies that CentraSite applies to the asset depends on the virtual type's Inherit Base Type Policies setting. If the type's Inherit Base Type Policies option is enabled, CentraSite applies the policies of the base type to the asset in addition to the policies of the virtual type. For example, the Inherit Base Type Policies option is, by default, enabled for virtual services. Therefore, when CentraSite enforces policies for a virtual service, it applies the set of policies that are defined for the Virtual Service object type and the set of policies that are defined for the Service object type (the base type for the Virtual Service type).

If you disable the Inherit Base Type Policies option for a virtual type, CentraSite applies to the asset only the policies that are defined for the virtual type. For example, if you disable the Inherit Base Type Policies option for the Virtual Service object type, CentraSite applies to virtual services, only the policies that are defined for the Virtual Service type. Policies that are defined for the Service type are not applied.

The following table summarizes how the set of policies that CentraSite enforces for a virtual type is affected by the state of the Inherit Base Type Policies option:

For more information about virtual types and the Inherit Base Type Policies option and which predefined types in CentraSite are virtual types, see Inheriting Base Type Profiles, Lifecycle Models, and Policies.

Many of the event types to which you can apply policies represent pre-operation events or post-operation events.

You can apply design/change-time policies when the following events occur to an object in CentraSite:

Not all object types support the full set of events. Some events occur only with certain types of objects. For example, a PreStateChange event occurs only on Assets, Policies and Lifecycle Models. If you create a policy for a PreStateChange event on a User object, that policy will never execute, because a PreStateChange event will never occur on a User object.

The following table identifies the events that each object type supports:

An action in a design/change-time policy instructs CentraSite to perform a specific task, such as submit a request for approval, send an email notification to a group of users, perform a specified test or validate certain properties of an object.

CentraSite includes many built-in actions that you can use to compose design/change-time policies. Built-in actions are provided in the following categories:

If you need to execute a task that is not provided by a built-in action, you can create a custom action to perform the work. A custom action consists of a Java class that performs the required task (for example, running a test, adding a required attribute, or updating an external database).

To use a custom action, you must upload the Java class to the CentraSite repository and define an action template for it. An action template specifies the location of your custom code and identifies the parameters that it uses. After you create the action template, your custom action appears in the CentraSite Control user interface and it can be inserted into a policy just like a built-in action.

A design or change-time policy is either system-wide or organization-specific. System-wide policies apply to all organizations within an instance of CentraSite. Organization-specific models apply only to a specified organization.

Whether a policy is system-wide or organization-specific affects the policy's scope. When a policy is organization-specific, its scope is limited to the set of objects that belong to a specified organization. For example, if you create a policy that executes on a PreDelete event for XML schemas and you make that policy specific to organization ABC, then that policy executes only when XML schemas in organization ABC are deleted. If you make it system-wide, it executes when an XML schema in any organization is deleted.

You can give a policy a priority value between 11 and 9999 (inclusive). Priority 11 is the default. Values less than 11 and greater than 9999 are reserved for system use.

The Priority setting contains a non-negative integer that indicates the policy's priority. A priority value of 0 represents the highest possible priority. You can give a policy a priority value between 11 and 9999 (inclusive). Priority 11 is the default. Values less than 11 (0 through 10) and greater than 9999 are reserved for system use. These priorities can only be assigned to predefined policies. You cannot assign these priority values to the regular, user-defined policies that you create using CentraSite Control.

When an event triggers multiple policies, CentraSite examines the priorities of the selected policies and executes the policies serially, in priority order, from the lowest value to the highest value (that is, it executes the policy with the lowest value first). Each policy in the series is executed to completion before the next one begins.

For example, if an event were to trigger the following policies, CentraSite would execute the policies in the following order: B, A, C (as determined by the priority assignments 11, 25, and 100 respectively).

If two or more policies have the same priority value, their order is indeterminate. CentraSite will execute these policies in serial fashion after all lower priority policies and before any higher priority policies. However, you cannot predict their order.

If CentraSite were given the following policies to enforce for an event:

It would execute the policies in the following order:

The policy-enforcement process begins when a CentraSite user submits a request that acts on one of the object types. Depending on the type of request the user submits, one of the events identified can occur.

When an event occurs, CentraSite queries its database and executes policies that satisfy the following criteria:

When multiple policies have the same scope, all of those policies are triggered when an in-scope event occurs. To determine the order in which to execute these policies, CentraSite examines each policy's Priority setting.

When an action in a design/change-time policy completes its execution, it returns a completion code and a completion message. This information is written to the policy log if CentraSite is configured to log successful policies.

If the completion code indicates success, CentraSite performs the next action in the policy (if one exists) or completes the requested work on the object (for example, it commits the given change to the database).

If the completion code indicates failure, CentraSite records the error in the policy log. Then it immediately exits the policy. If the policy contains additional actions, those actions are not executed. If the policy was triggered by one of the pre-commit events (for example, during a Pre-Create, Pre-Update or Pre-State Change event) the requested operation is not performed. If the initial request had triggered multiple policies, any policy that had not yet been executed will be bypassed.

CentraSite includes a set of predefined policies that execute internal operations on the registry. Many of these policies relate to operations such as deleting objects, exporting objects and moving objects. By default, predefined policies are not shown in the policy list, however, you can view them by enabling the Show Predefined Policies option.

System policies often execute on events such as OnCollect, OnMove, and OnExport. For example, the OnMove event triggers the Default Move Handler policy, which makes the changes necessary to move an asset from one organization and user to another. If your site has special requirements, it can override certain predefined policies. For example, if you have an asset type that is not suitably exported by CentraSite's Default Export Handler policy, you can develop your own export handler policy to export assets of that type. .