SOA's and Drunk Driving

Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.

Web Services vs. Service-oriented Architectures

If you have a Web browser and are interested in Web services you probably have not escaped the discussion around SOA, REST, Web services etc. I am going to let the REST argument rest for for the time being (pun intended), but want to share a few thoughts on Service-oriented architectures. By now most people agree that a service-oriented architecture is not a specific technology, but rather a design philosophy or architectural style. Web services technologies make implementing this architectural style convenient but are by no means the only technology choice. For example, one can build fine SOAs using CORBA, even though the nagging question might be "why would you?" (Steve V., please forgive me!).

Architectural Styles

So what is an architectural style? Roy Fielding defined it in his oft cited thesis as follows:

"An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style."

Essentially, an architectural style describes what elements we can work with (for example, filters in a Pipes-and-Filters architectural style or objects, interfaces and classes in an object-oriented architectural style. The style also defines the rules and constraints on how the elements can be composed. For example, in a Pipes-and-Filters style, filters have input and output ports that can be connected to pipes whose purpose it is to transport messages from one filter's output port to another filter's input port. One constraint is prescribes that you are not allowed to connect one filter directly to another filter.

There are more formal definitions of architectural styles, which enable the formal expression of the constraints in architectural design languages (ADLs). I touched on them briefly in a prior posting, so I won't repeat them here.

Service-Oriented Architectural Style

So what are the design elements and constraints that make up a service-oriented architecture? The elements of an SOA are services, self-contained modules that are universally accessible and advertise their interface contracts via some form of registry. Hao He has defined the following architectural constraints for SOAs:

1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

These principles are some of the main ingredients into making SOA's loosely coupled. Interfaces hide implementation details and services communicate by exchanging documents rather than by invoking methods directly on another service.

Evolution

We often underline the advantages of loosely coupled, service-oriented architectures by comparing them to the prior architectural style, namely distributed component (DC) architectures. This is only natural. It is hard to define the optimum architectural style for a given category of applications. Instead, it is much easier to learn from the shortcomings of the last attempt and to correct them based on incremental evolution. In the case of distributed component architectures, the shortcomings we set out to fix include the following:

• Vendor lock-in. Many DC architectures were based on proprietary protocols and implementations. In contrast, standards-based protocols support (at least in theory) free interoperability between multiple vendor products.
• Tight coupling. DC architectures typically link components directly to one another, making the solutions brittle. An asynchronous, document-oriented style of interaction allows more independent variability between components [3].
• The Transparency Illusion. Distributed components promised to hide remote communication from the developer by making the remoteness "transparent". While the basic syntactic interaction between remote components can be wrapped inside a proxy object, it turned out that dealing with partial failures, latency, and remote exceptions could not be hidden from the developer. It turned out that 90% transparency was actually worse than no transparency because it gave developers a false sense of comfort.
• Complexity. DC architectures extend the rich, but complex interaction between objects across the wire. One object can control the lifetime of remote objects, pass references, and rely on polymorphism and inheritance. This model turned out to be quite complex given the inherent complexity that distributed architectures add into the mix.
• Call Stack. While a call stack is an enormous convenience for monolithic applications it can quickly turn into a liability for loosely coupled, distributed applications. Waiting for a remote component to complete a task before continuing execution at the source tends to make distributed architectures unresponsive and brittle.
• Connectivity. Most DC architectures require reliable, permanent connectivity between components. They do not work well over wide-area, intermittent networks such as the Internet or mobile networks.

Note that some of these problems are inherent in the architectural style (e.g., tight coupling) while others are merely byproducts of popular implementations of the style (e.g., vendor lock-in). For practical applications, though, both kinds of problems are relevant factors in the adoption of Service-oriented architectures.

We can easily see how service-oriented architectures based on the Web-services standards and specs resolve these issues. They are (somewhat) vendor neutral, have a simplified, loosely coupled interaction model, and are based on an asynchronous document-passing model that allows for communication over partially connected networks.

So it seems that SOAs solve all our problems. Well, at least the ones we had with the distributed component architectures. But there remain two nagging thoughts. First, if SOAs are largely driven by the desire to cure problems in the prior style how can we be sure that SOAs are in fact the best approach or are they maybe a sub-optimization of the problem? And, more importantly, what other problems do they introduce?

Don't hit the Curb

Collective learning and vendor adoption cycles in our seemingly fast-moving field are often surprisingly slow. Object-oriented development took about a decade from early adoption (SmallTalk, early C++) to the preferred mainstream style of development. Given the long cycle times and the reactive nature of defining a new style via the weaknesses of the old style, we start to wonder whether we are really converging on a good style or whether we are swaying back and forth like a drunk driver who is swaying back and forth across the street trying to avoid hitting the curb. Every time the curb comes near the driver yanks the steering wheel in the opposite direction, causing the car to sway in the other direction until it is about to hit the other curb.

So are Web services and SOAs over-compensating the perceived issues with distributed component architectures? Are we heading for the curb on the opposite side? Sometimes I feel like that's what's going on. For example, distributed component architectures are too tightly coupled and brittle. A few levels of indirection can help resolve that but I think UDDI was aiming hard for the other curb by trying to make service discovery so generic that it became difficult to use. Likewise, we discovered that the object-oriented interaction model of instantiation and method invocation is too complex and chatty for network-based communication. So we fixed that with the document-oriented model. But is passing a document to a totally stateless service really sufficient for many real-life scenarios? What if I need a reply back? What if I don't have all required information available to assemble a single document? How about more complex conversations, transactions etc? Many of the WS-* specifications like WS-Addressing etc are trying to address these shortcomings. But then if I look at the dozens of WS-* specifications, where is the simplicity that we were aiming for?

Almost Home?

It will be interesting to see where the Web service evolution balances out or whether we'll hit another curb. It will also be interesting to see what the next best thing will be. One can't blame the business users for asking "How can you be sure you got it right this time? First you tell me terminals and mainframe hosts are all the rage, then it is client-server, then 3-tier, then distributed components and now SOAs. What's next?" I kind of have to agree with the end users but at the same time I have no idea what will be next. But we can be assured that once SOAs reach wide adoption all marketing departments are itching to define the next major trend...