A Virtual Service runs on runtime gateway, for example webMethods Mediator, 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 Mediators. 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 Mediator. You use CentraSite to create, edit, publish, and manage virtual services. Virtual services have the following major elements:

The processing steps associated with a virtual service determine how the virtual service handles the requests it receives from consumer applications. All virtual services have four processing steps:

You configure these steps to specify how Mediator is to act upon the requests it receives for this virtual service.

The Entry Protocol step specifies the protocol (JMS, HTTP, or HTTPS) in which the virtual service accepts requests. This step allows you to bridge protocols between the consuming application and the native service. For example, let's say that you have a native service that is exposed over JMS and a consuming application that submits SOAP requests over HTTP. In this situation, you can configure the virtual service's Entry Protocol step to accept HTTP requests and configure its Routing Step to route the request to the native service using JMS.

Besides using the Entry Protocol step to resolve protocol differences between the consumer and the native service, you might use this step to intentionally expose a virtual service over a particular protocol. For example, if you have a native service that is exposed over HTTP, you might expose the virtual service over JMS simply to gain the asynchronous-messaging and guaranteed-delivery benefits that one gains by using JMS as the message transport.

The Request Processing step specifies how the request message is to be transformed or pre-processed before it is submitted to the native service. You can configure this step to perform message transformations using a specified XSLT file or by calling the webMethods IS service (that is, a webMethods Integration Server service running on the same Integration Server as webMethods Mediator).

You can use this processing step to accommodate differences between the message content that a consuming application is capable of submitting and the message content that a native service expects. For example, if the consuming application submits an order record using a slightly different structure than the structure expected by the native service, you can use the Request Processing step to transform the record submitted by the consuming application to the structure required by the native service.

The Routing step specifies the endpoint to which requests are to be routed and the protocol (HTTP or JMS) by which they are to be submitted to the native service.

If the native service is exposed over JMS, you use the routing step to specify the queue to which the Mediator is to submit the request and the destination to which the native service is to return the response.

If the native service is exposed over HTTP or HTTPS, you can configure this step to route all requests to a specified endpoint (straight through routing), route requests to different endpoints based on the content of the request (content-based routing), route requests to different endpoints based on factors such as the time of day or the requestor's IP address (context-based routing) or distribute requests across multiple endpoints (load-balancing routing).

If you have a native service that is hosted at two or more endpoints, you can use the load balancing option in the Routing Step to distribute requests among the endpoints or you can use the content-based or context-based options to route different types of messages to different endpoints.

Using the content-based routing option, you can route messages to different endpoints based on specific values that appear in the request message. You might use this capability, for example, to determine which operation the consuming application has requested and route requests for complex operations to an endpoint on a fast machine.

Using the context-based routing option, you can route messages based on criteria such as the time of day and/or the identity of the consuming application. For example, you might use this capability to route requests from certain high-priority consumers to endpoints on a fast machine.

The Response Processing step is similar to the Request Processing step. This step specifies how the response message from the native service is to be transformed or processed before it is returned to the consuming application. Like the Request Processing step, you can configure the Response Processing step to perform message transformations using a specified XSLT file or by calling the webMethods IS service. You can also use this step to return a customized error message to the consuming application when a SOAP fault occurs. (CentraSite provides a set of context variables that you can use to incorporate specific details about the transaction into the error message. You might use these variables to include information such as the time and date of the error, the consumer identifier, and/or the requester user ID.)

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 Mediators that are attached to your instance of CentraSite. For example, if you will be deploying virtual services to two different Mediators, you must create two gateway objects, one for each Mediator 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 Mediator 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 Mediator:

After you deploy a virtual service to a Mediator, the virtual service remains deployed and active on that Mediator 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 Mediator 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:

Mediator cannot run multiple versions of the same virtual service simultaneously. Mediator 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 Mediator:

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 Mediator 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 Mediator).

This pattern has one virtual service that can access: