CentraSite's flexible and extensible registry structure enables you to model any kind of asset that you might want to include in your asset catalog. It supports a rich set of attribute types for defining the different properties and qualities of your assets. These types include attributes that you can use to classify an asset according to a predefined or custom taxonomy and attributes that you can use to associate the asset with other objects in the registry.

The three major aspects of your catalog that you can customize are: types, taxonomies, and associations.

A type (also called an object type) describes a kind of object that the registry can store. Besides defining the set of attributes that make up an object, a type includes several system properties that determine, among other things, whether objects of the type are visible in the user interface, whether objects of the type can be used with reports and policies, and whether they can be versioned.

CentraSite includes many predefined types. You can customize many of these predefined types and also create custom types of your own.

All items stored in the CentraSite registry are objects of a particular type. Users, policies, and taxonomies are examples of objects that are stored in the registry. An asset is a specific kind of object that represents an artifact in your SOA environment such as a Web service, a REST service, XML schema or a business process. In other words, all assets are objects, but not all objects are assets.

The asset catalog represents the set of all objects in your registry that are assets. Many features within CentraSite operate specifically on the contents of the asset catalog.

Any custom type that you add to CentraSite is considered to be an asset type. Consequently, all instances of a custom type are treated as assets.

CentraSite is installed with a number of predefined asset types, including types that represent Web services, REST services, OData services, XML schemas and BPEL processes. Before using these types in your environment, you should examine their type definitions and customize them as necessary.

With respect to customizing the predefined asset types installed with CentraSite, you can:

Besides customizing the predefined asset types that are installed with CentraSite, you can also define custom types of your own. For example, if you wanted to include items such as service requests, IT projects, and source code libraries in your registry, you would create a custom type for each of these entities.

Before creating a custom type, you must first decide which aspects of an entity you want to model in the registry. If you were creating a type to represent IT projects, for example, you might want to capture characteristics such as the name of the project requester, the lines of business the project is expected to affect, the project plan, the project manager and the project's expected completion date. After you decide which specific characteristics and qualities you want to model, you can create a custom type that includes a corresponding attribute for each of those characteristics or qualities.

An attribute holds data about an asset. All asset types include a basic set of attributes for general information such as the asset's name, description, creation date, and owner. You define additional attributes to hold data that is specific to the type of asset that you want to store in the registry.

When you define an attribute, you specify:

Besides basic data types such as String, Number, and Boolean, CentraSite supports the following special types:

The inclusion of these attribute types facilitate many of the advanced features in CentraSite. It is a good idea to make use of them whenever possible.

Rather than using a String attribute to identify the project manager in this type, you could use a Relationship attribute instead. A Relationship attribute not only identifies the individual who is serving as the project manager, but also provides the additional benefit of enabling users to obtain detailed information about the project manager (because the attribute itself will link users to the actual User object for that individual).

A profile defines a collection of attributes that are meant to be grouped together for presentation purposes.

When you define a new asset type, you specify on which profiles the type's attributes are to be displayed.

All asset types include several generic profiles. Among others, these include:

The information on the generic profiles is generated by CentraSite. You cannot customize the content of these profiles or add attributes to them. You can, however, select the profiles you want CentraSite to include when it displays an asset of a defined type.

To display the attributes that you define for an asset type, you create custom profiles and assign the attributes to them. CentraSite does not require an attribute to be assigned to a profile. However, if you do not assign an attribute to a profile, the attribute is not be visible in the user interface. You can assign an attribute to multiple profiles if you want it to appear on multiple profiles (tabs) in the user interface.

The CentraSite Business UI user interface enables users to add assets to the registry in the following ways:

CentraSite includes importers for the following types of assets:

If you want your users to be able to generate an instance of a custom asset type from an input file, you must build a custom importer and register it in CentraSite. You can find information about developing a custom importer in the CentraSite Administrator’s Guide.

A taxonomy is a hierarchical classification scheme. In CentraSite, you use taxonomies to classify objects in the registry. Taxonomies enable you to filter, group and sort the contents of the registry.

A taxonomy consists of a name and zero or more categories. A category represents a classification within the taxonomy. A category can have multiple levels of sub-categories.

When users publish assets to CentraSite, they can classify the assets in two ways:

Classified assets are easier for users to locate because CentraSite includes convenient tools for filtering, reporting, and querying the registry by taxonomy.

Design/change-time policies execute when events within the policy's scope occur in the registry. The scope of a policy specifies to which type of registry objects the policy applies (for example, Service objects, Policy objects, User objects) and during which types of events the policy is triggered (for example, a PreCreate event, a PostCreate event, a PreStateChange event).

