CentraSite's flexible and extensible registry structure enables you to model virtually 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.
This section describes the three major aspects of your catalog that you can customize: 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/or 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.
Note:
Types are system-wide objects, meaning that they apply to all
organizations. Consequently, all organizations within a particular instance of
CentraSite use (or have access to) the same global set of
types.
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, an 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, 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:
Add attributes to the type
Move certain attributes from one profile to another
Specify which profiles are to be displayed for the type
Change the type's system-property settings (for example, specify whether the type supports versioning or can be used with design/change-time policies)
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.
Note:
Before creating a custom type, always check to see whether
CentraSite provides a predefined type that you might be able to customize and
use. Customizing one of CentraSite's predefined types will save you time,
especially if the type requires a file importer.
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 requestor, 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:
The type of data that the attribute will hold (e.g., String, Number, Boolean)
Whether the attribute will hold a single value or multiple values (i.e., an array)
Whether an attribute is required or optional
Whether the attribute is read-only
Besides basic data types such as String, Number and Boolean, CentraSite supports the following special types:
| Attribute Type | Description |
|---|---|
| Classification | This type enables users to classify an asset according to a specified taxonomy. |
| Relationship | This type enables users to establish an association between an asset and another object in the registry. |
| File | This type enables users to link an asset to a file that resides in CentraSite's repository or exists at a URL-addressable location on the network. |
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.
For example, let's say you were creating the Project asset type described earlier in this section. Rather than using a String attribute to identify the project manager in this type, you could use a Relationship attribute instead. A Relationship attribute will not only identify the individual who is serving as the project manager, it will also provide the additional benefits of 1) 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), and 2) allowing the relationship to be discovered and reported by CentraSite's Impact Analysis feature. For example, one could use the Impact Analysis feature to locate all of the projects managed by a particular individual.
A profile defines a collection of attributes that are meant to be grouped together for presentation purposes.
The attributes associated with a profile are displayed on individual tabs in CentraSite Control
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:
Audit Log profile—Displays the history of changes to the asset (including changes in an asset's lifecycle state).
Consumers profile—Displays the users and/or applications that are registered consumers of an asset.
Permissions profile—Displays instance-level permissions for an asset.
Classifications profile—Displays an asset's classifiers.
Associations profile—Lists the registry objects to which the asset is related.
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 which of these 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 will 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.
Note:
If you want to provide different views of an asset to different
users or groups, divide the attributes among profiles in a way that enables you
to use profile permissions to selectively show or hide the appropriate set of
attributes to different users or groups.
The CentraSite Control user interface enables users to add assets to the registry in the following ways:
Users can create an asset "from scratch", meaning that they manually assign values to the asset's attributes in the CentraSite Control user interface.
Users can import an asset from an archive file (a file that contains objects that have been exported from an instance of CentraSite).
Users can import the asset from an input file. To add an asset in this way, CentraSite must be configured with an "importer" that can read the input file and generate an instance of the specified asset type from it.
CentraSite includes importers for the following types of assets:
| Type of Asset | Required Input File |
|---|---|
| Web Service | Web Services Description Language (WSDL) file |
| XML Schema | XML Schema Definition (XSD) file |
| Business Process | Business Process Execution Language (BPEL) file |
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 SOALink Cookbook.
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:
By directly assigning values to an asset's Classification attributes. If an asset's type includes one or more Classification attributes, users can classify the asset by simply setting these attributes.
By assigning ad-hoc classifiers to an asset's Classifications profile. This profile enables users to classify an asset by any available taxonomy defined in CentraSite. It allows users to assign classifiers to an asset in cases where the asset itself does not include any explicit Classification attributes or does not include the needed type of Classification attribute.
Classified assets are easier for users to locate because CentraSite includes convenient tools for filtering, reporting and querying the registry by taxonomy. For example, the Browse page in CentraSite Control enables users to browse the asset catalog according to a specified taxonomy. Additionally, the advanced search feature in CentraSite Control enables users to query the registry for assets that are classified a particular way. By classifying assets, you enable users to discover them using these tools.
Note:
If you want users to be able to browse the asset catalog by a
taxonomy, you must enable the taxonomy's "Taxonomy is
browsable" property. If this property is not enabled, it will not
appear in the catalog browser's Browse by drop-down list.
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 (e.g., Service objects, Policy objects, User objects) and during which types of events the policy is triggered (e.g., 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 will need 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 users do not forget to classify assets of this type.)
Like types, taxonomies are system-wide objects, meaning that they apply to all organizations (i.e., 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 users 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:
ISO 3166 Country Codes
North American Industry Classification System 2002 (NAICS)
ThomasNet Supplier Registry
Product and Service Category System: United Nations Standard Products and Services Code (UNSPSC)
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.
You Use Association Types to Define Relationship Attributes in Object Types
When users publish assets to the registry, there are two ways in which they can relate an asset with other objects in the registry.
By establishing the relationship using an asset's Relationship attributes. If an asset's type includes one or more Relationship attributes, users can relate an asset to other objects in the registry by simply setting these attributes.
By establishing an ad-hoc association using the asset's Associations profile. If an asset's type includes the Associations profile, users can relate assets of that type with other objects on an "ad hoc" basis. Using this profile, users can relate an asset to virtually any other object in the registry (assuming they have view permission on the target object).
CentraSite's Impact Analysis feature reports the associations that exist among objects in the registry. By viewing an Impact Analysis report for an asset (either in graphical or tabular form), users can quickly determine to which objects the asset is related.
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 Impact Analysis 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 (i.e., 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.
Important:
Because the import process uses timestamps to determine whether
an object in an archive file is more recent than the one that exists in the
target registry, it is important that the system clocks on all of the
participating stages are synchronized.
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.
Note:
Association types that the asset uses are not automatically exported
with an asset. If the asset uses custom association types, you must export the
association types separately and import them on the other stage(s) before you
import the asset itself.
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.
Note:
Although you should do the initial customization after CentraSite
is installed, you can always add additional asset types, taxonomies and
association types as you develop the need for them.
When customizing the catalog for your site, keep the following points in mind:
You can customize any of the predefined asset types installed with CentraSite by adding attributes to them and/or modifying the content and organization of the profiles associated with the type.
If you have an asset that is not represented by one of the predefined types provided by CentraSite, you must create a custom asset type for it. If you want users to be able to generate the asset type from an input file, you must also create a custom importer for that type and register the importer in CentraSite.
Consider using Classification attributes and Relationship attributes instead of ordinary String attributes whenever possible. Among other benefits, these attribute types enable users to more easily discover assets and understand the relationships that an asset has with other objects in the registry.
In general, use a Classification attribute or an enumerated String instead of an ordinary String attribute when you want the attribute to be more strongly typed.
Instead of defining multiple asset types to represent variants of the same basic type, consider creating one basic type and using a classification attribute to differentiate them. For example, instead of creating separate asset types for different kinds of Web services (e.g., business services, technical services, security services), use the one basic Web service asset type and use a Classification attribute to classify its variations.
When you are designing a new asset type, think about the design/change-time polices that you might want to apply to assets of that type. If you need to apply different policies to different sub-sets of the asset type, use a Classification attribute to differentiate the sub-sets.
If you do not want users to be able to assign ad hoc classifiers and/or associations to instances of a particular type of asset, omit the Classifications and/or Associations profiles from that asset's type.
If a taxonomy is designed to be used with specific types of assets, specify those types in the taxonomy's Applicable to Object Types tab. This will prevent users from using the taxonomy to classify objects with which the taxonomy was not intended to be used.
You can define taxonomies with multiple levels of sub-categories to create very fine-grain levels of classification. When you do this, users can search for assets that are classified by a specific category or any of its sub-categories. For example, the "Service Type" taxonomy shown in the figure below would enable users to locate a specific type of technical service (e.g. a Utility or a Network service) or all "technical services" (i.e., all services that are classified by the Technical Services category or by any of its sub-categories).
If you are working in a multi-stage environment, always master your custom asset types, taxonomies and association types on one stage and export them to the other stages. Do not attempt to define these objects manually on each stage.
