SOA and Future Trends



June 06, 2008
URL:http://www.drdobbs.com/web-development/soa-and-future-trends/208402614

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.

Figure 1: A Worst Case Scenario for Enterprise Integration

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.

REST Explained

What is REST? As we have mentioned previously, it is an architectural style derived from the Web architecture. More specifically, it is a style derived from constraints applied to elements within the Web Architecture. This derived style is eventually defined with more concreteness in the form of fundamental constraints on components, connectors and data. In order to steer away from too much theory, we will first list and explain the five constraints Fielding thinks are important to the Web Architecture and then fully describe the three main classes of components that comprise the essence of REST. Fielding looked at the evolved Web and noted five basic properties: (a) Client, Server, (b) Client, Stateless-Server, (c) Client-Cache, Stateless-Server, (d) Uniform-Client-Cache, Uniform-Stateless- Server, and (e) Layered-Uniform-Client-Cache, Layered-Uniform- Stateless-Server. There is also a sixth optional property called code-on-demand but it is not important for the explanation given here. These constraints are no doubt confusing, but many of the terms used here have entered the everyday technical vernacular. What did Fielding really mean by each of these constraints? Table 1 provides an explanation of each constraint.

Table 1: Basic Web Architecture Constraints

It is important to note that the constraints Fielding describes, which are shown in Table 1, are descriptive of the Web at the time (circa 2000). He tries here to capture the essence of what made the Web successful in the form of abstract constraints rather than pay homage to one set of standards or vendor technologies. This being said, there is an underlying tribute to HTTP in his abstract architectural style. Once he has laid out the constraints of the Web, he derives Representational State Transfer as a new set of constraints over three fundamental artifacts: data elements, connectors and components. We believe that the most important part of REST, its subtle core, can be found in how the data component is described. The next section describes these components, with special attention given to the data elements.

Data Elements

In the context of traditional client-server interaction, such as an HTTP GET, data is transferred from client to server. In REST terms, a resource is de-referenced and its representation transfers from the server to the client. The important observation that Fielding made (and it now seems obvious) is that links are static and can represent an invariant concept, while the representation can change over time. This idea consists in the demarcation between resource and representation. While this sounds lofty, it is exactly the same idea used when a Web site publishes a link, such as the "latest" schedule for some fictional meeting such as "http://www.foobar.com/schedule.html." We can note that there are three concepts tied to this: (a) The resource ("the latest schedule") which is ostensibly invariant, (b) the link identifier ("http://www.foobar.com/schedule.html"), and finally (c) the actual schedule or document returned when the link is de-referenced-the representation. Fielding notes that any information that can be named can be a resource. The resource identifier term is used to describe the URI, but it could also have been a URN as well. So why is this resource concept important? Resources provide some familiar features such as interface decoupling as well as generality for the resource. That is, the resource can be manifested in more than one way; resources can realize one or more representations based on more specific client and server interactions, and these representations can be negotiated during the communication itself.

The second part of the data elements of REST includes the all important representation. This is where the term state transfer comes into use; Fielding looks at the Web like a giant state machine and the state transitions are initiated by and stored on the clients themselves (as the servers are stateless). Further, the next state of this giant state machine is considered to be captured in the representations of resources that transfer from server to client. This further implies that clients initiate state transitions of the Web in response to new state options that come back as server responses. It is at this point that we can begin to understand how the term Representational State Transfer (REST) becomes appropriate.

But what are representations? Representations consist of the data itself, metadata to describe it, as well as additional (optional) metadata to describe the metadata. In order to avoid getting lost a jungle of theory again, the reader can understand this simply as a message payload, a content-type, and possibly security information or routing information that is applied to the message or payload. Again, this is all still abstract, but Fielding's original thesis suggests HTTP as the model to be followed. Figure 2 shows a pictorial representation of the central concepts of resource and representation, and how they map to technology choices such as HTTP or even XML.

Figure 2: Resources and Representations in REST

Figure 2 shows three examples: A, B and C. In each example, a client is making a request to a server for the representation of a resource. Example A shows the representation in the abstract, the way Fielding conceived it. Example B shows the concrete implementation of HTTP with a content type to describe the payload. Finally, Example C shows another way of fitting into Fielding's framework with the use of an XML payload and an XSD, or schema definition, for the complete metadata. You should note that the last example is sometimes referred to as POX, or Plain Old XML.

The final two architectural pieces of REST are the connectors and components. These are less interesting because most of what makes REST important for our discussion is encapsulated in the data views just described. Connectors are the interfaces used by components. Fielding describes these as simply as client, server, cache, revolver, and tunnel. The first two are self explanatory. The third is a client-side browser cache or a web cache, the fourth is a DNS lookup library and the fifth is a tunneling protocol such as SOCKS or SSL/TLS. Each of these components has interfaces with "in" and "out" parameters. The "in" parameters consist of request control data, a resource identifier, and representation. The "out" parameters consist of response control data, resource metadata, and representation. The four components that utilize these connectors are the origin server, gateway, proxy and useragent. Fielding notes further that some components can play a dual role as client and server (such as a proxy) and terms these components intermediaries within the architecture.

As noted previously, the Fielding dissertation and the definition of REST appears benign-it does not throw down any overt challenge to SOAP, nor does it appear to be solving the same problem as SOA or even SOAP. In fact, the REST architectural style appears to be a description of essential elements of the Web. If this is the case, what is the nature of this debate? Now that we have some of the theory behind us we must probe further and examine not what REST is, but what REST has become; or rather, the meme it has transformed into.

A CRUDy Central Claim

In the REST world view, resources are primary. The role of HTTP is to perform one of four functions on resource concepts. These functions are POST, GET, PUT and DELETE. Described in order, POST implies the creation of new resource information, GET implies the reading of existing resource information, PUT implies the updating of existing resource information and DELETE implies the removal of resource information. If we look at these four HTTP request methods, we will find they map to the well-known verbs from the data storage domain: Create, Read, Update and Delete. REST advocates note that (and this is some extrapolation on the original REST model) these four verbs encompass all we might ever want to do with resources on the Web. If we add XML to HTTP as a payload and provide schema descriptions, we can fit a generalized cross-platform data format square inside of a proven, now nearly ancient technology such as HTTP. REST advocates proceed with an inductive sort of argument that builds upon the tremendous success of the Web. And here at last is where we really get to the core of the debate: Resources on the Web can have at least two representations, (a) a hypermedia or hypertext representation for humans, and (b) a machine-readable representation for solving "web services" or SOA types of problems. REST advocates look at the technology stack surrounding SOAP and SOA and chuckle a bit on the inside-we already have a proven, scalable technology (HTTP) that solves a nearly unbounded integration problem. If we can solve the unbounded version, this surely should apply as well to the bounded enterprise version of the problem. Why reinvent the wheel? The assertion of REST advocates is that the diversity of resources should be immense, but the number of verbs (Create, Read, Update, and Destroy) should be scarce. All that needs to be done can be done with CRUD, or so it is claimed. This does seem like a grand claim indeed: how can all enterprise business functions, both B2B and EAI be encapsulated in just four verbs? Indeed, the most common objection against REST is this perceived limitation. Before we examine this aspect of the debate further, however, we will examine a real-world example service that offers both REST and "traditional" SOAP interfaces to see how the messages manifest differently on the wire.

A Storage Service Example

The example that follows is adapted from a commercial web storage service, but the specifics have been changed to mask the actual service vendor. This example is central because this particular service offers both SOAP and REST type interfaces, which are prime candidates for looking at the similarities and differences between the approaches. The idea behind such a service is to allow web developers to store an arbitrary amount of data into keyed containers, which can then be used for retrieval at a later point in time. This particular service charges users of the service based on bandwidth of objects stored and retrieved from these logical containers. The service considers objects to consist of metadata and then an opaque object payload. The idea behind such a service is to provide a scalable, reliable, low-latency generic data store. You can think of this type of storage service as a building block for just about any distributed web application. Figure 3 summaries the basic concepts of container, key, and object.

Figure 3: Basic Concepts for a Storage Service

In Figure 3, objects are stored into logical containers. The containers are named along with a key that allows the service to map from a combination of key and container name to the object itself. Further, objects also contain some metadata, which is in the form of media type information along with the octets that comprise the opaque payload. You should note that in this model, the containers can hold more than one key; in fact, one per object stored in each container. The operations allowed on these storage service artifacts are further defined as follows: (a) Container Creation, (b) Object Storage, (c) Object Retrieval (Non-Destructive), (d) Object Deletion, and (e) Key Listing. In addition to these basic operations, there are also other practical issues such as permissions (for others to read and write buckets) as well as authentication to the service itself. Other operations could also be added, but this represents a basic set for our purpose here.

So how do these operations map to real requests and responses in REST and SOAP? What do the messages on the wire look like? The first thing to remember is that with REST we are really only dealing with four fundamental operations applied to resources. This implies that REST messages come in the form of only GET, POST, PUT and DELETE whereas with SOAP, we can express the method itself within the request. Tables 2(a) and 2(b) shows the mapping between the abstract operation name, the equivalent REST operation and SOAP method. You should note that brackets in the following table (shown in bold) denote variables that would be filled in with actual values. Also, Table 2 just shows the request side of the messages for brevity.

Table 2(a): Mapping between REST and SOAP

Table 2(b): Mapping between REST and SOAP

You should note that Table 2 does not show complete requests, just the essence of each request. The REST requests are straight HTTP requests and the only thing omitted in the samples shown would be the HTTP headers. In this case, the headers would contain authorization information in the form of a keyed hash that identity and authenticity of the requester. Because the requests are stateless, this authorization information must be present in each request. Conversely, the SOAP requests shown are really only the SOAP body. While HTTP could also be used as the transport for SOAP, there is no guarantee that it will be, so any extra information such as authorization elements must be expressed as XML elements inside the SOAP request. Further, the SOAP example here leaves out any SOAP headers as well as any namespace declarations that appear in the body of the messages. Finally, the SOAP example also makes use of SOAP Attachments, specifically in the case where an object is stored at the service.

As you ponder the differences between each style of request, it should be obvious that the REST-based messages and model seems much simpler. It achieves the same basic functionality by riding on top of mechanisms already provided by HTTP. However, does this simplicity scale when the services become more complex? How would REST handle real world scenarios that go beyond a basic storage service? What about reliable messaging, transaction support, and asynchronous communication styles? How would message-level encryption and digital signatures be handled with REST? SOAP proponents may argue that the storage service works better as a REST architectural style simply because it is such a simple service and it already manifests itself as create, read, update and delete operations. REST proponents typically counter with observing that if we tied down the number of verbs, the diversity in nouns (or resources) will account for the additional complexity. REST proponents firmly believe that all problems in computing eventually fall into the CRUD domain, and all that must be done is the identification and definition of these resources. We argue that software complexity never really decreases, it just shifts around. Thus, if we use only four verbs, the diversity and complexity of the nouns must increase. This is typically done by REST proponents with careful examination of the domain and a liberal definition of what a noun can be. For example, if we were to model the relationship between users and groups with REST, we would not attempt to create nested nouns, where users fit inside groups and groups contain a set of users. Instead, we would create a set of singular relationships between each user and their group. Once we identify the noun as a relationship we can apply CRUD operations to it.

This design paradigm surely sounds elegant, and in fact it may be true. However, the time needed for this "discovery of nouns" may not be aligned with the needs of business.

Evaluating REST and SOAP

