Web services: A skeptic’s journey

The truth is most products and techniques can help a little here and there. Sometimes they help immensely — provided the conditions are right.

To get to the truth I have a “hype filter” that works this way: I construct a model of the basic functions of a product and then examine under what conditions those functions will make a difference in a business at a reasonable cost.

This method serves me as a hype normalizer. But occasionally it causes me to dismiss an idea without fully appreciating its power, which is exactly what happened when I came to examine Web services.

Most marketing and advertising is tiresome, and I am generally prickly about new trends, as if I’d been disturbed by a telemarketer from reading a good book. When the metaphorical phone call came during the first wave of Web services announcements, my first impression was that it was the next idea to fill the hype vacuum that has existed since the end of the dot-com gold rush. The first such idea was peer-to-peer, which is a powerful technique for a certain set of applications but not likely to live up to its revolutionary claims.

Web services seemed to me like a three-pronged plug, a standard that applications and services can share. I’m happy that all of my appliances have three-pronged plugs, but it is electricity that provides the power and the appliances that turn that power into work. Aren’t electricity and useful appliances far more important than the three-pronged plug?

More fuel for my skepticism arrived when I heard the claims about UDDI (Universal Description, Discovery, and Integration) allowing some mythical application architect to search through a distributed directory to find useful Web services. After hearing this sort of pipe dream, I chuckled, and turned my attention back to my good book.

But as I’ve seen what my fellow travelers have done with Web services, I realized that I have been too hasty. Web services are a three-pronged plug and it will be a long time before they are able to deliver on the full promise of general interoperability across company boundaries. But within the enterprise, it is already clear that Web services can make a huge difference in the short term if properly implemented and managed.

The companies that are getting ROI out of Web services are using them to implement a service-based application architecture within the enterprise. The benefits are reduced costs of integration as business needs change and a cleaner abstraction of what each application provides to the rest of the enterprise. Much of the improvement comes from the analysis of what each application should offer the rest of the infrastructure. Planning a migration to a service-based architecture allows architects to make sense of the maze of their infrastructure and identify further opportunities for increased efficiency. Think of this potential as integration in advance.

Because Web services are relatively light, they can be implemented more quickly and with less effort than its ancestors DCE (Distributed Computing Environment) or CORBA. The use of SOAP (Simple Object Access Protocol) as a Web services foundation makes for a much cheaper and faster implementation because SOAP relies on the existing network infrastructure of TCP/IP, HTTP, and XML. The fact that SOAP is implemented on almost every platform known to man makes platform independence more than a claim. So in the typical company that has systems across a number of platforms, the fastest path to a unified presentation of applications will be through Web services.

I see little hope for UDDI, the inter-enterprise yellow pages for Web services, to be used as intended. But like LDAP before it, which has been used as a fast cache for applications and many other purposes, UDDI will probably find a use within enterprise architecture.

Re-igniting skepticism

Examining the notion of the WSDL (Web Services Description Language) partially re-ignites my skepticism. Here’s an important reason Web services are lightweight: Many important things have not been specified. The WSDL file tells much about what parameters are being exchanged and what results will come back, but how those results will be used is not made clear. A common understanding of the meaning and usage of the parameters and results constitutes the semantic contract between an application using a Web service and the program that provides. This contract is not completely specified by WSDL.

Although the vision of offering applications as services is attractive, as soon as someone starts using them, you have a semantic contract that must be kept. The downside of a service-based architecture is that if successful, you have to take into account all of the applications using the service when making changes to improve the system or fix bugs. If this change control is not well managed, a lot of applications won’t work after a change and people will get angry. Like ASPs, individual Web services have a higher chance of success when they are simple and well defined.

Other problems that are in early stages of being addressed are the lack of consistent implementations. The Web services standard is not commonly understood and implemented. Until it is, compatibility problems will arise. Security is also a huge issue that is going to be tough to address at both the specification and implementation level.

Solving these problems across company boundaries will be impossible in the short term, but within an enterprise they are manageable. If these challenges can be met, the three-pronged plug of Web services can work as promised to produce the elusive ROI on technology investment that we all diligently seek.

Dan Woods (dwoods@CapitalThinking.com) is CTO of New York-based CapitalThinking, an ASP for the real estate industry, and is a member of InfoWorld’s CTO Advisory Council.