Classifying assets can help you create highly targeted design/change-time policies, because the scope of a policy can be additionally constrained to objects that are classified in a specified way. For example, instead of applying a particular policy to all Application Server assets, you might want to restrict the policy to just the Application Server assets that are classified by the APAC category from the Domains taxonomy.

When you define a custom asset type, think about whether you want to apply different design/change-time policies to specific subsets of that type. If so, make sure the asset type includes a Classification attribute that can be used to distinguish those subsets. (Consider making this a required attribute to ensure that you do not forget to classify assets of this type.)

Like types, taxonomies are system-wide objects, which means that they apply to all organizations (that is, all organizations have access to the same global set of taxonomies). You cannot restrict a taxonomy to a specific organization.

Taxonomies are also visible to all users. You can give specific user's Modify or Full instance-level permissions on taxonomies, but you cannot revoke a user's View permission. All users (including guest users) can view the taxonomies defined within an instance of CentraSite.

CentraSite installs a number of standard taxonomies that you can use to classify assets.

These include:

CentraSite also includes a number of special-purpose taxonomies that it uses for its own internal classification of registry objects.

You cannot delete any of the predefined taxonomies installed with CentraSite or modify their category structure. You can, however, modify certain attributes and properties for these taxonomies. Additionally, you can suppress them in the user interface. For example, if your users will never use the NAICS taxonomies that CentraSite provides, you can remove these taxonomies from the user interface.

In addition to using the taxonomies that CentraSite provides, you can create your own custom taxonomies.

When you include a Classification attribute in a type, you usually need to create a corresponding taxonomy for the attribute (unless the required taxonomy already exists in the CentraSite registry). For example, let's say you decide that you want to classify your Application Server assets according to the domain in which they reside. To do this you would first create a custom taxonomy that identifies the various domains in your environment. Then, after the taxonomy exists, you would customize the Application Server asset type and add a Classification attribute to it that enables users to classify application server assets by the Domain taxonomy.

An association type describes a type of relationship that can exist between objects in the registry.

An association type has a name, a forward label (which describes the relationship of the source object to a target object) and an optional reverse label (which describes the relationship of the target object to the source object).

You use association types to define Relationship attributes in an asset type. In the following example, a Relationship attribute called Managed By has been included in the Project asset type to associate a project asset with the user that manages the project.

When users publish assets to the registry, there are two ways in which they can relate an asset with other objects in the registry.

CentraSite's Asset Navigator feature helps to visualize the dependencies between assets. Users can determine the dependent assets using the Asset Dependency usecase.

When you include Relationship attributes in an asset type, you not only enable users to specify the objects to which an asset is related, you enable the relationships to be discovered and reported by the Asset Navigator feature.

CentraSite provides numerous predefined association types for you to use to create Relationship attributes. However, you can also create custom association types as needed.

Like types and taxonomies, association types are system-wide objects. They apply to all organizations defined in the registry (that is, all organizations within an instance of CentraSite have access to the same global set of association types). You cannot restrict the use of an association type to a specific organization.

If you are working in a multi-stage environment, it is important to master your custom asset types, taxonomies, and association types on one stage and then promote them to the other stages. Do not attempt to manually define these objects in each stage. Doing this will create objects that are equivalent, but not identical. That is, the objects will have the same attributes, but they will not have the same Universally Unique Identifier (UUID). It is the UUID that uniquely distinguishes an object in the registry.

When objects are imported into CentraSite (either through an import process or a promotion process), CentraSite uses the UUID to determine whether an object that you are importing already exists on the target instance of CentraSite. If the UUID does not already exist, CentraSite adds the imported object to the registry. If an object with the same UUID exists in the target registry, and the object that you are importing has a more recent timestamp than it, CentraSite automatically replaces the object in the target registry with the one that you are importing.

When you promote an asset from one stage to another, CentraSite also promotes the asset's type and the taxonomies that it uses. If you have manually defined these objects on the target instance of CentraSite, they will be duplicated, instead of replaced, during the promotion process. This will create a confusing situation wherein you have two instances of the same asset type and/or taxonomy on the target instance of CentraSite.

To avoid this condition, always create your custom asset types, taxonomies, and association types on the first stage of a multi-stage deployment and export those objects to the registries that host the subsequent stages of the lifecycle.

CentraSite provides many ways for you to customize the asset catalog. After you install CentraSite, you should customize the predefined asset types provided by CentraSite (if necessary) and create new types, taxonomies and association types as required for your site.

When customizing the catalog for your site, keep the following points in mind: