The concept of a Service Oriented Architecture (SOA) existed long before the current set of Web Services standards. However, it's the widespread adoption of these standards that has enabled the idea of SOA to enter the mainstream and to start delivering the level of connectivity and savings it has promised for so long. Now that SOA has hit the mainstream, some are attempting to show how SOA can be successfully implemented using pre-Web Services technologies. This article will show why these approaches fail to fulfil all aspects of SOA and become exercises in rediscovering why SOA depends on Web Services technology.

Before looking at some of the shortcuts that people take, let's start with a quick recap of the core principals of SOA. SOA is an approach to software development that is most commonly used where a number of distributed systems have to be connected. SOA emphasizes the use of standards to achieve interoperability and the reuse of existing assets. One aspect of SOA that is often overlooked is the use of a standardized protocol that provides a message envelope to enable the processing of messages by intermediaries. Of course, at the heart of SOA is the concept of the service, which should perform a specific task and be self-contained. It should be invoked remotely, have a well-defined interface, and be loosely coupled.

The As-You-Were Approach
The adoption of a new architecture requires some due diligence, part of which must be a comparison of it with existing practices and architectures. At this point, finding elements of SOA already in use is good news for everyone. However, this doesn't mean that no change is required and that the existing system just needs to be described in SOA terminology.

Consider what might be uncovered in an organization during an analysis prior to introducing SOA. Most large organizations have an existing queue-based transport infrastructure (if not several of them) that is typically used to support a variety of point-to-point integrations between applications. The good news is that these systems exhibit many of the characteristics of loosely coupled services: they perform specific tasks, exchange messages asynchronously, and can be accessed remotely via message queues. Most message formats are text-based. However, they've been documented as part of the design process.

It might appear that there's little left to do to roll out a SOA in an organization - perhaps all that's needed is to standardize a few design practices, such as getting people to think about the kinds of tasks these systems perform. Sections of the design documents can be published in a new document repository so that the message formats can be made public. Finally, organizations can standardize on the use of a single middleware vendor to provide the queue-based transport. They may have cut a few corners in using Web Services standards, but most of the SOA principles are covered.

The problem with this approach is that while the owners of the existing systems feel good about their architecture, the tasks required in enabling a new application to act as a client of such a service haven't changed. The client developers must start with reference documents and write code that constructs the appropriate message formats. This code might already exist in the service, but sharing it exposes the service implementers to all the issues associated with software distribution. It also assumes that the clients are implemented in the same programming language. The client applications have to make use of the messaging transport from the same vendor as chosen by the service implementers. Even if it were logical to standardize on a single vendor across the entire organization, this kind of vendor lock-in isn't necessarily a good thing.

The Too-Clever-by-Half Approach
Another approach is the demo that seeks to show how a SOA can be constructed using nothing more than the basic features provided by a programming language. For example, a Java application is developed that discovers all its components using JNDI. Each component implements an identical interface that provides methods that pass a java.util.HashMap as a parameter. This "loosely coupled" interface enables new data to be passed across APIs without recompiling.

Again, a number of SOA principals have been applied in this approach. However, it demonstrates the development of a new application in a single environment. These may be useful programming practices, but they're not solving integration problems, and they're limited to the microcosm of a single application.

Doing It Right
Each of these approaches set out to follow SOA principles, but fell short. The result is an architecture that is limited to a particular environment. In some cases, these limitations can be justified by specifying the limited set of circumstances in which the applications will be reused. However, if there's one thing that can be said without doubt, it's that over time, applications will be reused in ways that the original designer never imagined. Fundamentally, these approaches fail because they simply improve on, rather than replace, existing practices when it comes to solving integration. The result is a failure to deliver on projected cost reductions.

Where two distinct systems have to be connected, work must be done to solve the integration issues. A key issue is the question of where this work is done. The first example represents an exercise in tidying up an existing system and exposing it as is to clients. This pushes the integration work onto the client side. As a result, cost is encountered every time the system is to be reused. In an environment in which services are to be reused, any cost expended on the server side will be incurred only once. Doing it right requires the use of Web Services standards. The cost of solving integration issues is done on the server side when exposing the existing system as a well-designed Web Service. This will be recouped every time a new client reuses the service.

The most important Web Services standards are shown in Figure 1. There are a few ways in which these standards change integration practices and deliver on cost reduction.

The messaging-related standards are shown in blue. While Web Services messaging can operate on top of existing messaging infrastructure, it also represents a compelling alternative to proprietary messaging solutions at key points in an organization. These messaging protocols have been designed to work over the Internet to avoid having to choose one messaging solution for inside an organization and another outside. The work of the WS-I ensures that implementations of these standards are interoperable. Using these standards doesn't tie consumers of these services down to a single vendor. In fact, in large organizations there's growing acceptance that selecting a single vendor across the entire organization isn't possible. Even if it were, acquisitions would make such a practice an ongoing cost in terms of migrating the systems of the acquired companies.

The interfaces to services are described using WSDL and XML Schema. This provides an unambiguous description of the message formats. Tools support is provided for creating, validating, and parsing such messages, eliminating the need for developers of client applications to write code to construct the messages. It also eliminates the temptation for developers of the service to distribute sample client code, thus enabling them to avoid the support costs associated with software distribution.

WS-Policy provides a framework in which the Quality of Service (QoS) aspects of a service can be expressed declaratively. In particular, reliable messaging and security can be expressed this way. This turns what may have previously been development tasks into configuration tasks.

The Benefits of a True SOA
Using these standards ensures that integration issues are addressed once by the creators of the service, thus radically reducing the cost of reusing the services. It also makes the fewest assumptions about how the services will be reused. This enables the use of technologies such as BPEL to model business processes through the reuse of services. This is where SOA can deliver the greatest flexibility.

SOA advocates the reuse of existing assets to create new services. Figure 2 illustrates how to build on the benefits of reuse. The first tier of Web Services will solve many of the integration issues and provide a basis for adding value. However, they may still reflect some of the structure or function of the IT infrastructure rather than the business need. From these infrastructure services, new business services can be created that reflect the services performed by the business. It's these services that should be exposed for reuse by an organization. The interfaces and function of these services remain stable over time, because they reflect the core business functionality. For example, a bank has customers and provides them with accounts. In the history of banking the concept of accounts and the movement of money between them has changed very little, while the underlying infrastructure that supports it has changed radically.

Once created, this appropriate set of business services can be combined with each other and with new services to model business processes. This is where agility is of the greatest value. In the banking example the business service that provides a customer with a loan can be used in the bank by tellers or from a call center to provide telephone banking. Through orchestration, it can also now be used within a greater process that uses information about the purpose of the loan to sell car or holiday insurance to customers.

So Why Do They Do It?
There are a number of factors that motivate people to create something that is less that a true SOA. The as-you-were approach isolates the owners of the existing systems from exposure to new technology. It may also appear to cause them less upfront work during the integration phase of a project, as more work is pushed onto the client side (Figure 3).

However, in many cases the motivation is the perceived difficulty of supporting all the principles of SOA. This is the result of a failure to select the appropriate products to support the creation of a Service Oriented Architecture. The Enterprise Service Bus provides the necessary tools and servers to support the creation of a SOA based on Web Services standards. This will not only ensure that the principles of SOA are followed, but that the goals of reuse and cost reduction are achieved (Figure 4).