The following sections contain information that you should review if you intend to use CentraSite to govern Web services at run time.
When you use webMethods Mediator as your policy-enforcement point (PEP), your run-time environment consists of four main components: consumer applications, webMethods Mediator, native services and CentraSite.
Basic Components in the Run-Time Environment
| 1 | 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 webMethods Mediator and not directly to the Web service itself. |
| 2 | webMethods Mediator hosts virtual
services, which are proxy services that receive requests from consumer
applications on behalf of a particular Web service. A virtual service enforces
standard policies that you define for your environment (such as security
enforcement and audit-trail logging) and 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 native services, the Mediator also collects performance statistics and event information about the traffic flowing between consumer applications and the native services and reports this data to CentraSite. |
| 3 | Native services are Web services that process requests submitted by consumer applications. If a native service produces a response, it returns the response to the virtual service and the virtual service returns it to the consumer application. |
| 4 | CentraSite serves several key roles in the run-time environment. Besides serving as the system of record for virtual services, run-time policies and related artifacts in the SOA environment, CentraSite provides the tools you use to define virtual services and deploy them to webMethods Mediator. Additionally, CentraSite receives and logs the performance metrics and event data collected by webMethods Mediator and provides tools for viewing this data. |
When you use CentraSite for run-time governance, we suggest that you use a two-stage deployment like the one shown below. Note that with this deployment strategy, each instance of CentraSite has its own webMethods Mediator. This configuration creates an "air gap" between the development and production environments, which completely separates the components that support your production applications and services from those that support development and testing.
Note:
For more information about the two-stage deployment strategy, see
Choosing a Deployment
Strategy.
The creation environment supports the development and testing of run-time policies and virtual services. It is used by the following types of users:
Developers, analysts, or other authorized CentraSite users publish the native services that will be developed and added to the SOA environment.
Policy administrators develop and test the run-time policies that are to be applied to the native services when they are virtualized.
Asset administrators create and test the virtual services that will be used to mediate access to the native services.
After a virtual service has been created and tested on the creation CentraSite, the virtual service, the run-time policies associated with it and the native service that it represents are promoted to the consumption CentraSite.
The consumption CentraSite supports the production environment. Typically, the consumption CentraSite is managed by the Operations or IT organization and only users in this organization are permitted to publish assets to it.
The consumption CentraSite is used by the following types of users:
Developers and analysts access the consumption CentraSite to discover services that are available for reuse. When access to a native service is mediated by a virtual service, users who browse the catalog for re-usable services will see the virtual service, not the native service itself.
Designated administrators from the IT or Operations organization import the virtual services, run-time policies and native services that have been developed and tested in the creation CentraSite. These administrators will also:
Adjust the permissions settings to ensure that these objects can be viewed by the appropriate groups of users (for example, they typically hide native services from developers and analysts who browse the catalog for reusable services and expose only the virtual services to those users).
Deploy virtual services to the Mediator.
Owners of the consumer applications that invoke virtual services access the consumption CentraSite to view the performance metrics and other events relating to the operation of virtual services running in the Mediator.
The following diagram illustrates how the creation and consumption instances of CentraSite interrelate.
| # | Description |
|---|---|
| 1 |
CentraSite. The creation CentraSite supports the development and testing of services and virtual services, and the consumption CentraSite supports services and virtual services that are in production. Typically, both registries have the same basic organizational structure, although they each might each have certain "utility" organizations that are unique to their role as a creation or consumption server. (Note that the two instances of CentraSite are not required to have the same organizational structure. They can have different structures if that approach better suits your needs.) |
| 2 |
Mediator. Each instance of CentraSite has its own Mediator (or Mediators). The Mediator in the creation environment provides a test bed that developers use during the development of virtual services and run-time policies. The Mediator in the consumption CentraSite is used exclusively for hosting virtual services that are in production. |
| 3 |
Native Services. A native service begins its lifecycle on the creation CentraSite. When the service is ready for production, you promote it to the consumption CentraSite. On the consumption CentraSite, the native service is typically hidden from users who browse the catalog looking for services to reuse and is visible only to certain administrators (as a best practice). Note that the catalog entry for a native service includes the endpoint(s) where the service is deployed. As indicated by the figure above, these endpoints evolve as the service moves through development, test and production. The handling of endpoints is discussed in more detail in Managing Endpoints. |
| 4 |
Virtual Services. Like a native service, a virtual service begins its lifecycle on the creation CentraSite. You cannot create a virtual service until the native service it represents is registered in the creation CentraSite and it has been deployed on an endpoint in the network. Typically, one creates a virtual service during the late stages of the development phase or when the native service enters the test phase (in other words, after the service's interface is completely implemented and an instance of the service is deployed and running at a known point in the development environment). After the virtual service has been tested and it is considered ready for production use, it is promoted to the consumption CentraSite and deployed to a production Mediator. |
| 5 |
Run-time Policy. A run-time policy defines a sequence of standard policy-enforcement actions that are to be executed when a virtual service is invoked. Administrators define and test run-time policies on the creation CentraSite. When the policies are considered ready for production use, they are promoted to the consumption CentraSite. Note: |
| 6 |
Consumer Application. A consumer application identifies an application that invokes virtual services. Consumer applications are defined directly on the consumption CentraSite. They are not promoted from the creation CentraSite. (Administrators on the creation CentraSite who define run-time policies will typically define dummy consumers for testing purposes.) Note: |
