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's rush 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.
The economics of integrationSince SOA is more of strategy than a product or an architecture, it has a fundamental motivation problem. In our industry, strategies are sold in the form of consulting and training. Investors don't like consulting and training because you can't really build a multi-billion-dollar company on consulting and training. The industry likes licenses and subscriptions.
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?That said, you can buy a complete SOA product suite from nearly any large tech vendor. Due to poor standardization, however, most of these products won't really integrate with any other vendor's products. This is partly due to a key, missing component from the SOA diagram above: the service registry. Sure, every vendor has one, but every standard proposed until now has failed to gain serious momentum. As a developer, I had always assumed that one day they'd plug into the Java Naming and Directory Interface API or System.DirectoryServices in .Net and I wouldn't have to worry about it. So far, it hasn't happened.
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 doThe marketing steam ran out of SOA a while ago. Instead, the industry is focused on big data and cloud computing. But the cloud solves none of these integration problems. The cloud will not stop silo computing as the predominant industry standard. In fact, abundant commodity computing power may yield a bigger mess.
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 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.