As mentioned in the previous section, SOAP proponents would look at REST architecture models and make claims that HTTP is designed well for a stateless web, but the REST architectural style doesn't account for all that is required in a full-fledged SOA. The central argument given can be characterized by pointing out additional requirements that only a SOAP framework can provide. Some of these requirements are listed as follows:

  1. Reliability: Many verticals, such as healthcare and financial services, have strong requirements for reliable transactions. In the case of healthcare these could be long-running transactions where state must be stored over a long period of time. While it is yet unproven, SOAP does have ongoing standardization efforts to provide reliable messaging between SOAP endpoints, complete with delivery assurances appropriate for different use cases. As we have seen, REST is fundamentally stateless and currently lacks this capability.
  2. Description: When messages are sent with REST, the de-facto standard is to make the payloads opaque or use POX (plain old XML). If we consider XML schema to be a type description language, REST does have a mechanism for describing payloads, but no service description language. REST proponents would argue that API descriptions are not applicable with REST because there are only four operations, but this ignores the standardization work that also includes policy information as part of SOA service descriptions. SOAP proponents would argue that service descriptions allow for richer types of messaging interactions to be universally understood and processed, rather than the standard request/response exchange pattern defined by REST.
  3. Message Level Security: REST can piggyback easily on top of point-to-point security protocols such as SSL or IP-Sec, but it has no mechanism for persistent security properties applied to the messages themselves. If we remain in the context of POX, one could make an argument that raw XML Security standards could be used to sign and encrypt payloads, but there is no standard for where to place identity tokens in REST style messages. SOAP, by contrast, has a proven message-level security mechanism in the form of OASIS WS-Security that has a proven track record of interoperability.
  4. Publish/Subscribe: Many business verticals rely on publish/subscribe type messaging coupled with message-level routing to publish information to a diverse number of endpoints over an application level network. The REST model doesn't directly apply to environments that use anything other than a request/response message exchange paradigm. SOAP, by contrast, has standardization efforts that allow for one-way messaging as well as topic based publish and subscribe standards. SOAP also has header mechanisms that allow portions of messages to be targeted at certain intermediary targets

As it stands, SOAP appears to be more closely-aligned with business vertical requirements and REST appears to be more closely-aligned with the nature of how the Web works. Truth be told, it would be cumbersome and weighty to use SOAP for something like the storage service if none of these additional SOAP features just described would ever be used. SOAP frameworks and the WS-* stack are often criticized for being myopic and ignoring the success of the Web. In reality, this stack of specifications is vendor designed and it is no mystery that it trades features for simplicity. The "Web" as such may have little to do with solving the bounded integration problem shown in Figure 1. In short, it is not the goal of WS-* to solve the unbounded integration problem, but merely provide business value for the here and now. As we segue into the next section, our discussion of the unbounded integration problem and REST will be taken up a level in terms of the Web 2.0 phenomenon. From this elevated viewpoint we look again at the relationship of SOAP and REST, but in the broader sense of SOA and Web 2.0.

SOA and Web 2.0

Considered as a precursor to SOA, the term web service was terrible. In the early days of web services, there was a need to continually disambiguate a "web service" from "services on the Web" as they were commonly understood. A service on "the Web" was just that, a Web site such as Amazon.com or Expedia.com, something very different from an XML-based, cross platform interface for application communication. As time passed, however, web services passed into SOA and "services on the Web" passed into Web 2.0. At last, at least in their naming, the two can finally be differentiated. There are, however, forces at play that put SOA and Web 2.0 concepts in a special relation to one another, as if they were two different realizations of a single concept. The purpose of this section is to critically examine this relationship. Specifically, we are interested in what subsets of the Web 2.0 idea are relevant for SOA, especially in terms of the practical or business level requirements.

Current predictions put SOA and Web 2.0 in a type of schizophrenic relationship: some blog pundits claim they are convergent while opposing theories claim they are divergent. In order to get to the bottom of the matter, we will have to provide an exposition of the defining components of Web 2.0 and then examine which parts or subset of Web 2.0 really bears relation to SOA in an enterprise setting. The reader may find this particular section a bit loftier than others, but the trends we are dealing with have an amorphous character that tends to escape formalization.

What Is Web 2.0?

