«    »

Assessing Service Oriented Architecture

I have always been skeptical of Service Oriented Architecture (SOA) and web services since they first came on the scene. This was not necessarily a rational skepticism, but was instead more of a visceral response to all the hype. As the years passed by, SOA and web services stuck around and I heard it mentioned more and more. I began to wonder if there was something worthwhile hiding under all the buzz, but my skepticism kept me from looking closer. This changed recently when I took a week-long course on SOA from Web Age Solutions. Besides covering the course material, I did my own research online and talked with colleagues with relevant experience to get a sense for other's opinions of SOA. This article presents a summary of SOA and my assessment of it.

What is SOA?

There are many definitions of SOA. (See for example Wikipedia's definitions.) I consider SOA to be an enterprise architecture strategy where business logic is organized into services, and business processes are realized through the invocation of these services. I consider a service in the context of SOA to be a related set of automated business activities accessible through a well-defined interface. Services are often expected to be accessible remotely over the network, usually as web services using the HTTP for the transport protocol, SOAP for the message format, and compliant with one or more of the 'million' WS-* specifications. "SOA is more about good design and architecture than it is technology." (from Lawrence Wilkes). This is often confused, unfortunately, by all the vendor hype around particular products and specifications, especially web services.

A successful service oriented architecture needs to address three areas:
SOA Triangle of Services, Processes, and Governance

  1. Services: the units of composition for a service oriented architecture.
  2. Processes: the business processes using the services. Each business process is implemented by orchestrating together multiple services.
  3. Governance: the policies governing the development and maintenance of services.

I am hesitant to call SOA an architecture pattern. A pattern is generally defined as a reoccurring solution to a reoccurring problem. SOA qualifies as a reoccurring solution, but it is not clear whether it addresses a single reoccurring problem. The more hype-driven literature assumes that SOA is a given without any justification. In other cases, SOA is presented as addressing one or more of a collection of enterprise issues without any discussion of the context around these issues and the consequences of using SOA. I think SOA could be expressed as an architectural pattern, and that doing so would be beneficial in reducing the hype and the sometimes contentious discussion surrounding SOA. I feel that looking at the motivation, applicability, and consequences of SOA would be particularly helpful, and in the remainder of this article I will touch on these points.

Does SOA represent something new? I have heard it said that SOA is merely a set of "best practices" for enterprise I.T. - a collection of what has worked before. Certainly some details of SOA like the enterprise service bus (ESB) seem like a rehash of the message bus in enterprise application integration (EAI). The inclusion of business processes in SOA, especially executable via the business process execution language (BPEL), comes straight from the notion of automated work-flow engines. From the middle-ware vendors' perspectives SOA means a new 'stack' of products to sell. I suspect this has been a major driving force behind the SOA hype. As existing middle-ware such as Java EE servers becomes commoditized and open-sourced, it is rational for vendors to create new, higher-profit markets where this has not yet happened. My perspective is that SOA is at least an incremental refinement of what has come before: it does pull formerly disparate concepts together into a unified whole. Its explicit inclusion of process and governance seems unique, although I remain uncertain how those aspects will work out in practice. Whether or not SOA is something new or just the product of vendor hype, the question "does SOA work?" remains. Below I look at some of the benefits and weaknesses of SOA.

Benefits of SOA

SOA promises many benefits, but how many of these can be achieved in practice? Below I list the reported benefits of using SOA and evaluate each one.

  • Integration of legacy or stovepipe applications: Legacy or stovepipe applications, even those implemented in variant technologies, can be wrapped in a service and orchestrated with other, perhaps newer, services to achieve a business process. This mixing of old and new allows existing I.T. assets to be reused rather than needing to be rewritten, which is expected to result in cost savings. I feel this is a legitimate benefit, especially when such an application is not under the control of your organizational unit and cannot therefore be modified directly.
  • Bridging the divide between I.T. and the business: SOA explicitly considers business processes and thus links business goals and business use cases with the I.T. architecture through services. While I think SOA goes much farther in this direction than other architectures, I suspect that many of the normal issues that arise between I.T. and the business will remain. The people involved will still come from primarily from one side or the other and bring their existing viewpoints and biases which will inherently lead to conflicts.
  • Loose coupling: SOA encourages loose coupling through encapsulating functionality behind course-grained services with well defined interfaces. This allows the implementations of services to change without impacting users of the service, since other services and business processes will only invoke the service through its interface. This is similar conceptually to the use of dependency injection, where the code using an external resource knows nothing about the concrete implementation since it is injected by the container. While I think this is a significant benefit, bad design can still ruin it.
  • Reuse: Reuse is one of the more highly touted benefits of SOA. The theory is that the services can be reused to implement new business processes. Since each service operation represents a business activity, its reuse represents a significant savings in development costs. This is the benefit I am most skeptical of. It seems far too similar to the promises made when object-oriented programming was first becoming mainstream. While OO has many benefits, the level of reuse that does occur is far below what was initially hyped. There are a few hopeful signs, however, that SOA may actually enable a reasonable level of reuse. One of the key requirements to enable reuse is the proper management support, which SOA explicitly addresses through governance. Services are course-grained, so even a large corporation will have a limited number of them (less than 500 is a ballpark I have heard). This makes it easier to review the catalog of services and determine possibilities for reuse. And since the service operations have business meaning, both I.T. management and the business can better understand and commit to their reuse, unlike in OO where individual classes or even libraries are at too technical a level to be truly comprehensible to such people. A significant obstacle to service reuse, however, is that it requires the organization's business processes to become more standardized in how various business activities are performed, since the same services to perform these activities will be invoked by these different processes. In a typical large organization with independently-minded business units, perhaps with varying requirements, this standardization will likely be difficult to achieve without senior management involvement.

Weaknesses of SOA

There are a number of drawbacks and challenges to successfully using SOA, of which I highlight what I feel are the most significant:

  • Distributed Systems Problems: Making a system distributed is problematic. Martin Fowler's first law of distributed object design is "Don't do it" for this reason. The issues you need to deal with include the following:
    • Reliability: If any required service in your business process becomes unavailable then your entire business process cannot be executed. Even having systems with different scheduled maintenance windows can cause difficulties. One way to address this is to use asynchronous messaging as much as possible and make your messaging infrastructure high availability.
    • Performance: The performance of remote calls is much, much worse than local (in-process) calls. This is exasperated when using Web Services with the verbosity and extra parsing that XML and the various WS-* specs add. This is why service operations should be as course-grained as possible to minimize the number of remote invocations.
    • Transactions: For a typical application, database transactions are used to ensure data integrity. When multiple, remote services are being invoked this becomes much more difficult. One option is to use a distributed transaction, which requires that both the service messaging infrastructure (i.e. Web Services) supports distributed transactions, and that the underlying service implementations can enlist in these transactions. When wrapping services around legacy or off-the-shelf applications, this may not be possible. Even when distributed transactions can be made to work, they introduce yet another performance hit. Another option is to forgot about distributed transactions and deal with the consequences: this usually involves more careful design and the use of compensating transactions in the case of failures. It sounds dangerous to those such as myself used to working with transactions, but there are cases where transaction-limited systems have been made.
    • Security: The current security context - the identity of the user and the actions it is authorized to perform – often needs to be propagated to each service. Propagation is actually not that difficult, especially with the introduction of specifications like WS-Security which automatically include security context in the SOAP header. A harder problem is managing user identity and access privileges across separate, perhaps legacy, systems. Even if you introduce an enterprise-wide security service for all your applications to use, you still face the problem of dealing with off-the-shelf or legacy applications that do not use it.
  • Changing Services: Once services are defined, created and in operational use, changing them becomes difficult. One problem is versioning: what happens when the interface to a service needs to change? Especially troubling are interface changes that are non-backwards compatible. Frameworks in languages such as Java with explicit interfaces have already had to deal with this problem. One solution is to change all the consumers of the service at the same time the service changes: this requires significant organizational coordination and is frequently unrealistic. Another solution is to create a version 2.0 of the service, and leave the old service running but deprecated to allow time for consumers to migrate to the new service. This requires that both versions of the service are operational, which increases maintenance costs and is not always possible. Service implementations can also be changed without touching the interface. While a purported benefit of SOA, there is the risk that an implementation change actually subtly changes the semantics of one or more operations and breaks one or more of the consumers of the service.
  • Crossing Organizational Boundaries: For all the benefits of SOA to be realized, a number of organizational boundaries need to be bridged. This typically requires a change in organization culture, which is very difficult to achieve. Integrating services in separate, traditionally stovepipe, organizational units requires them to coordinate more closely, both during the initial development project and on an ongoing basis for maintenance. Effective management and reuse of services requires more effective communication between development teams and architecture within I.T, and potentially requires better alignment of separate organizational business processes with enterprise-wide processes. I've already mentioned bridging the divide between the business and I.T. as one of the reported benefits of SOA that is likely challenging to achieve in practice.

Other Viewpoints

As part of my research into SOA, I came across a number of sites with varying views and feedback:

What is your take on SOA? Please leave a comment and share your experiences.

If you find this article helpful, please make a donation.

«    »