CentraSite 10.7 | CentraSite User’s Guide | Runtime Governance | Introduction to Runtime Governance | The Components of Runtime Governance
 
The Components of Runtime Governance
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.
Native Service
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.
Virtual Service
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:
*Move native services to other physical addresses or switch providers without affecting existing consumer applications.
*Bridge differences (for example, transport differences, message structure differences) between the capabilities of a consuming application and the requirements of a native service.
*Block portions of a service interface from certain consuming applications (that is, expose selected portions of the native service to certain consumers).
*Provide access to different versions of a service through a single endpoint.
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:
*Policy enforcement rules
*API keys and OAuth2 client credentials
When you choose to expose a Web service as virtual service, you need to:
1. Create the Virtual Service asset
2. Configure governance rules for the virtual service
3. Create consumer applications to consume the virtual service at run-time
4. Deploy virtual service and consumer applications to a runtime gateway
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.
Runtime Policy
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.
Note: 
*Creation and configuration of run-time policies from CentraSite is disabled by default. However, you can enable it by modifying the centrasite.xml file and setting the RuntimeComponentSetting element's enabled attribute to true.
*Creation and configuration of run-time policies is now dealt within API Gateway.
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.
Runtime Gateway
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:
*webMethods API Gateway
*webMethods Mediator
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.
Note:
In addition to using webMethods API Gateway or webMethods Mediator, you can use webMethods Insight. Insight Server is an additional monitoring tool from Software AG that you can use with CentraSite. Insight Server enables you to see what is happening in real-time with service transactions as they flow across any system. It provides visibility and control at the transaction level to heterogeneous SOA environments. CentraSite provides support for Insight as a gateway type out-of-the-box. For more information about Insight's uses and capabilities, see the Insight user documentation.
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.
Consumer Application
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:
*Indicate the consumer application to which a logged transaction event belongs.
*Monitor a virtual service for violations of a service-level agreement (SLA) for a specified consumer application.
*Control access to a virtual service at run-time (that is, allow only authorized consumer applications to invoke a virtual service).
For more information on defining consumer applications and configuring identifiers for the consumer authentication, see Consumer Management.
CentraSite Registry Repository
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.
Runtime Events and Metrics
A Runtime Event is an event that occurs while virtual services are actively deployed on the runtime gateway.
Examples of runtime events include:
*Successful or unsuccessful requests/responses.
*Policy violation events, which are generated upon violation of virtual service's runtime policy.
*Service monitoring events, which are generated by the service-monitoring actions in the runtime policy.
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.