For the uninitiated, the term Web 2.0 currently refers to a cluster of concepts that characterize the direction in which the current Web is evolving. Due to this evolutionary nature, there is an inherent danger in pinning down and conclusively describing the current state of Web 2.0. It can be done, but only for a given point in time, as the Web 2.0 phenomenon is capricious and undergoing rapid change. Figure 4 shows our interpretation of the Web 2.0 cluster that includes what we believe are the most fundamental ideas.

Figure 4: A Basic Web 2.0 Cluster Map

Compared to other descriptions of Web 2.0, our six concepts may seem minimal, and we recognize that there is much more to be discussed for a full treatment of Web 2.0. Here we aim only at its essence. The totality of Web 2.0 is difficult to grasp at once because the Web 2.0 phenomenon is really more of a social construction. The enabling technologies behind the success of the Web 2.0 phenomenon aren't necessarily new or revolutionary. In fact, the six concepts described in Figure 4 can be arranged by means of a derivation from emergent Web 2.0 technology memes that are themselves derived from relatively ancient technology building blocks. The term ancient is used half jokingly to convey the short shelf-life of most technology (but clearly not all) standards.

You should be aware that Figure 5 introduces new terms and acronyms not yet discussed or defined-we will treat it as a sort of roadmap for this section of the article.

Figure 5: Figure 5: The Derivation of Web 2.0 from Memes and Technology Building Blocks

Figure 5 is quite busy and demands some further explanation. First, arrows represent antecedent conditions, which simply mean that the referring concepts play a central role in the derivation of the new concept. Note that the arrow styles (dotted and dashed) are included for the sake of readability. Figure 5 should be read backwards from right to left to see how the six core Web 2.0 concepts are composed of first emergent Web 2.0 memes, which are themselves tied back to real technology standards. The timeline shown on the left edge of the figure only applies to the left side of the figure-that is, to the left of the dotted line. It is shown to highlight a major difference between SOA and Web 2.0, which is that while SOA is undergoing rapid standardization that includes new technology building blocks, the major technology enablers of Web 2.0 have been in place for many years. This is the core reason why we conceive Web 2.0 as a largely social construction that innovates based not on novel technology, but instead innovative ways of using old technology.

We should spend some time and further explain the center part of Figure 5, labeled Emergent Web 2.0 Technology Memes. What does this mean? The term meme used here refers to a concept or word that takes on a life of its own, evolving within its domain of use. For Web 2.0, we argue that the memes that seem revolutionary, such as the REST model (as described in the previous section) or AJAX (the use of JavaScript to achieve partially refreshed pages) will pass from new ideas to old ones. This simply means that the architectural ideas embodied in each of these, which seem at once so new and innovative, will become the normal way web applications work. That is, these memes serve to unseat old perceived limitations of the Web, and once this happens they will pass into historical footnotes while new, yet undiscovered memes take their place. Each meme should be read and understood in its forward and reverse derivation. We summarize the three memes in Figure 5 as follows:

The Web 2.0 Endgame

According to Figure 5, if we look at the core concepts, three of them are shown to derive what looks to be an end-state for Web 2.0, which is software as a service. This further promotes the web browser from a client perspective to a status similar to the operating system. If new applications of the future run on the "the Web" then we can think of the Web as a new operating system and the client side browser as the operating container. This view is certainly a threatening one to traditional ISVs that conceive software in more traditional terms and it remains to be seen if this proverbial end-game will play out as predicted.

An AJAX Detour

