Realizing SOA with service virtualization?

Gosh, since virtualization is a hot buzz word, we'll use it everywhere.

Service Virtualization as a Solution

At its most basic form, virtualization is an abstraction layer that decouples a resource consumer from the provider of those resources. Virtualized resources allow a single provider to support multiple consumers to achieve higher agility and reuse of those resources. In the virtual machine scenario, the physical hardware is abstracted from the operating system creating unique opportunities for design optimization.

Capable of supporting multiple running instances of different operating systems on the same machine, virtual machines deliver unparalleled utilization of extra processing cycles in the data center and developer workstations. Service virtualization realizes many of the professed SOA advantages by abstracting the true service address, binding, and contract necessary to invoke business functionality at a given endpoint. An abstraction layer is also a potential platform for additional behaviors.

Address virtualization abstracts the URI where the endpoint actually sits from service consumers and allows messages to be delivered per metadata to different endpoints. Coupled with content-based routing behavior, for example, address virtualization could be used to manage a service level agreement (SLA). For instance, a Web farm can be dedicated to silver customers and another more powerful and robust Web farm can be made available for gold customers. Consumers would appear to invoke the same endpoint, but in reality messages would be routed to the appropriate endpoint, thus ensuring an appropriate level of service that corresponds to the importance of the customer.

Binding virtualization abstracts the actual communication protocols supported by the endpoint to more easily allow providers to adopt newer Web service development stacks while still supporting existing service consumers. Contract virtualization abstracts WSDL and XSD definitions so services can be discovered. For example, a service may be dynamically comprised of operations from disparate services to form a single service that may serve as a better representation of a task or entity service. Such seemingly straightforward capabilities are extremely powerful and organizations may be willing to undergo major infrastructure upgrades to better support a virtualized service inventory.

Many vendors profess service virtualization as a capability of their intermediary, agents, or bus. Usually they limit the concept to contract virtualization and attribute address virtualization and binding virtualization as a feature of their product. It is important to understand that the concept exists independently from any specific implementation architecture. Certain architecture designs are supported by a stronger implementation and serve as a base for security, monitoring, and caching of value-added services. Service virtualization implemented over the service intermediary pattern ideally achieves these goals in a non-invasive manner and can be easily applied to existing production deployments. Moreover, the centralized nature of service intermediaries makes them an excellent platform for service repository and service registry capabilities.

To gain a real world perspective of this approach, let’s explore the case study example.

Link