Service Virtualization or Service to service(s) map

In Service Oriented Architecture, a service definition, in case of web services expressed in a form of WSDL, is a contract between a service provider and consumer. This contract needs to be long lasting. Moreover, services needs to be well designed so that they can be consumed very well with various tooling and programming frameworks. It sounds easy especially when such services are defined in a standard language like WSDL.

However, when a provider is exposing a legacy application, like Peoplesoft Component Interface based application, as a service, it becomes often challenging because the services often carry signatures of legacy services including naming, data types etc. Consuming them becomes a nightmare because if you run then through some service developments tools like wsdl2java, you would get an explosion of java objects with meaningless names and a spaghetti object model. If the provider intends to expose such services at the same time re-implement the services, the provider would prefer to be a forward looking and should define the service contract as “how it should be” and not as “how it is today”.

Many air travel ticketing sites expose their web services and in backend use Web services from providers like Sabre as the actual provider. However, they may have some additional processing or just would like to hide the details of the actual provider service. In such scenario when a service provider is actually delegating to a third party, the provider would hide the identity and details of the third party service so that if needed it can be replaced by an in-house implementation or another third party implementation.

In many such occasions, service providers want to separate a service from its physical implementation. This usage pattern is often referred as “Service Virtualization” and would be served by a “service to service map”. Many Web Service gateways/brokers, Enterprise Service Bus like Oracle’s ESB typically provide a framework for virtualization.

In most of the implementations, the physical service may not be on the same host. The virtual service may have more meaningful or different names for service, operations and messages data types. Most importantly it may not have the same shape and it may even have a different protocol like SOAP over HTTP or JMS.

In bare-bone architecture of virtualization, there could be a one to one mapping of operations between a source and proxy service. In this mapping, the name of the operations as well as shapes of payload may get changed. In a more complicated scenario, a proxy service may represent a full or partial view of more than one service.

Thus, common Patterns of Service virtualizations are:

1. One to one: One service can be mapped to another service.

1. Fan out: One service operation can be delegated to multiple services to execute.

2. Partial: A service is partially exposed as a virtual service.

3. Aggregate services: Multiple services can be partially or fully grouped together and exposed as one virtual service.

A typical service virtualization framework would have metadata module to capture the service routing information, transformations and invocation framework to mediate between various transports.

In summary, Service virtualization is useful in following use cases

1. XML firewall isolating virtual and physical services

2. Proxy Service provider for an external service

3. Composite service from different services

4. Encapsulating legacy services

Service virtualization using Oracle ESB 10.1.3:

Here is an example of a 1:1 service virtualization using Oracle ESB 10.1.3. In this example I am providing MovieService as a proxy for an external movie service available on internet (http://www.ignyte.com/webservices/ignyte.whatsshowing.webservice/moviefunctions.asmx?WSDL)

The proxy movie service changes the namespace, and some operation name. The Routing service in ESB transforms and routes the incoming messages to the external movie service.

Higher level view of service virtualization: