by Nicholas Petreley

SOA, WOA, Web 2.0 and Other Picture Post Cards

Jun 27, 20084 mins
DeveloperWeb Development

The success of service-oriented architecture will hinge on its roots in Web-oriented architecture.

Service-oriented architecture (SOA) is going to have a tremendous impact on business, but it is going to get there via Web-Oriented Architecture (WOA) and Web 2.0. Right now, people make the mistake of thinking that SOA and Web services are interchangeable terms. They are not, but they should be, and I believe they will be (more or less) in the future.

SOA is problematic in its current form because it pushes various standards created specifically to address the needs of SOA. Yes, you read that right. It may seem counter-intuitive that standards which are intentionally designed to solve a specific problem would not lead SOA to success, but a brief history of standards shows that de-facto standards are the only standards that matter.

“Best” doesn’t matter. When have you ever seen the best technology win, except by accident? I learned this lesson the hard way when I used to predict the success of OpenDoc and other implementations of CORBA. CORBA is a brilliant standard: a superb middleware approach to network components. CORBA could even be ideal for SOA from a technology perspective. But CORBA never became a de-facto standard for widespread deployment. For one thing, CORBA was too bulky during the birth of the Internet. More important, it had a fraction of the mindshare of competing solutions. In the end, it was squeezed out by SOAP, ActiveX, and all the other solutions-du-jour.

Furthermore, building an SOA infrastructure from scratch demands a great deal of effort based on promises made by SOA that have not yet been demonstrated. SOA still has to prove itself through successful deployment.

For some examples of SOA deployments in various stages, see:

  • Open-Source SOA Proves Valuable to Business Processes
  • SOA Migration: An Airline Keeping Its Feet on the Ground
  • Clear Channel Broadcasting Better IT Integration Between Software Development and Operations

Fortunately, SOA and WOA are similar enough that those who want to implement SOA can sit back and watch WOA and Web 2.0 developers work out the kinks in their systems. As such, WOA and Web 2.0 developers are creating the de-facto standards necessary for the foundation of SOA. Granted, WOA and Web 2.0 lack features necessary to make SOA live up to its promises, but anything that SOA needs that WOA lacks can be patched into WOA as needed once developers pour the de-facto foundation and it sets.

One can argue that WOA and Web 2.0 aren’t delivering on their own promises, and one can even argue that some implementations of Web 2.0 are patently absurd. I don’t blame those who find it laughable to do word processing with a Javascript application in a browser. But the viability of what Web 2.0 and WOA can offer in the long run are indisputable. Web 2.0 already demonstrates that distributed services minimize duplication of effort and provide access to collections of data which would be far too difficult to duplicate, even if it made sense to store the data in multiple locations.

Face it. Cloud computing, software as a service (SaaS) and other implementations of distributed services are here to stay, because the advantages are proved by a handful of successful implementations. Amazon and Google Web services are highly successful, and many AJAX-based applications knock our socks off because they leverage Web sevices correctly. It’s probable that web-based productivity applications will see their day, but even if not, Web 2.0 and WOA have already demonstrated their prowess.

Finally, it could be argued that a de-facto standard foundation, simply due to its nature of being a de-facto standard, is every bit as important to SOA as the technological greatness of the standards. SOA will stand or fall depending on its usefulness, and its usefulness revolves around the ability for applications and services to interoperate seamlessly. It must therefore be relatively easy for an application to discover and communicate with a service. The closer a service conforms to a de-facto standard, the easier it will be to discover and use that service properly.