Before we examine the deeper relationship between SOA and Web 2.0, it is useful to pause and examine AJAX in more detail as it is one of the important emergent memes of Web 2.0. As mentioned earlier, AJAX stands for "Asynchronous JavaScript and XML", but has grown to mean any web application that exhibits rich user interface design techniques. The most famous example and most often cited example of AJAX techniques is Google Maps. The key innovation here was the realization that partial page updates can be managed through JavaScript. That is, the old "mold" of web browser request and full-page server response or refresh was broken. It was now possible for partial redraws to occur through the use of the (now almost infamous) XMLHttpRequest object available in both Microsoft and Mozilla based browsers. This object allows a web browser to spawn additional HTTP requests in an asynchronous (non-blocking) fashion. Generally, data is passed back and forth from the browser to the server in a JSON or XML representation. Then, JavaScript manipulation of the browser document object (DOM) can be updated in a partial manner. In short, this trick is the beginning of the browser as the next operating container for Web 2.0, and the success of AJAX relies in part on the performance of the JavaScript engine. Poorly optimized JavaScript runtime engines can wreak havoc with complex AJAX interactions, which may tax the JavaScript runtime when compared to a Web 1.0 Application. In some cases, the performance of AJAX applications across browsers can be drastic. The continued success of AJAX-type web clients will be closely tied to how well major browser vendors can optimize for this usage model.

The AJAX meme is a bit like the story of fleas at the circus that are trained to jump only a certain height with the use of an artificial boundary. This was commonly achieved by placing the fleas in closed jars of various heights. For a long time, this same type of artificial boundary existed in the form of the full- page refresh paradigm. The capability existed in the browser, but it took a social phenomenon or realization that the limit was in fact artificial. Now that this limit has been removed, we are seeing not only a flood of AJAX based web applications, but also complete frameworks and toolkits for building AJAX user interfaces. Some examples of AJAX-style services include Google Docs, Spreadsheet and Calendar and Zimbra Collaboration Suite. Some examples of popular Web 2.0 frameworks include Google Web Toolkit (GWT), Adobe Flex, and Dojo.

SOA and Web 2.0

We now have a characterization of Web 2.0 split into three fundamental pieces: (a) fundamental technology building blocks, (b) central memes, and (c) evolving concepts and predicted end- state. You may have noticed that SOAP is shown as a fundamental building block for Web 2.0, but doesn't seem to go anywhere, as if it were treading water in a "Web 2.0 Ocean." In reality, there are plenty of Web 2.0 style-applications that provide SOAP interfaces, and to be fair, it could be classified as a referring concept for developer interfaces. However, it is shown here as disconnected to emphasize two further points, first that the SOAP versus REST debate puts REST style interfaces (due to their simplicity) in a better position to achieve the Web 2.0 vision, and second, SOAP is really a vendor driven technology designed for enterprises rather than the smart mob of the new Web 2.0 world. Yet, despite this apparent indictment of SOAP, it appears to be connected to Web 2.0, at a basic level. Figure 6 shows this intersection: SOA, as conceived for business and Web 2.0 are really just realizations of the Abstract SOA Model (SOARM).

Figure 6: The Intersection between SOA and Web 2.0

Figure 6 is another busy figure, but if you focus on the middle portion, we will see the familiar abstract SOA building blocks. These include capability, service, interface, and consumer. If we take each of these core concepts to their logical conclusion, tempered by either SOA or Web 2.0 type requirements, we can see how these fundamental building blocks derive Web 2.0 in the form of browsers, REST, stateless patterns, CRUD/Resources, and finally the endgame, software as a service. Similarly, if we look at the SOA business level requirements, the same fundamental building blocks derive the heavier SOAP WS-* stack really designed to address EAI and B2B business requirements. Naturally these include more "complicated" processing at the message layer such as publish/subscribe, reliable messaging, message level security and the need for SOA to broker or integrate with legacy style protocols such as vendor MOM (message-oriented middleware). You should note that both problem domains include the standard lightweight client browser, but in the case of the SOA business requirements, the browser is an indirect tool, often contacting a gateway or intermediary that initiates a series of SOAP requests. This contrasts the primacy of the browser for the Web 2.0 phenomenon, especially the mass- market, "smart-mob" aspect that drives the evolution of Web 2.0. Continuing the comparison, business requirements drive SOA to adopt business functions encapsulated within service containers, rather than a fixed set of verbs. This diversity of business functions is a natural side effect of EAI, where legacy functions take on new audiences but must maintain their original semantics and intent. Moreover, business functions are not bounded by the CRUD model, which allows them capture more concisely the meaning and intent of B2B interactions, which actually bridges the gap between technology and business instead of wrapping it in the elegant CRUD and Resources model, which is really another layer of indirection from the business perspective. You should also note that we have reintroduced the terms bounded problem and unbounded problem. The first refers to the nature of enterprise business requirements as falling generally into one of two camps (EAI and B2B), while the second implies the complete unpredictability of innovation on the Web. It is no mystery that in order for the innovative landscape of Web 2.0 to remain fertile, its core tenets and technologies will remain simpler and more agile.

