Time to drive a wedge between SOA and Web services?

SOA is about more than interoperability. SOA is about more than integration.

SOA is more than Web services, but Web services still offers the least path of resistance to SOA

No argument there. SOA ultimately is about business agility and flexibility. But, for now, the main thrust of most reported SOA efforts -- at least if they want to deliver some demonstrable ROI -- is interoperability and integration. By all indications, the business agility will come later as SOA-based services reach critical mass, are shared across enterprises, and are well orchestrated.

But interoperability and integration are what Web services -- not SOA -- is all about. In a new post, ZapThink's Jason Bloomberg says too many people still make the mistake of thinking of service-oriented architecture and Web services as one in the same. "SOA has now grown beyond what Web services can offer," he says.

Indeed it is. But are we that far along yet? Jason defines the distinction as follows:

• SOA: an approach to organizing IT resources to better meet the changing needs of the business
• Web services: standards-based, contracted interfaces to software functionality and data

Note the business angle to SOA, and the more techie angle of Web services. Of course, there's nothing new about this argument, and it's been quite well established that SOA doesn't have to be limited to Web services -- it could be built on CORBA components, for example.

An entire SOA could theoretically even be delivered on someone's own proprietary standards, though it's hard to imagine why a company would go through the effort when well-tested, agreed-upon standards already exist. And those well-tested, agreed-upon standards are, well, Web services. That's why most of the SOA initiatives emerging out there are built around Web services standards and protocols. Web services aren't perfect, but for a greenfield project, what else is there?

Cased closed? Not quite, Jason says. He notes that "there remains far too much confusion around the Web services vs. SOA question for this issue to be put to rest quite yet:" (No pun intended, I'm sure.)

"Perhaps the greatest challenge remaining is to establish the perspective that SOA is really about business process, but not about integration. That challenge will remain as long as vendors hawking integration software cling to the mistaken belief that their software is essential to successful SOA."

Jason also cautions that "there remain many organizations who are attempting to implement SOA, but do little more than implement Web services instead, ending up with redundant, incompatible, and often unmanaged services that have nothing to do with architecture."

iTKO's Jason English just put up a post that agrees with Jason Bloomberg, observing that "in our experience with prospective clients, we still commonly find companies that need to learn the distinction between one integration approach (WSDL/SOAP) with developing standards at best -- and an overall strategy of aligning technology around the business (SOA)."

Is this just splitting hairs? No, because real damage is done, Jason English notes, when companies think they are testing SOA by simply testing their Web services:

"Web services testing on its own will never deliver the quality levels required to achieve Trust in your SOA applications. Since SOA is by nature a heterogeneous environment, you need to invoke and test every layer of these applications - and an XML stream from a Web services provides no visibility into the behaviors underneath that Web service."

Agreed -- and I talk about the prevalence of JBOWS (Just a Bunch of Web Services) architecture quite a bit in this blogsite. Few organizations, if any, truly have full-functioning SOAs at this time that enable developers, architects, or business users across the enterprise to decompose, build, or redirect business processes as needed.

SOAs will arise as part of a gradual, evolutionary process that will take place over a period of years. Web services have proven themselves to be robust enough to serve as stepping-stones in this effort for many companies. For example, industry-standard interfaces and messaging have already been deployed in many organizations as cost-effective ways to build composite applications that link back-end legacy systems.

Ultimately, SOAs will either be built entirely on Web services, on some Web services, or not on Web services at all. But, at least for now, for most enterprises, Web services represents the path of least resistance.