Follow Us on:

• About
• Leadership
• News
• Events
• Careers
• Contact Us
• Environmental

What Happens When SOA and Virtualization Intersect? Mark O'Neill SOA World Magazine 6 October, 2008

Virtualization is a buzzword that is living up to its hype as it takes hold in IT. It has spawned magazine covers, conferences, and analyst reports, and all with good reason. Virtualization allows applications to be deployed in a highly efficient manner. By taking the physical servers out of the equation, virtualization allows applications to be deployed across a number of servers, or for multiple operating systems to run simultaneously on one server. In this way, an organization can scale its applications by seamlessly adding hardware, or by adding more instances of operating systems to its servers.

In the world of Web Services, in a "service-oriented architecture" (SOA), applications are deployed as services over the network. This means that if an application wants to use components of another application, it simply accesses this other application over the network. The services in an SOA are both language- and platform-neutral, so they can be called from .NET applications or Java applications, in Windows, Linux, or Solaris. How does virtualization apply to SOA? In this article, we look at the intersection of SOA and virtualization, which is service virtualization.

"Service virtualization" is made possible by XML gateways. Over the past three years, XML gateways have emerged as a prime delivery platform for XML applications. An XML gateway is either delivered as an appliance or as software. It proves functionality that is essential to the successful delivery of Web Services, such as security, XML processing acceleration, and XML routing. XML gateways effectively "front" back-end Web Services by creating so-called "virtual services" that act as proxies in front of the real services. For example, if an organization has used .NET to create a Web Service called "calculateStateSalesTax", then an XML gateway can be used to create a virtual service in front of the service. Then, the client accesses the virtual service at the XML gateway rather than the actual Web Service.

This architecture is depicted in Figure 1. Clients can now connect to the virtual services rather than directly to the Web Services. The XML gateway makes this possible.

By acting as a proxy, the XML gateway has created the virtual service. You may ask "Why?" What are the advantages of service virtualization?" We examine these advantages below:

An XML gateway provides a number of important mediation services. These are:

• Protocol Mediation: For example, a message received to a virtual service over HTTP may be placed onto a message queue by the XML gateway. In this way, the XML gateway has "service-enabled" the message queue.
• Identity Mediation: A client's presented identity (e.g., from an X.509 certificate) may be mapped to their local identity. This is an important component of what is known as "identity federation." The XML gateway effectively acts as an identity bridge.
• Content Mediation (transformation): A message may be transformed using XSLT or using custom code (Java, JavaScript, etc.). This deals with the fact that XML messages are sometimes received in the wrong format, or wrong version, and must be transformed.

Service virtualization means that back-end services are not directly in the "line of fire" from clients. For example, with service virtualization the back-end services don't need to have publicly addressable IP addresses. Only the XML gateway receives messages from clients. The XML gateway typically includes a full set of "XML firewall" threat protection. Therefore it blocks both brute-force denial of service and the more insidious XML denial of service, which makes use of XML messages that are designed to be difficult for services to parse.

XML gateways support a wide arrange of access methods, all based on standards such as WS-Security. This means that a virtual service, exposed by the XML Gateway, most likely supports many more standard access methods than a "real" service. For example, many Web Services platforms do not fully support X.509 certificate authentication using the WS-I Basic Security Profile. However, XML gateways support this. Service virtualization allows a secure standards-compliance access mechanism to be placed in front of Web Services that may not support standards fully.

Organizations that are adopting Web Services are often unsure about which platform they will eventually use. For example, an organization may have started out with WebLogic but ultimately intends to move to .NET. A "service virtualization" pattern helps this. This is because when a client connects to a "virtual service" rather than to the real service, this allows the actual back-end service to be migrated from one platform to another, without causing any effect on the client. The client is not "tightly coupled" to the back-end service, and is often unaware of which platform is being used at the back end, because tell-tale information such as file endings (e.g., ".asmx" for .NET, ".jws" for Java) are hidden by the XML gateway.

This is a direct analogy with server virtualization. In a similar manner to how server virtualization allows for one operating system to run on multiple servers, a "virtual service" can be mapped to multiple back-end services. This is usually done for performance reasons: a single service can call on multiple back-end services to share its load. It also allows for high availability to be provided, since if one back-end service is unavailable, others can be used instead.

A fundamental design pattern of SOA is that multiple services can be amalgamated together into "composite services." For example, a service may use a service to look up an attribute of a customer, such as their payment status. An XML gateway or an Enterprise Service Bus (ESB) can be used to create these "composite services." An XML gateway brings the advantage of an XML acceleration subsystem, when compared to an ESB.

An XML gateway allows for differential access to services, depending on the attributes of the client. For example, a "gold customer" client can be given prioritized access to services, when compared to other clients. This is not possible when all clients simply access services directly.

When an XML gateway implements service virtualization in front of Web Services, this allows for outages of the Web Services to be detected. Since the XML gateway becomes the ultimate client of the Web Service, any excessive service latency is detected. If the back-end service is not responding, the XML gateway can use a cached response, or route the request to a different back-end service.

Service virtualization is a new type of virtualization that comes from the world of SOA. It has some aspects in common with server virtualization, such as the masking of underlying resources. The enabler of service virtualization is the XML gateway. In this article, we demonstrated how XML gateways enable service virtualization and deliver attendant benefits. The "service virtualization" pattern is here to stay, and is an important part of how XML gateways act as an essential delivery platform for SOA.