What should we make of this intersection? The fact that Web 2.0 can be derived from the abstract SOA model implies a dilemma: either SOA-RM is in fact primary and Web 2.0 is really an SOA coupled with a mass market "smart mob" that engenders explosive growth, or the SOA-RM model is so abstract and general that it can be used to derive just about anything. Unfortunately, both horns of this dilemma appear unsatisfactory; SOA-RM is general, and specific technologies must be specified in order to give it meaning. We answered this initial question by providing XML as such a building block. However, it turns out that XML is also a primary building block for Web 2.0. If we choose the second path and consider SOA the father of Web 2.0, we will have a social coup on our hands as the two really aim for different goals: one is a social phenomenon and the other is a business enabler. Aside from clearly different end goals, there is a social rift between the pure viewpoint represented by Web 2.0 and the businesses that aim to profit off this new natural resource. This being said, as general is it is, SOA-RM captures something essential about how software systems should model businesses in a service economy, and as far as we are all consumers of services, whether in the context of Web 2.0 or B2B, the core SOA-RM model appears to be deep-seeded and relevant as ever.

SO*: The Future of SOA

The bulk of this article aims to present a vendor-neutral characterization of future trends likely to have an impact on SOA. While not exhaustive, the two trends covered thus far give insight into the value SOA has for businesses as well as the arguments and viewpoints shared by its critics. In this final section, we will step away from a completely neutral view of the future of SOA and give some hints as to how Intel sees SOA moving beyond the purely abstract model to more holistic view. This view of the enterprise is called SOE, which stands for Service Oriented Enterprise. The SOE idea suggests that service orientation will be eventually be endemic not only to software, but also to infrastructure as well. As a software development trend, SOA has the potential to permeate internal software architectures. This downward influence of SOA is seen in architecture models such as SCA (Service Component Architecture) that describe SOA not as a solution to B2B or EAI problems, but as a model for software architecture.

Carrying this thread even further, we can imagine the same model eventually applying to infrastructure and operating systems. Once a component view of software becomes prevalent throughout the operating system, hardware and virtualization techniques can be used to provide finer grain control of services themselves, tied back to hardware. This allows for more complex resource allocation in the datacenter as well as finer control of individual components. This view is also closely aligned with grid computing, which is seen as a panacea for exploding datacenter resource costs. This view of infrastructure supporting SOA is called Service Oriented Infrastructure, or SOI. Figure 7 shows a characterization of SOE in terms of SOA and SOI.

Figure 7: SOE in terms of SOA and SOI

Figure 7 can be understood as two converging trends. Considered top-down as a business driver, SOA will permeate software further, moving from an integration centric solution to a core software architecture methodology. Once this trend is in place, hardware and infrastructure can move to align with SOA to complete the final bridge between not only business and software, but business and infrastructure and hardware. Again, this idea must be tempered with a dose of skepticism, but if the abstract SOA model is really fundamental to business, then the realization of SOI seems to be a likely outcome.

Where do we go from here? This article has focused mostly on future trends that apply to SOA at a software level with Web 2.0 as the obvious contentious gorilla. SOI considered as a separate topic has not been treated here, but its component topics such as SCA, virtualization and grid computing are ripe topics for a bottom up type of treatment. Overall we believe that the core ideas of SOA, especially its importance for business, remain strong. As we have tried to show, Web 2.0 and RESTstyle approaches are really facets of an underlying unifying service orientation concept expressed for different audiences.

Summary

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.