Run-Time Governance Environment

When you use webMethods Mediator as your policy-enforcement point (PEP) to expose and govern the services at run-time, basic requirements for the run-time environment include the following main components: consumer applications, gateways, webMethods Mediator, native services, and CentraSite.

Consumer Applications: 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, a consumer application submits its request to a Virtual Service on the webMethods Mediator and not directly to the web service itself.

Policy Enforcement Points (Gateways) such as webMethods Mediator: webMethods Mediator is a service mediation and policy enforcement application for web services. The web services can be SOAP-based, REST-based, or OData Web services.

Mediator hosts Virtual Services, which are proxy services that receive requests from consumers on behalf of particular Web services. Mediator can also host Virtual APIs, which are proxy APIs for Web services that have been externalized as Application Programming Interfaces (APIs).

Mediator enforces the run-time governance policies or rules that you define for your Virtual Services (such as security enforcement and audit-trail logging) and handles mediation measures between consumer and provider (such as message transformation and message routing).

Besides serving as an intermediary between consumer applications and native services, Mediator also collects performance statistics and event information about the traffic flowing between consumers and the native services and reports this data to CentraSite.

Mediator is designed for use with CentraSite. The Mediator application is delivered as a package called WmMediator, which runs on webMethods Integration Server. It provides an infrastructure for the run-time governance policies or rules that you define.

Virtual Services or Virtual APIs: You can choose to expose your Web services as Virtual Services (also called as Virtual APIs). When you create a Virtual Service, you also define:

As an alternative to exposing your Web services as Virtual Service, you can instead expose the Web services as Virtual Services, which perform a role similar to Virtual Services. When you virtualize a Service, you also define:

Native Services: A Native Service is a plain Web service that processes the requests submitted by consumers. If a Native Service produces a response, it returns the response to a Virtual Service, and then the Virtual Service returns it to the consumer.

CentraSite Registry Repostiory: The CentraSite Registry Repostiory 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 run-time 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.

To use an instance of CentraSite with Mediator, you must define a run-time gateway that identifies the specific instance of Mediator that you want to use. A run-time gateway is a registry object that represents a particular instance of a policy enforcement point (in this case, an instance of webMethods Mediator). The gateway object specifies the address of the Mediator's deployment endpoint, which is the endpoint that CentraSite uses to interact with Mediator to deploy Virtual Services.

If you use multiple Mediators with an instance of CentraSite, you must create a gateway for each Mediator. To make the Mediators 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 Service to one or more run-time gateways.

Instead of (or in addition to) using webMethods Mediator for mediation and/or policy enforcement, you can use other third-party products with CentraSite. Support for third-party policy-enforcement and run-time 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 .

In addition to using Mediator, you can use webMethods Insight. Insight is an additional monitoring tool from Software AG that you can use with CentraSite. Insight 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.

Create the Virtual Services. A Virtual Service is a service that runs on Mediator and acts as the consumer-facing proxy for a native service that runs elsewhere on the network. You can create Virtual Services for Web services that are SOAP-based, REST-based, or OData services. A Virtual Service provides a layer of abstraction between the service consumer and the service provider and promotes loose coupling by providing independence of location, protocol, and format between the consuming application and the provider service. When a Virtual Service is deployed, consumers access this proxy service instead of the actual Native Service. The Virtual Service forwards the request to the appropriate back-end service and, if it has been configured to do so, performs additional mediation functions such as message transformation, protocol bridging, load balancing, and failover handling.

The figure shows Mediator (the service access intermediary) mediating traffic between consumers and Virtual Services. Mediator provides loose coupling between consumers and providers and is able to identify the consumers who are accessing the provider services by examining the traffic flowing through it.

You create Virtual Services for a Web service (termed as, Virtual Service), REST service (termed as, Virtual REST Service), and OData Service (termed as, Virtual OData Service) in CentraSite Control and CentraSite Business UI, and store them in the CentraSite Registry Repository.

You can create one or more Virtual Services for a single Web service. For example, if you have different authentication or routing requirements for two different sets of consumers, you would create a different Virtual Service for each set of consumers.

Create Run-time Governance Policies for the Virtual Services: A run-time governance policy is a sequence of actions that are carried out by a policy-enforcement point (such as Mediator) when a consumer requests a particular Web service through the policy-enforcement point. The actions in a run-time policy perform activities such as identifying/authenticating consumers, validating digital signatures and capturing performance metrics. You create run-time policies using the CentraSite Control user interface and store them in the CentraSite registry/repository.

Create Consumer Applications: A Consumer Application is an Application asset that consumes (invokes) assets (Service, REST Service, OData Service) at run-time. A consumer application defines the precise consumer identifiers (for example, a list of user names in HTTP headers, a range of IP addresses, and so on) who are allowed to consume Virtual Services and other assets at run-time. Thus the policy enforcement point (such as Mediator) can identify or authenticate the consumers or clients that are requesting access to an asset.

You create Application assets (termed, Consumer Applications) or any other assets, and configure the identification parameters in CentraSite Business UI, and store them in the CentraSite Registry Repository.

Publish (Deploy) Virtual Services and Consumer Applications to Gateways: Publish (Deployment) refers to the process you use to send Virtual Services, Virtual REST Services, and Virtual OData Services to the policy-enforcement points (PEPs) on which they are to be used for run-time governance.