CentraSite Features

The registry refers to the part of CentraSite that manages the set of objects that represent the artifacts in your SOA environment (for example, web services, XML schemas, BPEL processes). The registry also contains supporting objects such as Organizations, Users, Policies, and Taxonomies that CentraSite itself uses to manage and organize the SOA artifacts that are contained in the registry.

It is important to understand that the registry functions as a directory, not a library. That is, it describes the properties of an artifact (for example, name, description, location, contact information, technical specifications, lifecycle disposition), but it does not hold the artifact itself. For example, the registry entry for an XML schema contains information about the XML schema. However, the schema itself resides in a different data store known as the repository.

The CentraSite registry supports the Java API for XML Registries (JAXR). JAXR is a standard API for working with XML registries. The JAXR information model provides a standard way to describe registry content. Its API includes powerful capabilities for describing, classifying, relating, and querying the content of a registry.

In CentraSite, the term catalog refers collectively to the sub-set of the objects in the registry that are assets. Generally speaking, an asset is an object that represents an artifact in your SOA environment, such as a web service, an XML schema, or a BPEL process.

When initially installed, the CentraSite catalog supports the following types of assets:

It also includes support for the types of assets that are published and consumed by products in the webMethods product suite (for example, assets such as CAF Task Types, TN Document Types, and so forth).

However, CentraSite's catalog is completely extensible and can be configured to hold any type of artifact that your organization cares to model. For example, you might want to customize your catalog to include metadata for artifacts such as Java libraries, portlets, and XSLT documents.

Any custom object type that you add to CentraSite is, by default, treated as an asset that is part of the catalog.

Note:

The terms object and asset have very specific meanings within CentraSite. An object is any data object that CentraSite maintains in its registry. An asset is an object that is treated as a member of the catalog. Therefore, all assets are objects, but not all objects are assets.

The repository is the data store in which CentraSite maintains documents and other file-like resources. For example, when you publish an XML schema to CentraSite, CentraSite generates an entry in the registry that describes the schema and then stores the schema document itself in the repository (the registry entry includes a link to this document). By providing both registry and repository capabilities, CentraSite enables you to centrally manage the metadata for an asset as well as the asset itself.

Note:

When an asset in the catalog represents an entry in the repository, the item in the repository is often referred to as the asset file.

CentraSite also uses the repository as the data store for items that it produces and consumes, such as report templates, policy descriptions, and lifecycle models.

The CentraSite registry supports the JAXR information model. Physically, the registry resides in a single XML database that can be accessed using XQuery, UDDI, or JAXR-based client APIs.

A JAXR-based registry is built around a generic, but extensible object called a RegistryObject. The RegistryObject class defines a minimal set of metadata and provides methods that enable an object to be classified and associated with other objects in the registry.

Although the metadata that RegistryObject specifies is very minimal (Name, Description, and Key), it can be dynamically extended to incorporate additional metadata. By extending the RegistryObject, one can model and catalog virtually any type of artifact in an SOA environment.

In general, CentraSite's information model consists of system-related objects that represent the artifacts in your SOA and support the administration and management of the registry.

System-related objects include objects such as organizations, users, groups, roles, taxonomies, policies, and lifecycle models. These type of objects do not appear in the catalog, however, they play a key role in managing its content.

The organization object in particular plays a major role within the registry. Under the registry's information model, any object that is not an organization must be associated with an organization object.

CentraSite is installed with one predefined organization. When the administrator of this organization creates users (which are represented by user objects in the registry), CentraSite automatically associates those user objects with the administrator's organization. Similarly, when those users subsequently create objects in the registry, CentraSite associates those objects with the user's organization.

When users work with CentraSite, they see only the registry objects that belong to their organization. Because organizations restrict users to the portion of the registry that belongs to their organization, they provide a way to, in effect, partition CentraSite into multiple, logical registries.

Note:

When necessary, it is possible to share objects between organizations. Using permissions, one can give a group of users in another organization permission to access a specific data object. Additionally, there are certain types of objects (such as Policies) that can be made globally available to all organizations. In both cases, however, the organization in which the objects were originally created maintains ownership of the shared objects.

Assets refer to registry objects that represent the artifacts in your SOA. As installed, the CentraSite registry supports a set of asset types (Services, Virtual Services, REST Services, Virtual REST Services, OData Services, Virtual OData Services, XML schemas, BPEL processes, and Application Servers). Because these asset types are based on the JAXR extensible RegistryObject, you can customize the amount and type of metadata that CentraSite maintains for each type. You can also create additional asset types as necessary.

