Introduction
Service Virtualization is the concept that allows physical services (let’s call them business services or business APIs) to be exposed through an intermediary (or broker) application similarly to how classical reverse proxies forward messages to applications behind them. The difference between “primitive” reverse proxies and service virtualization intermediaries in that the latter are loaded with the intelligence and knowledge of what services and APIs they are actually exposing. This intelligence is what makes virtualization intermediaries a powerful and non-intrusive software instrument in the real-life service brokerage scenarios.
Consider the following diagram where a service intermediary exposes potentially hundreds of business services as if they are real services but with added value of real-time non-intrusive monitoring, managed authentication and access control, security and communication protocols bridging, Service Level Agreements management and many others at the same time.
In this article I will try to highlight only some of the most notable service virtualization scenarios, their differences and specific benefits. In addition to conceptual descriptions I will briefly demonstrate how these concepts are actually implemented in the Nevatech’s Sentinet™ software product which is a unique service virtualization solution built entirely on a Microsoft platform. In my next article I will discuss how these scenarios can be applied to, and benefit services and APIs versioning challenge – something that is often overlooked as a one of the service virtualization benefits.
Service Virtualization concept in general, and Sentinet product as its concrete implementation, support variety of practically unlimited service virtualization scenarios that provide very specific benefits. The choice of selected scenario is typically driven by the ultimate requirements and service virtualization objectives (for example, an objective can be to make services more accessible, or to enable services with new capabilities, or to provide services with remotely managed monitoring and access control, or to support services versioning through a non-interruptible operational environment).
Let’s start describing these scenarios by defining a generic structure of a virtualized business service. Each service is defined with one or more interfaces, where each interface defines one or more operations and one or more endpoints. Figure bellow shows example of a generic service structure with two interfaces, two operations per interface and two endpoints per interface.
Unlike SOAP services, REST services do not have concept of interfaces and they are described with the simplified structure as shown in an example below:.
Service Virtualization Scenarios
Service virtualization scenarios described below use SOAP services as examples. REST services can be virtualized through the exact same scenarios with the exception of mentioning service interfaces and WSDL metadata.
It is also extremely important to note that from SOA Governance perspective virtual SOAP services must be capable of producing 100% accurate metadata (WSDL) that fully describes all the elements of the virtual services including interfaces, operations, endpoints, endpoint identities and endpoint policies. Without being able to give access to the virtual services’ metadata the benefits of the virtualization concept would have been limited only to runtime capabilities with nonexistent design-time benefits. In other words, if developers of consumer applications cannot get access to the virtual service metadata (and that is the only metadata that consumer applications are ultimately have to be concerned about) then developers will not be able to successfully build and maintain their applications. Sentinet is unique in that it gives easy access to any virtual service metadata, and most importantly Sentinet provides 100% accurate and complete description of the virtual services through dynamically generated WSDL documents.
One-to-one mapping
In a one-to-one interfaces and operations mapping, virtual service virtualizes business service structure “as is”:
Note that one-to-one mapping does not include explicit endpoints mapping. Messages received by any endpoint of a virtual interface can be routed to any endpoint of the matching business interface. Moreover, number of virtual interface endpoints does not have to match the number of business interface endpoints. Example above shows single endpoint, VirtualEndpoint1 of the virtual interface, Interface1. VirtualEndpoint1 routes messages to any endpoint of the matching business interface Interface1, Endpoint1 or Endpoint2. At the same time any endpoint, VirtualEndpoint3 or VirtualEndpoint4 of the virtual interface, Interface2 routes messages to the same exact (and the only one in this case) Endpoint3 of the matching business interface Interface2. In case of Interface1 virtual service provides the feature of endpoints routing. In case of Interface2 virtual service provides the feature of better service accessibility when business service becomes more accessible through different virtual endpoints. In the latter case each virtual endpoint can be configured not only with its own address but also with its own transport, protocol and policies requirements.
Partial Mapping
In a partial mapping scenario, only a subset of business operations is virtualized where some of the business operations are not made available for consumer applications that access business service through the virtual service.
Example above shows virtual service that does not provide virtual Operation2, making business Operation2 unavailable for service consumer applications. In a real-life scenario you may have hundreds of business operations provided by the business service or API, but you may want only a subset of these operations to be available through a virtual service. Service virtualization provides here the benefit of business service reuse when different virtual services virtualize the same business service or API but in a different manner and with different service structure.
Services Aggregation
The most powerful scenario that provides services reuse benefit is the one where a virtual service aggregates more than one business service at the same time.
Single Interface Aggregation
Example below shows the actual Sentinet Console screenshot where Sentinet Virtual Services Graphical Designer is used to design virtual service that aggregates two business services (CustomerSearch and Order Service) within the same Interface1 of the virtual service.
An aggregate virtual service gets the structure that combines operations from all aggregated business services. Note that each business service can be deployed in its own location with its own endpoints, transport, protocol, message version and binding requirements, and yet exposed through a single virtual service with its own unique inbound virtual endpoint, VirtualEndpoint1.
Multiple Interfaces Aggregation
Business services can also be aggregated by different virtual interfaces. The same business services above can be aggregated as shown in this screenshot bellow.
The resulting virtual service gets the following structure.
A single virtual service here aggregates two business services by providing unique service interface per each virtualized business service.
Services Aggregation with Partial Mapping
Partial mapping and service aggregation scenarios can be combined when only some of the business service operations are virtualized as shown on the following below.
Note that SendAlert operation is excluded from CustomerSearch service virtualization, and GetOrderStatus operation is excluded from OrderService virtualization. The resulting virtual service gets the following structure.
Example above demonstrates the most notable use case of the services reuse benefit when multiple services (or APIs) are aggregated exactly the way they are supposed to be exposed to consumer applications. Users can pick only few operations from one API and few operation from another API, and then expose them as a single virtual service with only those operations that are relevant to the external applications.
Message Transformation Scenario
In a message transformation scenario a message sent by a consumer application can be transformed by the virtual service before it is delivered to the business service.
Capabilities Enablement Scenarios
Service virtualization scenarios are often used to provide business services with new capabilities. Here is few examples of service capabilities enablement via mediation and protocols bridging.
- A business service deployed with Microsoft-specific and performance-optimized communication binding (NetTcpBinding) can be provided with capability to be consumed via interoperable HTTP or HTTPS virtual service (transport, protocols and messages encoding bridging).
- A business service deployed with Microsoft-internal Windows integrated security can be provided with capability to be consumed via interoperable X.509 certificates or Username/Password- based security (security mediation).
- A business service deployed with no knowledge of SAML tokens and federated security can be provided with capability to be a claims-aware application with support for Federated Security (federation and single-sign-on enablement).
- A business service is enabled with non-intrusive remote control of authorization logic and access control (access control enablement).
- A business service developed and deployed as SOAP services can be exposed as REST service. The same business service can also be exposed through different virtual services , for example as virtual SOAP and as virtual REST services.
In the next article I will show how to apply service virtualization scenarios described in this article to the Services and APIs Versioning challenge.