CentraSite 10.5 | CentraSite User’s Guide | Runtime Governance | Introduction to Runtime Governance | Runtime Governance Deployment Architecture
 
Runtime Governance Deployment Architecture
 
Enabling CentraSite Run-Time Aspects
Disabling CentraSite Run-Time Aspects
When you use CentraSite for run-time governance, Software AG recommends that you use a two-stage deployment as shown in the following diagram. With this deployment strategy, each instance of CentraSite has a set of runtime gateways . 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.
Creation Run-time environment
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 are 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 are 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.
Consumption Run-time environment
The Consumption CentraSite supports the production environment. Typically, 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 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 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.
Operations between the Creation and Consumption Environments
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 might each have certain utility organizations that are unique to their role as a creation or consumption server. (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).
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.
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:
Before you deploy a virtual service to the Mediator in the consumption environment, it is important to ensure that all the run-time policies that apply to the virtual service have been promoted to the consumption CentraSite.
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 typically define dummy consumers for testing purposes.)
Note:
A consumer application is represented by an Application asset in the registry.