Service Oriented Architecture (SOA) promises to reduce the amount of new code required to create new applications by allowing the reuse of existing services. To get significant benefit from SOA, an organization must have as many services exposed as possible at as broad a level as possible.

Those services will be very expensive to manage if they are all written from the ground up and don't build on a common framework for communication, deployment, and management. Civil engineers don't build an office tower with independent plumbing, electricity, and insulation for each office. Services shouldn't be built that way either.

Development organizations need to respond more quickly to changing market requirements in today's ultra-fast-paced business world. SOA promises to help those IT departments drastically shorten the development time for new initiatives while increasing the stability of the delivered functionality. How can a new approach to building applications do that?

To reuse services, companies must first service-enable existing assets and build services to meet the needs of ongoing business initiatives. With each project built according to SOA principles, the library of services available to the next project will grow. As that library grows, so will the benefits of SOA.

Unfortunately, as that collection of services grows, so does the complexity of the environment in which they're deployed. Services-based applications are, by their nature, more complex than standalone applications. At the very least, a services-based application consists of a number of different components (services) that all need to communicate for that application to function right. This communication has performance implications, introduces new failure points and can weaken security.

Services-based applications developed using the same techniques as standalone applications will also have significantly more code than monolithic applications with equivalent functionality. This is because conventional service development tools require that communication between services be hand-coded in each and every service that's built. Inter-service communication is fundamental to service-based architectures and shouldn't have to be hand-coded each time a new service is built.

Application servers provide a framework for building Web-based applications that lets developers focus on building the flow and logic of a Web application. Functionality that's common to all Web applications - such as resource pooling, thread management, and session management - is not hand-coded by developers for each application. Instead, the application server provides for this common functionality. In SOA, communication between services is common across all servers and should not be hand-coded, but should be provided by the deployment environment for those services.

Service Virtualization Defined
Recent studies show that 40% of the code written for the average service developed using an application server is unnecessary "plumbing" code.

Large office buildings don't have duplicate plumbing systems and the business units of a large corporation that inhabit those buildings don't build duplicate HR departments. In SOA, the same principle applies. Services must be reused across as much of the organization as possible to get the full benefit of SOA.

As a company gets to be 10 or 15 years old it doesn't create a second human resources department because the original one is "out-of-date." The same principle applies to old services. Modernization might be required, but replacing services should be avoided whenever possible. This lets developers focus on delivering new value to the business organization.

Services with very broad reuse and services with long life spans both imply a heterogeneous service environment. No company can standardize on a single development language or toolkit and expect that they will use it forever. Internal personalities, corporate mergers, and technological progress will all contribute to a library of services based on different programming languages and frameworks.

Heterogeneous environments make sense. The computers found that in the typical corporate office there are a mix of different form factors (laptops, desktops, servers) that run on different operating systems and run different software packages. However, those computers all connect to the same network and power infrastructure.

The same must be true of services. A services-based application can certainly be an orchestration leveraging a Java service, a .NET service, and a C++ service. All of those services should communicate, be deployed and monitored using the same mechanisms.

Service virtualization is an approach to deploying and managing services that provides the common plumbing required by all services-based applications. This lets developers focus on building new functionality and provides a foundation on which you can plug that new functionality.

To do this, new services must be written to run as components in a service container. That container must then provide a straightforward mechanism by which the newly deployed service can both be invoked, and invoke other services. This clear separation between the service logic and its communication with other services is the most important requirement for effective service virtualization.

ESBs and Beyond
Enterprise Service Bus (ESB) products have already been implemented by many companies with SOA initiatives. These products provide enormous value by allowing companies to easily bridge communications between services, packaged applications, and legacy assets. Complete ESB offerings also provide a mechanism by which legacy systems can be intelligently exposed as services without any changes to those existing system. Many even go so far as to providing the ability to very quickly orchestrate a set of services into a higher-level business service using a graphical flow language.

These ESB products all provide for mediation as their core functionality. This mediation allows ESB customers to remove the in-code coupling between services. Some companies are currently plugging all of their services directly into these products. By combining the out-of-the-box connectivity features found in ESB products with messaging technology, standards, and conventions these companies have implemented the most basic form of service virtualization.

The ESB-based service virtualization approach helps solve much of the communications problem. However, the management of those services isn't addressed because ESBs only address communication between services and don't provide a container in which to host the service. Further, developers still need to write some communications code because the ESB only mediates communication.

Implementing Service Virtualization
Developers should be able to focus simply on writing the functionality required for a new business initiative or business application. Once that service has been deployed, a service virtualization container should:

• Provide the communication required to invoke other services;
• Allow the service to be invoked from orchestrations and other services;
• Insure data integrity across multiple service invocations;
• Secure all communications according to corporate requirements;
• Control access to the service;
• Track use and performance of the service;
• Provide common pooled access to resources (for example, DBs, JMS);
• Provide for hands-off migration of services from dev-test-production; and
• Allow for lifecycle operations.

Companies in such heterogeneous environments struggle with the very definition of "service." Is a service anything with a clearly defined interface? Is it something with a SOAP interface and a WSDL definition? Is an orchestration a service? Service component architecture (SCA) finally provides a single definitive answer to these questions by providing a universal definition of "service." It provides not only a formal interface definition, but also ties that interface to an implementation, specifies service and non-service dependencies, and allows deployment overrides to be written in a standardized way. Also unlike WSDL, SCA doesn't tie the service to a particular communications endpoint. This is very important because it further decouples service code from the underlying plumbing.

It's not enough to provide a single definition for a "service" and a single model for describing that service. To have a single container that can host heterogeneous services there has to be a standard by which all of those services can "plug-in" to a container.

Just as the Enterprise Java Bean (EJB) specification provided a standard for plugging code into an application server, Java Business Integration (JBI or JSR208) provides the standard by which services can easily plug into a service container or service virtualization environment. JBI describes how the service communicates with the service container and also how the service is monitored and managed.

A service container built on a combination of SCA and JBI lets developers write services with no transport code at all. Using other services becomes as easy as writing a single line of code: create a service object and invoke a method on that object.

Standalone service containers aren't enough. Large-scale adoption of SOA means services distributed throughout the organization on different machines and even different platforms. These services must run on an interconnected grid of service containers. Service invocations must flow seamlessly from one "node" in this grid to any other node. In fact, it shouldn't matter which machine in the grid a given service is deployed to because the service code itself doesn't contain any hardwired ties. Invoked services might live on the machine from which they are called, or any other machine on the grid.

This extreme decoupling has radical implications for service scaling. Just as machine virtualization makes it easier to provision new machines, service virtualization makes it easier to provision new services. In the SOA world, the ability to provision new instances of a specific service is very important. The web of reuse that one sees in mature SOA makes anticipating load requirements nearly impossible. The ability to react to those load requirements by provisioning new services makes predicting them unnecessary.

Large buildings rely on a single solid foundation and a well-designed infrastructure to survive. Large-scale SOA is no different. Building your services on top of a solid service virtualization layer will reduce operational cost and complexity while allowing your developers to focus on writing new functionality and providing new business value. In today's hyper-competitive business climate this increased agility provides an invaluable edge.