A Virtual Service runs on runtime gateway and acts as the consumer-facing proxy for a service that runs elsewhere on the network. You can create a Virtual Service asset for the SOAP, REST, and OData Web services. A Virtual Service provides a layer of abstraction between the service consumer and the service provider, and promotes loose coupling by providing location, protocol, and format independence between the consuming application and the provider service.

For example, Virtual Services enable you to:

You use CentraSite to define Virtual Services and to deploy them on specified runtime gateways. After you deploy a Virtual Service, you use CentraSite as a dashboard from which to view performance metrics and other run-time data relating to the usage of a Virtual Service.

Although it is possible to virtualize any native service that is registered in CentraSite, you will generally virtualize only certain types of services. The use of virtual services creates an additional hop in the execution path and also consumes resources from an execution perspective. It is generally not practical (or beneficial) to virtualize every native service in your environment. With respect to virtualization, you want to strike a balance between the need to provide an SOA infrastructure that is flexible and extensible with the need to maintain a manageable infrastructure that is not overly complex.

Broadly speaking, there are three types of services you should consider virtualizing:

As shown in the following diagram, one approach to virtualization is to think of your services in terms of business services and technical services and to virtualize those services that are business services:

A shared service is a service that is used by multiple functional domains within an enterprise. For example, consumers in the CRM area, the Sales and Marketing area and the Risk Management area might each need access to customer data. Instead of giving these systems direct access to the data service for the customer database, you virtualize the service and give these consumers access to the virtual service (or virtual services). Virtualizing the service gives you greater control over the interface that is exposed to these consumers, enables you to accommodate differences among the consumers by applying different run-time policies and/or processing steps to them and also gives you the flexibility to make modifications to the native service without impacting existing consumers.

Any service that is provided by an entity outside of the enterprise or is consumed by an entity outside of the organization should be virtualized. For example, if you have an outside service that provides sales forecasts for your industry, virtualizing this service would enable you to:

Similarly, you should virtualize any service that your organization offers to applications that execute outside the enterprise (for example, an inventory control service that you extend to suppliers and/or distributors).

A virtual service is a Web service that runs on webMethods API Gateway. You use CentraSite to create, edit, publish, and manage virtual services. Virtual services have the following major elements:

Before you can create and deploy Virtual Services on your instance of CentraSite, there are two important configuration steps that you must perform.

Before you can deploy virtual services, you must define gateways to represent the API Gateways that are attached to your instance of CentraSite. For example, if you will be deploying virtual services to two different API Gateways, you must create two gateway objects, one for each API Gateway instance.

A virtual service is a specialized form of a Service asset type. Because virtual services are actually service objects, a lifecycle model that applies to services applies to virtual services as well. Yet a virtual service and a native service have distinctly different lifecycles. To accommodate this difference, you must create a lifecycle model that defines two separate lifecycle paths.

The following diagram shows a simple lifecycle model that supports both types of services. Note that this lifecycle has a path for native services and a path for virtual services. Policies are used to switch native services and virtual services to the appropriate path.

In the following example, the Proposed state is the lifecycle model's initial state. When a native service is created, it enters the Proposed state and from there, it follows the lifecycle path for native services. After a native service is tested and it is ready to be promoted for production, a virtual service is generated for it. The virtual service initially enters the Proposed state when it is created. However, a design/change-time policy immediately switches the virtual service to the lifecycle path for virtual services.

To create a lifecycle model that supports both native services and virtual services, you must perform the general steps described below.

The virtual service's Deployment profile contains the controls that you use to deploy, undeploy and redeploy the virtual service. When the Deployment profile is disabled, you cannot perform these operations on the virtual service.

By default, the Deployment profile is disabled when you create a virtual service. This is to prevent anyone from deploying the virtual service until after its processing steps have been properly configured. To enable the Deployment profile, you must switch the virtual service to a state that triggers the execution of a policy that enables the Deployment profile.

When you define the lifecycle path for a virtual service, you must determine during which states the Deployment profile will be enabled and during which states it will be disabled. Then, you must create policies to enable or disable the Deployment profile as appropriate when the virtual service enters these states.

For example, if you wanted the Deployment profile to behave as shown in the lifecycle path below, you would apply a policy that enables the Deployment profile when the virtual service switches to the VS_Virtualized, VS_Certified or VS_Promoted state, and you would apply a policy to disable the Deployment profile when the virtual service switches to the VS_Revising or VS_New state.

To enable the Deployment profile for a virtual service, create a policy that contains the following action and apply this policy (on a PostStateChange) to all states during which you want the controls on the Deployment profile to be enabled.

If you want to prevent users from modifying the processing steps for a virtual service after the Deployment profile is enabled, include the Processing Step Status action in the policy to disable the Processing Step profile as shown below.

To disable the Deployment profile, create a policy that contains the following action and apply this policy (on a PostStateChange) to all states during which you want the controls on the Deployment profile to be disabled.

If your lifecycle includes policies that automatically disable the Processing Step profile when the Deployment profile is enabled, this policy should include the Processing Step Status action to re-enable the Processing Step profile as shown below.

To create a virtual service in CentraSite, you must select the native service for which you want to create the virtual service and run the Virtualize command. During the virtualization process, CentraSite copies the metadata (including the WSDL) from the native service to the virtual service. In other words, the virtual service is basically cloned from the native service.

