When you use CentraSite to govern Web services at run-time, the basic components in the run-time environment include the following - native services, virtual services, runtime policies, runtime gateways, consumer applications, CentraSite registry repository, and the runtime events and metrics.

A Native Service is a plain Web service that processes the requests submitted by consumers. When a native Web service produces a response, CentraSite returns the response to a virtual service, and then the virtual service returns it to the consumer.

You use CentraSite to define Web services of the type - SOAP Service, REST Service, and OData Service.

For more information on defining and managing Web service assets, see Managing Assets through CentraSite Business UI.

A Virtual Service, also called as Virtual Alias, Virtual API, is a service that runs on a runtime gateway and acts as the consumer-facing proxy for a Web service that runs elsewhere on the network. It provides a layer of abstraction between the service consumer and the service provider, and promotes loose coupling by providing location, protocol, and format independence between the consuming application and the provider service. You can choose to expose any kind of a native Web service as virtual service, which performs a role similar to the native service.

For example, virtual services enable you to:

You use CentraSite to define proxy services of the type - Virtual SOAP Service, Virtual REST Service, and Virtual OData Service, and to deploy them on specified runtime gateways.

When you define a virtual service in CentraSite, you also define the following criteria, which enables users to securely access the virtual service:

When you choose to expose a Web service as virtual service, you need to:

After you deploy a virtual service, you use CentraSite as a dashboard to view the performance metrics and other runtime data relating to its usage.

For more information on defining and deploying virtual service assets, see Virtual Service Asset Management.

A Runtime Policy, also called as governance rules, defines a set of policy actions that are to be carried out by a runtime gateway when a consumer requests access to a particular Web service through the gateway. The actions in a runtime policy perform activities such as identifying and authenticating consumers, validating digital signatures, logging run-time events, and capturing performance measurements.

You use CentraSite to define runtime policies with the required sequence of actions and configuration parameters, associate them with virtual services, and deploy them on specified gateways in the runtime environment. You also use CentraSite to monitor quality-of-service and other performance metrics for the services to which you have attached runtime policies.

For more information on defining global policies, see Run-Time Policy Management.

For more information on defining policies for a particular virtual service, see Virtual Service Asset Management.

A Runtime Gateway, also called as Policy-Enforcement Point (PEP), hosts virtual services, which are proxy services that receive requests from consumer applications on behalf of a particular Web service.

A runtime gateway is a registry object that represents a particular instance of a policy enforcement point (for example, an instance of API Gateway or Mediator). The gateway object specifies the address of the deployment endpoint, which is the endpoint that CentraSite uses to interact with gateway to deploy the virtual services.

The gateway handles mediation measures between consumer and provider such as protocol bridging, message transformation, and message routing. Besides serving as an intermediary between consumer applications and Web services, the gateway also collects performance statistics and event information about the traffic flowing between consumer applications and the Web services and reports this data to CentraSite.

CentraSite supports the following runtime gateways:

To use an instance of CentraSite with an instance of webMethods API Gateway or webMethods Mediator, you must define a Gateway asset that identifies the specific instance of API Gateway or Mediator you want to use.

If you use multiple gateways with an instance of CentraSite, you must create a Gateway asset instance for each gateway. To make the gateways easier to distinguish when they are viewed in CentraSite, consider adopting a naming convention for gateways that clearly identifies to which environment the gateway belongs (for example, development, test, production). You can deploy any given virtual services to one or more gateways.

Instead of (or in addition to) using the above runtime gateways for mediation and/or policy enforcement, you can use other third-party products with CentraSite. Support for third-party policy-enforcement and runtime governance tools is available through integrations that are provided by members of the CentraSite Community. These tools are made available through the Software AG TECHcommunity Website .

For more information on defining and registering runtime gateways with CentraSite, see Gateway Management.

A Consumer Application is represented in CentraSite by an Application asset. Application assets are used by the runtime gateway to determine from which consumer application a request for an asset originated. An application asset defines the precise characteristics (for example, a list of user names in HTTP headers, a range of IP addresses, and so on) by which the gateway can identify and authenticate messages from a specific consumer application and enable consumer access to a protected Web service at run-time. Consumer applications submit requests for operations that are provided by Web services that reside on various systems in the network. As shown in the figure above, a consumer application submits its request to a virtual service on the gateway and not directly to the Web service itself.

The ability of runtime gateway to relate a message to a specific consumer application enables the gateway to:

For more information on defining consumer applications and configuring identifiers for the consumer authentication, see Consumer Management.

The CentraSite Registry Repository (CRR) serves several key roles in the run-time environment. Besides serving as the system of record for the artifacts in the SOA environment (such as Virtual Services and their runtime governance policies), CentraSite provides the tools you use to define these artifacts and deploy them to Mediator. Additionally, CentraSite receives the performance metrics and event data collected by Mediator and provides tools for viewing this data.

A Runtime Event is an event that occurs while virtual services are actively deployed on the runtime gateway.

Examples of runtime events include:

Runtime Metrics, also called as KPI metrics, are used to monitor the runtime execution of virtual services. Metrics include the maximum response time, average response time, fault count, availability of virtual services, and more. If you include runtime monitoring actions in your runtime policies, the actions will monitor the KPI metrics for virtual services, and can send alerts to various destinations when user-specified performance conditions for a virtual service are violated.

The runtime events and KPI metrics are collected by the gateway and published to CentraSite via SNMP.

The gateway publishes the following types of runtime events - Lifecycle, Error, Policy Violation, Transaction, and Monitoring.

For the Monitoring event type, gateway publishes the following types of KPI metrics - Availability, Average Response Time, Fault Count, Maximum Response Time, Minimum Response Time, Successful Request Count, and Total Request Count.

For more information on configuring events and metrics logging, see Runtime Events and Key Performance Indicator (KPI) Metrics.