This document introduces the following CentraSite features:
The registry refers to the part of CentraSite that manages the set of objects that represent the artifacts in your SOA environment (e.g., 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 (e.g., 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:
Services
Virtual Services
XML Schemas
BPEL Processes
Application
Application Servers
It also includes support for the types of assets that are published and consumed by products in the webMethods product suite (e.g., 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. For information about configuring CentraSite to store metadata for custom asset types, see the document Object Type Management.
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 as described above. 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 will include 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. Additionally, the repository houses an organization's supporting document library. This library contains documents that an organization can arbitrarily attach to objects in the registry. For example, you might upload documents such as technical specifications, sample code and programming guides to the supporting document library, and then link these documents to various assets in the catalog. For more information about uploading documents to the supporting document library, see the section Working with Supporting Documents in the document Using the Asset Catalog.
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:
Initiate review and approval processes at specified points during the lifecycle of a registry object.
Validate metadata that users submit to the registry to ensure that it conforms to organizational standards and conventions.
Perform automated testing and quality checks.
Issue notifications to specified groups or individuals.
Trigger updates or other types of procedures on external systems.
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.
Note:
Design/change-time policies are not available in the CentraSite
Community Edition.
For more information about creating design/change-time policies, see the document Working with Design/Change-Time Policies.
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 Control to define run-time policies, associate them with services, and deploy them on specified PEPs 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.
Note:
Run-time policies are not available in the CentraSite Community
Edition.
Note:
.
For more information about creating run-time policies, see the document Working with Run-Time Policies.
A virtual service functions as public-facing proxy for a Web service or XML 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 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 Control. 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.
Note:
Virtual services are not available in the CentraSite Community
Edition.
For more information about defining virtual services, see the document Working with Virtualized Services .
SOALink is a framework that enables interoperability between CentraSite and various SOA infrastructure components that participate in the SOA lifecycle. SOALink consists of a set of standards, APIs and extension points supported by CentraSite.
SOALink leverages standards such as UDDI, SNMP, WS-Policy and WS-PolicyAttachment as the building blocks for the interface. In cases where a particular standard does not exist or is inadequate, SOALink defines a set of extensions to existing standards.
You can use the capabilities provided by SOALink to integrate CentraSite with third-party design-time tools and policy enforcement points.
Note:
SOALink is not available in the CentraSite Community
Edition.
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 the CentraSite Community Edition.
For more information about defining lifecycle models, see the document Customizing Lifecycle Management.
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. Or you might 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.
For more information about the reporting capabilities in CentraSite, see the document Working with Reports and Report Templates.
Impact analysis refers to the ability to evaluate the effect of a proposed change on an existing system. In an SOA environment, where reuse is encouraged and assets often have numerous dependants, the ability to understand the consequences of a change is crucial.
CentraSite enables you to represent the relationships among the objects in your registry using customizable relationship attributes and ad hoc associations. For example, in an asset type that represents a consumer application, you might include a relationship attribute that allows developers to relate consumer applications to the Web services that they consume.
If an asset's relationships have been described using relationship attributes or ad hoc associations, they can be visualized using CentraSite's impact analysis feature. This feature summarizes an asset's relationships in a concise, browsable diagram. Using this display, you can easily locate and examine the objects to which an asset is related and evaluate how change to the asset might affect them.
For more information about defining relationships among assets see the document Object Type Management. For more information about viewing the Impact Analysis profile, see the document Using the Asset Catalog.
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/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.
For information about permissions and user management, see the document User, Groups, Roles and Permissions.
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 (e.g., Organizations, Policies, Lifecycle Models) users in that role can create. They also specify whether a user is allowed to perform certain restricted actions (e.g., 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. For more information about roles, see the document User, Groups, Roles and Permissions.
CentraSite's federation capabilities enable you to automatically synchronize the contents of other CentraSite or UDDI registries with your CentraSite registry. Federation is accomplished by configuring CentraSite to automatically replicate certain types of entries in its registry to other registries within your network or to mirror entries from other registries into your CentraSite registry.
CentraSite includes these graphical user interfaces (GUIs):
CentraSite Control is a browser-based user interface that supplies access to all of CentraSite's features. Administrators use CentraSite Control to perform administrative activities such as managing organizations, users, groups and roles. Developers and analysts use CentraSite Control to browse the asset catalog, publish assets into the SOA, define policies, deploy run-time policies and virtual services, generate reports and monitor the performance of services in the run-time environment.
The Business User Interface is a browser-based interface that offers a business-level view of the CentraSite registry. Business users use this interface to browse the asset catalog, publish assets into the SOA and generate reports.
The CentraSite Eclipse user interface is a plug-in for the Eclipse Integrated Development Environment (IDE). This interface enables developers to easily discover and publish assets directly from their Eclipse development environment. It also permits developers to use drag-and-drop techniques to incorporate assets from the CentraSite registry into development projects in Eclipse. (Certain administrative operations can also be performed using the Eclipse plug-in.)
Programmatic access to CentraSite is provided through a number of APIs and protocols, including JAXR and UDDI. For a list of the supported APIs and protocols, see the section Ways to Interact with CentraSite in the document Logging On and Using the CentraSite UIs and APIs .