Because the virtual service is cloned from the native service, it has its own copy of the service metadata. If you make a change to the metadata in the native service after you generate the virtual service, you will need to explicitly update the virtual service if you want that change reflected in the virtual service, too.

Generally speaking, you do not want to generate the virtual service unless the following conditions are satisfied:

If a user has View permission on a native service and Create Assets permission within their own organization, he or she can create a virtual service. However, the user will not be permitted to configure the processing steps for the virtual service unless he or she also has the Manage Runtime Policies permission for their organization. Only users with Manage Runtime Policies permission can configure these steps.

Consider identifying a small group of users who will be responsible for configuring the processing steps for a virtual service. Give this group a role that includes the Manage Run-time Policies permission. Because these users might configure virtual services that other users have created, they will also need Modify permission on the virtual services. To ensure that these users can edit the virtual services that they need to configure, consider creating a design/change-time policy that automatically gives this group Modify permission on a virtual service when it is created.

One issue to consider when creating virtual services is the issue of ownership. When you create a virtual service, CentraSite automatically adds the virtual service to your organization (even if the native service itself belongs to another organization). You cannot explicitly specify the organization to which you want the virtual service added.

The issue of ownership is important with respect to virtual services, because it determines which run-time policies are applied to the virtual service when it is deployed. If the native service belongs to another organization, the existing run-time policies for your organization might or might not be appropriate for it.

When you define the general process that your site will follow to create and deploy virtual services (that is, when you determine who will create a virtual service, who will configure a virtual service, and who will deploy a virtual service), keep in mind that CentraSite always adds a virtual service to the organization of the user who creates it. Make sure that whatever process you adopt for creating virtual services places a virtual service in the appropriate organization.

There are several ways you can deploy a virtual service to a API Gateway instance. All methods except the first one allow you to deploy multiple virtual services in a single step.

To deploy a virtual service, the following conditions must be satisfied:

If these conditions are not satisfied, all or part of the deployment user interface controls will be disabled when you view the virtual service.

The deployment process is carried out by a sequence of interactions that occur between CentraSite and the API Gateway:

After you deploy a virtual service to a API Gateway, the virtual service remains deployed and active on that API Gateway until you manually undeploy. You can deploy a virtual service using the same deployment mechanisms mentioned above.

A virtual service that is already deployed on a API Gateway can be manually redeployed. You can redeploy a virtual service using the same deployment mechanisms mentioned above. If you make changes to a virtual service's processing steps, for example, you must manually redeploy the virtual service to put those changes into effect.

You cannot make changes to a run-time policy while it is active. To make changes to a policy after it has been switched to the active state you must do one of the following:

If you need to update a run-time policy that is already deployed with virtual services that are in production, always use the second method described above (that is, create a new version of the policy). If you use the first method, which requires you to suspend the existing policy, your production services will be running without the policy while you are making your revisions to it.

Web services are bound to change and evolve over time. The loose coupling principles of service-oriented architecture (SOA) imply that service providers can release a new version of a shared service without waiting for consumers to adapt, and that service consumers should test and certify on a new shared service version before switching. Consequently, you might need to have multiple versions of a shared service running concurrently and simultaneously accessible by different service consumers. Some service consumers might need to continue using an old version of a service until migration of the consumer code occurs. Therefore, Web services versioning is an important subject that should be considered carefully in all enterprise SOA approaches.

Current standards for Web services have no explicit support for versioning. However, there are two alternatives for handling access to multiple versions of Web services:

API Gateway cannot run multiple versions of the same virtual service simultaneously. API Gateway only retains the last deployed version of a virtual service. However, suppose you have multiple versions of a native Web service. By using a versioning pattern, a single virtual service can provide access to the various native service versions based on an intelligent routing scheme that routes requests from a particular consumer to the correct native service version. A second option would be to provide multiple virtual services that correspond to multiple native service versions. For example, suppose you have two versions of the native service GetOrder. You have the following options in API Gateway:

Minor and Major versions of Web services are described as follows:

This pattern allows multiple Minor versions of a native service to coexist in the registry without requiring consumers to change the code in their consumer applications, and helps to ensure a graceful migration to the new Minor version.

To implement this pattern, you configure a single virtual service to route each request to the version that is appropriate for each consumer (or group of consumers). That is, you configure the virtual service's Routing step to use either the content-based routing option or the context-based routing option.

This pattern allows multiple Major versions of a native service to coexist in the registry without requiring consumers to change the code in their consumer applications, and helps to ensure a graceful migration to the new Major version.

This is called the adapter pattern because API Gateway will act as an adapter, adapting the client requests before they are submitted to the native services.

Unlike the Layer of Indirection pattern, which has one virtual service that can access each Minor version of the native service, this pattern has a separate virtual service for each Major version of the native service.

To implement this pattern, you configure the virtual service's Request Processing step so that it transforms the endpoint specified in a request to the endpoint of the desired version. The Request Processing step specifies how the request message is to be transformed before it is submitted to the native service. You can configure this step to perform message transformations using a specified XSLT file or by passing the message to a webMethods IS service (that is, an Integration Server service running on the same Integration Server as webMethods API Gateway).

This pattern has one virtual service that can access: