The story of Web 2.0 and SOA continues - Part 1
It's nearly the middle of 2007 already and I've had occasion to sit down and look at where Web 2.0 and SOA software models have evolved lately. Partly it's because we're now seeing some of the bigger software companies seriously embrace lightweight SOA recently, and it's also because we're continuing to see more clearly that Web 2.0 and SOA really are largely (but not 100%) the same concepts that merely lay on different -- if fairly different -- parts of the software continuum. Here's the latest on this story.
For those not up-to-date on this trend, the fact that these two big conceptual foundations in the software business overlap extensively -- and somewhat unexpectedly -- appears to be a pretty important subject for a number of reasons. One is that SOA is the dominant design paradigm in business software today, with most software development projects using some subset of it as their primary organizing principle. The core principle of SOA is the decomposition of software into sets of services which can be used and composed into new applications that have a very high level of integration and reuse.
The second reason this convergence is important is that potent ideas in Web 2.0 have been mapped back from what seems to be working best on the often unruly, much less-organized, but considerably larger Web. Web 2.0 is more of a pragmatic extraction of what actually works best in online product design than a rigorous a priori engineering exercise. That both have arrived at largely the same endpoints on their own, but with very different priorities and focus in some areas, should not be understated.
SOA and Web 2.0 have also crossed over considerably around Rich Internet Applications and Ajax. Read ZDNet's Joe McKendrick recent post for the latest on this story.
I've written in the past about the considerable overlap and convergence of these two popular software models. From my contrived or converging article exploring the early possibilities to my first Venn diagram showing the similarities and differences, it's been clear that Web 2.0 and SOA are closely related. Understanding the exact demarcations and differences between the two, however, is driven by a couple of realizations. One is that from a product design perspective, understanding the advantages and disadvantages of each method prescribed for creating your software can dramatically effect what an online product can do in the market or for your business internally. Go with traditional SOA and you'll be able to leverage the advantages that its design center confers. Go with Web 2.0 ideas, and you'll be able to take on a different set of challenges and be successful in a very different environment and for different reasons. But make no mistake, it's fairly clear that choosing one of the other can really matter to a project's or product's ultimate success.
Both conceptions do make one very important assumption, that all software is part of a larger ecosystem bigger than itself. This idea has been with us for a while, ever since distributed computing. But the focus of software ecosystems has continued to move around over the years, from computing, to services, to data itself. What's the real core? What's the most important aspect of our applications? The O'Reilly concept of Web 2.0 tells us that data is one of the most important parts of our software applications these days, and this is backed up by citing one world leading product after another that took this idea seriously. SOA tells us that services are the center of composition. That services in a SOA also transport data is also important, but the focus in traditional SOA tends to be much more on the seams of our IT systems than what makes them the most valuable overall. These may be seemingly academic distinctions but the ongoing struggle of SOA implementation in many organizations and the runaway success of many a Web 2.0 application hints that this may indeed be some very important hair splitting.
Another important item: The bottom of the overlapping circle contains a cryptic acronym near the edge of the circle: WOA. This stands for Web-Oriented Architecture, a concept that I've written about several times here and here in this blog. It's an idea that basically states that software that goes naturally with the "grain" of the Web, extending the core infrastructure of the Web in natural ways, works the best. Fighting the Web and its standards is a losing battle and the products that embrace it and play to its strengths seem to do the best, time after time.
Traditional SOA is based on a protocol known as SOAP, whose strengths and weaknesses have been well-understood for a while now. SOAP is not Web-oriented for reasons too detailed and technical to go into here, but competing protocols such as REST, and now ATOM, are very clearly Web-oriented. SOAP, though the foundation for many an IT system that is increasingly being exposed to the Web, is generally not a great protocol for Web-facing systems. This is one reason that Google got rid of its SOAP search API late last year and it's why Amazon offered it's very commercially successful APIs in both flavors (SOAP and REST) and the market place chose REST.
My point is not to rekindle the seemingly endless REST vs. SOAP debates, but to point out that the industry itself seems to be confirming that this is an important lesson to learn. For example, my fellow ZDNet blogger, Phil Wainewright, and myself recently had the opportunity to look at Microsoft's innovative Project Astoria just before release at MIX 07. Project Astoria, downloadable today in CTP form here, makes it possible to expose almost any ADO-compliant database as a set of granular, queryable URLs in simple REST form.
The reason that the ability to expose our data in WOA form is important is this: One of the biggest arguments against traditional SOA is that there are literally thousands of software platforms and enviroments that presently exist in the world. And if they don't speak your unique flavor of SOA (SOAP and WS-*), interopability with them won't (and doesn't) happen.
With WOA, anyone that can speak HTTP -- the fundamental protocol of the Web -- and anyone that can process XML, which is to say just about every tool and platform that exists today, can interoperate and work together simply, safely, and easily and build applications on top of one another services. Importantly, mashups are a key outcome of the trend towards WOA and most mashups are based on REST or REST-like services.
So Project Astoria is literally an API server that Web-enables the vast repositories of data that we are awash in within our IT data centers and data warehouses. The fact is, our IT systems are still largely unexploitable and unreachable until someone makes them available in format easily consumable within our browsers and by the vast landscapes of partners and suppliers that exist in the giant network cloud of the Internet. Astoria is a solid example of how major software companies are now committing serious and disciplined effort to "WOA-ify" our traditional enterprise datastores and bring them into the 21st century to play in the world's largest ecosystem, the Web.
Along with Project Astoria, Microsoft has improved its WOA story considerably of late. Read a detailed (and technical) new piece on how Windows Communication Foundation (WCF) has extensive REST support.
But WOA is but one aspect of the SOA and Web 2.0 story. Another key one is the emergence vs. planned debate. So to is the role that users play, which is not a great one in SOA but a vitally important and central one in Web 2.0. The upshot is that the Web has provided a more proven model for how to integrate our systems, design our products around our customers and communities, and focus on the aspects that are most important to our businesses. SOA provides a more engineered, predefined, and formal view, that satisfies perhaps a larger number of important technical criteria but often seems to miss the very point about what matters; that people are central to software and it's our data that is irreplaceable and of supreme market advantage. And our software or services -- necessary as they are -- are like electricity and network bandwidth are to our IT systems; essential but not the primary value.
Next: Part 2: An update on Web 2.0 as the Global SOA.
Are you finding that Web 2.0 concepts continue to identify ways to do SOA "right?" Please share them in TalkBalk below.