Analyst: Web services not always right for SOA

Gartner analyst questions the wisdom of Web services-enabling enterprise apps intended for SOA.
Written by Joe McKendrick, Contributing Writer

"When it comes to building SOAs, I can't get over how much effort is wasted trying to force Web services to deliver enterprise-level capabilities they were never intended to handle."

Gartner's Daryl Plummer, writing in this month's issue of Optimize, wonders out loud if Web services -- designed with external e-business in mind -- are really the best approach for enterprise service-oriented architectures. Daryl Plummer, analyst and research fellow, Gartner

Since 2003, there has been a growing rift within the SOA/Web services world, Plummer says. "One group advocates using Web services to build complex SOAs. The other seeks to use emerging Web technologies in tandem with Web services to create flexible external applications."

Plummer relates how managers at a well-known airline once asked him "to make their Web services provide an enterprise-level distributed-transaction environment." He recommended that given the shortcomings of the Web services standards, the airline should consider a "a real distributed transaction environment instead of Web services."

Web services used to mean SOAP and WSDL, but now encompass other approaches such as Plain Old XML (POX) over HTTP and REST, Plummer adds. "The problem is, expanding on what's considered to be a real Web service could devalue the entire concept. When people get to thinking that anything delivered over the Web is a Web service, we run the risk of not delivering interoperability and programmability in a standard way. We could then see a proliferation of so-called Web services for use only in very specific circumstances—not exactly a step forward."

UPDATE, MARCH 17... I reflect further on the relationship between Web services and SOA in a commentary posted at Webservices.Org. My conclusion is that while there a thousand ways to build SOA, Web services will be (and already are at many implementation sites) essential to SOA efforts going forward.

Editorial standards