CentraSite Documentation : Getting Started with CentraSite : Implementation Concepts : Planning Your Run-Time Environment : Deploying for Run-Time Governance : General Concept of Operations between the Environments
General Concept of Operations between the 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 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:  
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 will typically define dummy consumers for testing purposes.)
Note:  
Technically speaking, a consumer application is represented by an Application asset in the registry. For more information about defining consumer applications, see Identifying the Consumers of Virtual Services.
Copyright © 2005-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback