Girish Juneja is the director of SOA products at Intel. Blake Dournaee is currently the product manager responsible for Intel SOA products. Joe Natoli is a platform architect in the Digital Health Group at Intel. Steve Birkel is the Chief Technical Architect for Intel's Information Technology. This article is based on material in the book Service Oriented Architecture Demystified, published by Intel Press. All rights reserved..
XML is a big idea. Web Services takes XML one step further. It uses the generalized portable nature of XML to achieve universally descriptive interfaces and message exchange patterns. SOA, following suit, takes Web Services one step farther and applies service orientation to web services in an attempt to shrink the gap between technology infrastructure and business agility. It is only natural to look at this progression and ask what could be next. Which future trends have the potential to affect SOA? Which trends will engender the next step? The purpose of this article is to survey some of the currently emerging technology trends that have the potential to affect SOA and shape its future. Trends can be characterized as very specific pieces of technology or more ephemeral ideas, memes or points of view. Both can be very powerful in shaping the future of SOA. While it is true that almost any technology trend can be tied back to SOA in some way, we limit this article to those future trends that have XML as an ingredient. The reason why comes from our assumptions about SOA; that is, we believe that SOA conceived without a specific reference to XML becomes too general. Some of the technology trends to be examined in this article include the SOA backlash, SOA and Web 2.0, and SO*, the future of SOA.
SOA Backlash: SOAP versus REST
The first trend we will look at might best be described as an anti-trend or opposing undercurrent within the SOA community. This undercurrent, called the SOAP versus REST debate runs opposed to a certain standards laden version of SOA, one that is perceived as cumbersome and weighty, rather than agile. This particular undercurrent looks at the WS-* family of specifications and SOAP-based interactions in particular in a negative light. That is, WS-* is seen as a hodgepodge of complex layered technologies with no historical evidence of practical use, rife with vendor positioning. As the number of competing (and completed) web services specifications continues to grow, tension rises in direct proportion to the increasing complexity. In response to this phenomenon, a new meme has emerged that labels the WS-* family of specifications with the term WS-Heavy to describe its ostensibly weighty character. Complexity alone, however, is not enough to dismiss a new technology if it provides real benefits to business. What is the nature of this debate? The next few sections provide a brief outline of REST when compared to the WS-* family of specifications and tries to present both sides of the debate on equal footing. In the end, we hope to convince you that a hybrid approach is really the answer, as these two technology stacks are not mutually exclusive.
Framing the Problem
REST stands for Representational State Transfer, which is an architectural style derived in a doctoral dissertation by Roy Fielding in 2000. The dissertation itself is not an indictment of SOAP nor is it a position piece on why REST is superior to SOAP. Instead, it derives a certain abstract architectural style, called REST, from the basic web architecture of hypermedia, or simply put the collection of web documents and the specific interactions that have evolved from the inception of the Web. Given such a terse description, REST appears to be a theoretical model rather than a business enabler. However, if we examine REST further and follow its thread, we can understand how this simple architectural style has evolved into a vehement, nearly religious battle between two world views. At the very least, the presence of the debate appears to be slowing the growth of SOAP-based SOA interactions.
Numerous resources on the Web provide information about REST and SOAP and at times it can be difficult to tease out the fundamental pieces of the debate itself. In this section we will begin with the familiar, namely the concept of big bus, little bus as well as the concept of heterogeneous architecture, which we will characterize as simply a set of enterprise software, systems, or servers all running different operating systems and protocols. For the purposes of this explanation we will begin by assuming a worse case scenario: an enterprise with both B2B (business-to-business) integration requirements and EAI (enterprise application integration) requirements. Further, even though we refer to big bus, little bus, we will assume here that there is really no bus connecting these disparate domains. Some descriptions of REST also call this scenario the unconstrained architecture, which means there are no constraints on how various pieces talk or interact with one another.
Figure 1 shows a representation of worst-case EAI and B2B integration problems. We are using a shape metaphor to denote disparate components, software, or servers. Basically, we assume that each component is different and requires custom work to make the pieces talk. If we assume a completely connected set of disparate components counting each edge twice we will approach an n2 type of integration problem. You should note that this applies both inside the enterprise (EAI) and across enterprises (B2B). The picture shown in Figure 1 is a bounded problem-it describes an enterprise or business specific way of looking at system integration on two axes-intra-enterprise and inter-enterprise. It is also bounded in another way-by the way the businesses currently operate; surely businesses innovate, but for application integration this is generally a fixed-cost problem that maintains current business relationships with some return on investment and cost-savings rather than an enabler of hyper- growth. These additional enterprise and business-centric assumptions will eventually make a difference later on.
We also note that there is a larger version of this same problem, but it is unbounded-the larger version of the problem is the Internet, but more specifically, the Web itself. If we were to draw a picture of this problem, we could imagine it as an interconnected set of disparate shapes with no necessary bounds. To be clear, however, this problem is considered somewhat solved; REST looks at the example of this successful solution (which evolved using HTTP) to derive architectural constraints on the nature of the solution. Put another way, REST is in part an architectural style derived from those elements that made the current Web successful. Before we get to specific examples, we have to first look at the underpinnings of the theory itself. To help counter charges of undue bias, we go straight to the horse's mouth and develop a summary of REST based on Fielding's original derivation. This being said, we will not expound his entire theory, just the essential pieces to give us a solid understanding.