WebServices dot org

What is Gartner Thinking? Dissecting a Puzzling Pronouncement on Web Services and SOA

Are Web services and SOA worlds apart? Daryl Plummer, analyst and research fellow at Gartner, just published an editorial in Optimize Magazine questioning the role Web services should play in SOA. He walks us through the initial confusion around Web services, noting that "initially, many people thought any service delivered over the Web was, logically enough, a Web service" - not specific to the use of SOAP and WSDL. (I've noticed most of the popular media still regards "Web services" this way, by the way.)

While much of the IT industry has finally grasped the stricter definition of Web services, Plummer says the picture is suddenly getting murky again. "Web-technologies groups are now forcing the acknowledgment that Web services will indeed use mechanisms other than SOAP, WSDL, or even UDDI. Instead, standards such as Plain Old XML (POX) over HTTP and Representational State Transfer (REST) are asserting themselves as legitimate and very credible ways of delivering on the value proposition of Web services. As Web services assume more expansive definitions, we can represent them using a wide variety of formats and communications protocols."

So, the Web services tent is growing and taking in more tenants. What's wrong with that? We’re seeing plenty of deployments happening and ideas springing up in the Web 2.0 space, fueled by the likes of Google and Amazon. These inevitably grow up into new approaches to enterprise applications as well. We saw that with the rise of PCs in the 1980s and the Internet and World Wide Web in the 1990s.

Gartner’s Plummer, however, goes on to talk about a “split” that occurred between the SOA and Web services camps, ostensibly in 2003, “when companies such as BEA Systems, IBM, Microsoft, and Sun Microsystems questioned whether mission-critical systems were possible with Web services as originally defined.” However, 2003 was about the time when vendors and enterprises alike recognized the potential for Web services – first designed for EDI-like and e-business trading partner interactions – to serve as integration standards within internal enterprise applications. I talk to the folks at BEA and IBM almost weekly, and last time I checked, no one had told them yet that the rest of their companies had abandoned XML Web services as standards for SOA development.

Plummer also decries "how much effort is wasted trying to force Web services to deliver enterprise-level capabilities they were never intended to handle." He says that a distributed transaction environment may work better than Web services interfaces for many mission-critical applications, such as an airlines reservation system. He adds that Web services standards "nowhere near ready to be used consistently by mainstream IT."

However, other industry observers – and end-users – may beg to differ with Plummer’s statement. Mark Little, director of standards for JBoss, and a Weblog contributor to Webservices.Org, argues that Web services works just fine for transaction systems, thank you. Enablers of these processes include the WS-AtomicTransaction/BusinessActivity or WS-Transaction Management specifications, both of which provide protocols intended for interoperability of existing transaction processing systems.

Dr. Jim Webber, a senior consultant with ThoughtWorks Australia (and also a contributor to this site), agrees that “the WS-* stuff is fine for Internet scale computing if you have the right underlying architecture (MESTian).” While he agrees that REST has its limitations in transactional settings, he goes on to observe that talk of a purported Web services-SOA split “stinks of another argument for argument's sake like the EDA versus SOA nonsense. It's some folks with a poor grasp of distributed computing getting hung up and over-excited about fluff.”

Perhaps its instructional to see what enterprises are actually doing with Web services now, as we speak. For example, just the other week, I heard Skip Snow, senior vice president and chief SOA architect for Citigroup, describe how Web services-based interfaces now support millions of transactions across his far-flung organization. (See my previous post, “ Invoking the B-Word and the G-Word, Early and Often ”, for details.) In addition, Citigroup’s impressive SOA effort is all about Web services. “Without industry standards, it would have been impossible,” he said.

Likewise, a former CTO of Merrill Lynch also calculates that the organization saved more than $700,000 by assembling a transaction system with Web services, versus traditional technology. There’s no arguing with success.

To put this argument in perspective, it's probably useful to consider what is required to build and deploy a full-functioning service-oriented architecture. Few organizations, if any, have true SOAs at this time that enable business users to decompose, build, or redirect business processes on a moment's-notice, as-needed basis. SOAs will arise as part of a gradual, evolutionary process that will take place over years, not weeks or months. XML Web services have proven themselves to be robust enough to serve as stepping-stones in this effort. 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, SOA is in the eye of the beholder, regardless of whether it is all Web services, some Web services, or no Web services at all. But, at least for now, at many enterprise sites, Web services represents the path of least resistance. There simply is no better way.