Service virtualization

Service virtualization is the abstraction of a physical service through a proxy or intermediary service. With service virtualization, the service intermediary interacts with the service consumer (i.e. the service or application making a request) and hides the physical location of the service provider (i.e. the service or application that provides functionality). In other words, communication between the service provider and service consumer is done through a service intermediary, creating a gateway for application integration.

Service Consumer ←→  Service Intermediary ←→ Service Provider

There are several common patterns of service virtualization, each of which suits particular use cases:

• The most basic service virtualization pattern is a simple service intermediary that decouples the service consumer from the service provider by adding a layer of indirection. The service consumer interacts with the interface of the service intermediary, which is the same as the interface of the actual service provider. Because the service consumer only knows the location of the service intermediary and not the endpoint address of the service provider, this pattern of service virtualization is commonly used when services are invoked by consumers that reside beyond the enterprise, providing security and control over access to such services. It is also used to prevent disruptions when changes are made to a service provider (for example, moving a service provider from one server to another), allowing the service consumer to continue interacting with the service intermediary without being impacted.
• In a service selection pattern, multiple implementations (or instances) of a service provider with the same interface are exposed to the service consumer at a common endpoint address. Each instance of the service provider provides a different level of service and the service intermediary routes a request to the appropriate endpoint based on the context of the service consumer’s invocation. In other words, the service consumer doesn’t know that there are multiple instances of the service provider and it is the service intermediary’s job to select the appropriate version based on the service consumer’s needs. This pattern can be used to distinguish service levels between different kinds of customers. For example, the service intermediary of a General Contact Service for a solar energy company end-user inquiries to one endpoint while routing vendor inquiries requests to another.
• In a service translation pattern, a service provider is made available through a service intermediary with a different interface than the existing interface. This allows for only some, rather than all, functionalities to be exposed as well as the modification of an interface to meet the local requirements of a service consumer. The service intermediary then translates the original request to meet the requirements of the existing interface before routing it to the service provider. This service virtualization pattern might be used when an enterprise teams up with a partner enterprise and decides to limit exposure of its services or discovers that the service consumers in its partner systems require data transformation for their different interface requirements.

To get a better understanding of service virtualization and its uses, consider the following scenario. XYZ Bank offers Checking and Savings products and Credit Services to its customers. To better compete with online banking institutions, XYZ Bank has recently started to offer an Online Savings product.

In XYZ Bank’s existing architecture, bank employees can access customer account information by using a custom enterprise application that sends requests to an Account Service. The Account Service then retrieves and combines data from a Checking and Savings accounts database and a Credit Services database, returning information on all the active accounts of a customer to the bank employee. Customers can access their account information through a web browser.

With the introduction of the Online Savings product, the bank’s Account Service must now be updated so that it can also retrieve information from the newly deployed Online Savings accounts database for new customers. An update to the Account Service will make existing account information unavailable to bank employees and customers, but XYZ Bank cannot afford such a service disruption.

The use of a service intermediary allows XYZ Bank’s development team to make the service upgrade while existing account information for Checking and Savings accounts and Credit Services remains available to bank employees and customers. The service consumer (i.e. either the custom application used by bank employees or the web application used by customers) sends requests to the service intermediary, which then routes the request to the existing version of the Account Service to retrieve the relevant information. When the upgrade to the Account Service is complete, the service intermediary acts as the common interface, routing requests to either the existing version of the Account Service or the upgraded version, which now includes Online Savings account information.

In order for proprietary or open source SOA to deliver real benefits, enterprise systems need to be flexible and agile. The loose coupling of services through service virtualization provides this flexibility and agility. Because service virtualization allows developers to make changes and upgrades to applications and services without disrupting access to end-users, it makes moving to cloud computing services or scaling up or down in a short amount of time possible. Moreover, the use of service intermediaries and other virtual services means that developers can focus on the service logic and functionality rather than the communication mechanisms when it comes to creating new services. With service virtualization, SOA becomes a reality.

Want to learn more? Explore MuleSoft's solutions for SOA.