In the abstract, SOA is fairly simple to understand. In fact, I recently stumbled across an easy-to-follow definition on a blog written by Luciano Resende, a senior software engineer at IBM -- though it was originally written by the research firm, Computer Economics.
"SOA is a better way to develop software, by using the basic building blocks of 'services.' Services are self-contained, stateless business functions, each of which accepts requests and returns responses through a well-defined, standard interface."
There's more to the definition, including the requirement that services written in one language be able to interact with services written in a different language, and so forth. But, essentially, it's simple and understandable.
But when you apply SOA in the real world, particularly at enterprise-class companies -- it can be, in the words of my high school government teacher, a mell of a hess.
A stat recently popped up in my e-mail that drove home how tangled SOA can become. ebizQ recently ran a survey on SOA Strategies and found that almost 75 percent of the respondents had more than five separate simultaneous SOA efforts across their organizations. Five!
The e-mail was to promote a March 12 Webinar on how ESBs can be used to federate between SOAs silos. Those who sign up to attend will receive the complete Service-Oriented Architecture Strategies survey results.
I think that one result speaks volumes about SOA's complexities. This week, I've shared with you articles focusing on the complexities of SOA, starting on Monday with an article by Ronald Schmelzer of ZapThink, challenging you to rethink what constitutes a SOA, followed by a pointer to Jeff Pollack's look at the unique challenges large companies face with data integration and SOA.
Today, I'd like to add another issue to the list: virtualization and SOA.
Frankly, I have a hard time wrapping my mind around virtualization anyway. Oh, I get the general idea, but I'm unsure how it will play out long term. For instance -- I've read articles about virtualizing operating systems, virtualizing desktops and then articles about using desktop PCs for virtual storage. Maybe you don't ever do all of that at once, but it made me wonder: When something breaks, how do you track down the problem in a virtualized infrastructure? How do you manage this virtual mess?
Apparently, I'm not the only one skeptical about the concept, as this blog post by Arthur Cole shows, there's confusion emerging over the relatively straightforward idea of data virtualization. Even Gartner has warned companies to hold off on virtualization.
So, bottom line, we have two complex, fuzzy concepts: SOA and virtualization. Naturally, analysts and vendors are putting them together.
What do you get when you virtualize a loosely coupled architecture?
Judith Hurwitz, the CEO of Hurwitz & Associates, recently took a crack at defining how the two relate in a short blog post, "Is Virtualization the Foundation of SOA."
Obviously, she sees similarities between the two, since virtualized resources are put into a container to create an agile system capable of responding as needed. Likewise, SOA puts business functions into packages of code we call services, so they can be pieced together to build more agile composite applications.
Hurwitz sees the two as a natural fit, particularly for vendors:
"What makes virtualization important for SOA is the ability to move the presentation and availability of these resources across physical networks and devices. Don't get me wrong--this is not simple and we won't see virtualized SOA in the next few months. However, this is the direction for any vendor that is really serious about creating an environment that will allow customers to have the flexibility to leverage their intellectual property across customers, partners, suppliers, and employees."
For a more concrete look at how virtualization can be used with SOA, check out "Are Virtualization and SOA Related." Since the article's written by the founder and chief architect of iTKO, which sells a virtualized testing product, much of the discussion ties back to development and testing of services.
Still, it does a good job of examining how virtualization could address some of the scaling problems large organizations face with SOA.