In JAXR, relationships are modeled using Association objects. Internally, CentraSite uses these objects extensively to establish relationships between many system-related objects in the registry. For example, Associations are used to relate an organization to its set of registry objects. CentraSite automatically generates and maintains these types of underlying associations when you create or modify system-related objects using CentraSite GUIs or APIs.

Besides the implicit relationships that CentraSite maintains for system-related objects, CentraSite also allows you to explicitly establish relationships between registry objects through the use of relationship attributes. A relationship attribute is part of an object's metadata.

An object can have many relationship attributes reflecting the many types of relationships it has with other objects. For example, a Service asset might include a relationship attribute called Uses, which relates the service to its constituent artifacts (that is, assets that it uses or otherwise depends upon). The same asset might also include a relationship attribute called Used By which relates the service to its dependents.

Relationship attributes can be predefined or ad hoc. Predefined relationship attributes are ones that are part of an asset's type definition. When a relationship attribute is predefined, the attribute is present in all assets of that type. Ad hoc relationships are ones you can create as necessary for an individual instance of an asset.

An organization is a high-level container for the assets and other objects that make up a CentraSite registry. Any object that is not an organization must belong to an organization. You use organizations to partition your registry into autonomous collections of assets that you can administer independently. You can use organizations to arrange your registry around functional lines of business, regional subsidiaries, branches, legal entities, departments, and B2B partners (for example, suppliers, and customers.) You can define parent-child associations between organizations to model the hierarchical structure of entities in your enterprise.

Users are individuals that are known to CentraSite. You assign roles and permissions to users to specify which operations they can perform and which registry objects they can access. You can create groups of users and assign roles and permissions to those groups.

Permissions determine the operations users can perform and the set of objects users can access.

Instance-level permissions grant users or groups access to a specific instance of an object in the registry, a specific folder in the repository, or a specific file in the repository. For example, you would use instance-level permissions to give a user or group the ability to modify a specific asset in the catalog.

Role-based permissions grant roles access to an entire class of objects or give the ability to perform certain operations. For example, you would use role-based permissions to give the role the ability to edit all of an organization's assets.

The following diagram illustrates the relationships between instance-level permissions, role-based permissions, users, groups, and roles:

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.

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.

CentraSite enables you to associate lifecycle models with assets and certain other object types in the registry. A lifecycle model defines a set of states that make up the lifecycle of a particular object type. For example, the lifecycle of a web service in your organization might consist of the Development, Test, Production, Revision, and Retirement states. In addition to defining the states that a particular object type can assume, a lifecycle model specifies who is permitted to transition an object from one state to another. You can also define policies that will execute when specified transitions occur.

CentraSite's lifecycle management feature provides added visibility into your SOA environment by enabling you to capture and report the disposition of the assets in the SOA. Moreover, it provides you with a single point of control from which you can centrally manage the lifecycle process of your computing assets.

The lifecycle-management user interface is not available in CentraSite Community Edition.

Design/change-time policies enable you to define and enforce organizational standards within your registry.

A design/change-time policy defines a series of actions that you associate with a registry event such as the addition, deletion, or modification of an object. When the specified event occurs, CentraSite executes the actions prescribed in the policy.

Among other things, you can use design/change-time policies to:

For example, you might define a policy that performs a series of automated tests when a provider submits a web service to your catalog. The policy would accept the service into the catalog only if the series of tests execute successfully.

Run-time policies define actions that are to be carried out by a policy-enforcement point (PEP) when a consumer requests a particular service through the PEP. The actions in a run-time policy perform activities such as identifying/authenticating consumers, validating digital signatures, logging run-time events, and capturing performance measurements.

You use CentraSite Business UI to define run-time policies, associate them with services, and deploy them on specified PEPs, say Mediator gateways in the run-time environment. You also use CentraSite Control to monitor quality-of-service and other performance metrics for the services to which you have attached run-time policies.

A virtual service functions as public-facing proxy for a web service, REST service, or OData service endpoint. You deploy virtual services on a specific type of policy enforcement point called the webMethods Mediator. Consumers who wish to use a particular web service, for instance, submit their requests to the virtual service on the webMethods Mediator, not to the endpoint where the service is actually hosted. The virtual service receives requests from consumers and routes them to the appropriate service endpoint.

You define and deploy virtual services using CentraSite Business UI. You can attach a policy to a virtual service just as you would a regular web service. Additionally, you can include processing steps in a virtual service to perform activities such as content-based or context-based message routing, load-balancing, failover handling, and message transformation.

CentraSite's versioning capabilities enables you to maintain multiple versions of the same object.

