# | 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 | API Gateway: Each instance of CentraSite has its own API Gateway (or API Gateways). The API Gateway in the creation environment provides a test bed that developers use during the development of virtual services and run-time policies. The API Gateway 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 API Gateway. |
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 API Gateway 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. |