A few years back, SOA (service-oriented architecture) was all the rage. Vendors rushed to remarket everything as SOA, and SOA-washing was the new greenwashing. But in today'srush to the cloud, have we abandoned SOA? If so, we're in trouble.
I was late to SOA. When Bobby Woolf sent me an early copy of "Enterprise Integration Patterns," I didn't get it. I had been working on performance and scalability rather than integration. A few years later, after JBoss was sold to Red Hat, we had one final blowout company party. I was standing amid some of the brightest minds in the industry when someone asked, "What the heck is SOA?" No one could answer except the marketing guy.
[ Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
SOA isn't a product. It isn't even an architecture. It is a strategy or maybe even a philosophy. The short version is, as Amazon's Jeff Bezos famously summed up, "everything is a Web service." SOA services are also discoverable and ideally event-producing or event-driven. Below is a common example of a typical SOA meta-architecture.
IT departments also love to buy integration products, but hate to use them for integration. Remember when portals were the hot ticket? Every corporate IT department created its own portal; no one created portlets. Internet companies did the same -- every company built its own portal. Now every department will buy its own SOA server.
Integration requires not just technical consulting, but management consulting à la "House of Lies." No integration technology can force two corporate departments to talk and share data. For that, you need both vision and hard-nosed, hands-on management. You need a corporate structure that supports that vision. In other words, you can't really buy a SOA product and achieve SOA through purchasing alone.
Is there a directory standard at long last?
UDDI was the Web services standard that was supposed to emerge, but failed to gain any kind of significant traction. IBM, one of the key supporters of UDDI, decided to roll its own with its WSSR product; later, along with other vendors, it published S-RAMP as an alternative. If you'd like to know more about S-RAMP, tough luck -- nearly all of the pages at OASIS, its specification group, return a 404.
What good is an integration strategy without standards to drive interoperability between vendors? Truth be told, you don't even need to buy an SOA product to achieve a SOA strategy, but it would certainly be nice if you could catalog and locate services between vendor products with an SOA purchase. Don't get me wrong, two REST or SOAP services can still talk, but it is point-to-point integration by name. This is a real shame for some of the larger organizations that I work with. You sell your soul to one vendor and their directory (such as WSSR), or you do point-to-point integration by name.
Everything I do is cloud because I say cloud before everything I do
A host of vendors will sell you a public or private cloud solution, but you still need a strategy that will let you integrate all of your data and logic. That's where the value of SOA lives on. It's even more important now that the industry is cloud-washing all of its products. As software developers, we should probably breathe deep on the way to the cloud and take one last crack at this integration strategy.
This article, "Long live SOA in the cloud era," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.