Versioning an object creates a clone of the object. When you version an object, CentraSite copies the source object with all of its attributes and then increments the version number in the cloned target object. Additionally, CentraSite establishes a supersedes relationship between the new version of the object and the old one. Among other things, this relationship enables you to view and manage all versions of an asset.

In CentraSite there are three concepts of consumers.

The first refers to developers who discover assets in the catalog that they want to reuse. Such developers can register to become registered consumers of those assets. You might give registered consumers access to more of the asset's metadata (that is, enable them to view additional profiles) and/or develop processes that notify them when changes occur to an asset that they consume.

The second concept refers specifically to any arbitrary asset that consumes any other asset in the CentraSite registry. This specific type of consumer is for the design-time usage.

The third concept refers specifically to a computer application that consumes (invokes) virtual services at run time. This specific type of consumer is represented in the registry by instances of the Application asset type. Application assets are used by webMethods Mediator to determine from which computer application a request for a virtual service originated.

A consumer application is represented in CentraSite by an application asset. An application asset is an instance of the Application asset type, which is one of the predefined types installed with CentraSite. An application asset defines the precise characteristics by which Mediator can identify messages from a specific consumer application at run time.

CentraSite provides reporting capabilities based on the Business Intelligence Reporting Tools (BIRT) open source reporting system. A standard set of reports is installed with CentraSite. You can define additional reports using the BIRT report designer in Eclipse.

Using the reporting features in CentraSite, you can obtain reports about any object type (or multiple types) in the registry. For example, you might want to create a report that list of all the inactive users in your organization. You might also want a report that provides the change history for a specified service in the catalog. Reports can also include information about files and documents in the repository.

To use an instance of CentraSite with webMethods Mediator, API Portal, or Insight you must define a Mediator gateway, an API Portal gateway, or an Insight gateway that identifies the specific instance of Mediator, API Portal, Insight or other policy enforcement point that you want to use. The gateway instance specifies the address of the deployment endpoint, which is the endpoint that CentraSite uses to interact with Mediator or API Portal to deploy virtual services or virtualized APIs.

Note:

The Impact Analysis feature that was used to easily navigate and visualize the associations between the catalog assets and registry objects, and hence identify the impact when updating or deleting assets in the catalog is deprecated and will be removed in future releases. Instead, you can use the Asset Navigator interface of CentraSite Business UI that helps you to easily navigate and visualize the dependencies between assets for various use cases.

The Asset Navigator provides a graphical representation of relationships between assets based on most common use cases. Several use cases for navigation are provided out of the box to allow for analysis of the runtime deployment landscape, organization structure, or dependencies to or from particular assets. The asset navigator can be extended through saved searches. This feature helps you to:

You can view the information based on the use case requirements. For example, you can visualize the information based on the Global use cases or the Asset Specific use cases. Global use cases includes use cases such as Organization Structure and Runtime Landscape view. The Asset Specific use cases includes use cases such as Asset Dependency, Asset Usage, and so on.

webMethods Mediator collects performance data (for example, average response time, total request count, fault count) for the virtual services that it hosts. It publishes this data to CentraSite at regular intervals. When you install and configure the Mediator, you must specify whether you want it to collect performance data and, if so, how often you want it to publish the data to CentraSite.

In addition to performance metrics, webMethods Mediator can also log event data. Event data supplies information about activities or conditions that occur on Mediator.

Mediator logs two basic kinds of events: data relating to the operation of Mediator itself and data relating to the execution of virtual services.

Access to CentraSite is restricted to authorized users who are authenticated through an external directory system such as an Active Directory Server (ADS). Access to objects in the CentraSite registry is controlled by both coarse-grained permissions (through the use of roles) and fine-grain view, edit, or delete permissions on individual object instances. CentraSite also maintains a complete audit trail of the operations that users perform on the individual objects in the registry.

Role-based access provides coarse-grained access control to features and objects in CentraSite. A role is a set of system-level permissions that you associate with a user account or a group of users. The permissions within a role determine which types of objects (for example, Organizations, Policies, Lifecycle Models) users in that role can create. They also specify whether a user is allowed to perform certain restricted actions (for example, View System Audit Log).

The role(s) to which a user belongs determines which screens and controls that user receives in the CentraSite user interface. With respect to API access (based on JAXR or UDDI), the role(s) associated with the client program's user account determine which methods or operations the program is allowed to perform.

CentraSite is installed with a number of predefined roles. For example, users that belong to the Policy Admin role are permitted to create and manage design/change-time policies. However, you can also create custom roles if you require a specific combination of permissions that is not supplied by the predefined roles.