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 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.
