A virtualized service is a service that runs on webMethods Mediator and acts as the consumer-facing proxy for a native service that runs elsewhere on the network. You can create a virtualized service for a SOAP-based Web service, a REST service or an XML service. A virtualized 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.
CentraSite supports three types of virtualized services, all of which are predefined asset types that CentraSite supports out-of-the-box:
| Virtualized Service Type | Description |
|---|---|
| Virtual Service | These are virtualized SOAP-based Web services. |
| Virtual REST Service | These are virtualized REST services. |
| Virtual XML Service | These are virtualized XML services. |
This document uses the term "virtualized service" when referring to the three types of virtualized services in general.
You deploy virtualized services to the webMethods Mediator policy-enforcement point. When a virtualized service is deployed, consumers access this proxy service instead of the actual native service. The virtualized service forwards the request to the appropriate back-end service and, if it has been configured to do so, performs additional mediation functions such as message transformation, protocol bridging, load balancing and failover handling.
The figure below shows webMethods Mediator (the "service access intermediary") mediating traffic between consumers and virtualized services. Mediator provides loose coupling between consumers and providers, and is able to identify the consumers who are accessing the provider services by examining the traffic flowing through it.
A virtualized service is an asset that you create and store in the Asset Catalog. You should virtualize each service that you want to deploy to webMethods Mediator. You can virtualize a service from scratch or make a virtual copy of an existing service, and then configure the following information in the virtualized service definition (VSD):
You configure a virtualized service by configuring its processing steps, as follows:
The Entry Protocol Step.
For a SOAP-based virtual service, you specify the protocol (HTTP , HTTPS or JMS) and SOAP format (1.1 or 1.2) of the requests that the service will accept.
For a virtual REST or XML service, you specify the protocol (HTTP or HTTPS) of the requests that the service will accept. You also specify the HTTP methods (GET, POST, PUT, DELETE) that the virtual service should be allowed to perform on a REST resource.
The Request Processing Step, in which you specify optional custom processing for requests responses (such as message transformation or pre-processing).
The Response Processing Step, in which you specify optional custom processing for responses (such as message transformation, post-processing or error messaging instructions).
The Routing Rules Step, in which you specify the manner in which to route the requests (e.g., directly to the native service, or routed according to your routing rules, or routed to a pool of servers for the purpose of load balancing or failover handling). You also specify the protocol used for authenticating the requests (for example, the credentials specified in the request’s HTTP header).
You can create one or more virtualized services for a single SOAP-based Web service, a REST service or an XML service. For example, if you have different authentication or routing requirements for two different sets of consumers, you would create a different virtualized service for each set of consumers.
