an XML Collection...

A Sane Approach to Migrating to Web Services
Roger L. Costello

August 4, 2002

The Web Service Vision

The vision of Web services is that software programs will be able to:


How far along is the industry in achieving the Web services vision? Here's my take on it:


Should your company leap into using Web services? Better be cautious. Here are my recommendations:

Rationale for Recommendations

The industry rags tell us that the industry has got its next silver bullet - Web Services. They tell us that a revolution is taking place on the Web with the introduction of Web services. I oftentimes hear this: "Let me convert my corporate applications to use SOAP, WSDL, and UDDI and then my company will have global, dynamic interoperability." Not wishing to dampen such enthusiasm, but SOAP, WSDL, and UDDI is not the magic, silver bullet. Any attempt to bring about revolutionary change in your corporate business structure through the use of Web services is doomed to failure.

Let's examine what SOAP, WSDL, and UDDI are attempting to bring to the industry:

The vision of SOAP, WSDL, and UDDI may best be characterized by this example: a program needs to determine the energy consumed by a 1600 BTU air conditioner in a 10 hour period. The program will find, connect, and interact with a Web service to obtain this information. It will dynamically interact with a UDDI operator which will return a list of Web services that have implemented the A/C energy calculating functionality. Based on factors such as performance, reliability, and trust the program will choose one of the Web services. Using the WSDL document that UDDI returned the program will dynamically learn how to connect to and use the selected Web service. The program will then interact with the chosen A/C energy calculating service by sending and receiving XML documents wrapped in a SOAP envelope.

This scenario is pretty impressive, isn't it? Well, don't count on seeing such examples being implemented on a large scale any time soon. Perhaps as demos, and on a small scale, but not Web-wide. Let's examine why:

You say, "Okay, I'm convinced. I shouldn't jump head-first into Web services. What should I do?" To answer that question we must see what technology exists today which is solid. The answer is - XML. That's all! That should be your starting point. Let's examine the implications of this.

Get together with your business partners, and with your competitors. Come to an agreement on how data in your domain should be formated. That is, create a standard XML vocabulary for your domain. When you do this then everyone in the domain benefits.

Then, after you have created a standard XML vocabulary you can start exchanging XML messages with your business partners. At some point you may wish to start wrapping your XML messages in a SOAP envelope. Resist the temptation. Plain XML really is "good enough".

Note: be prepared to rip out your standardized XML vocabularies! RDF and DAML are coming along very strong. Today you may define your XML vocabularies using XML schemas (or your favorite schema language). This is good but the resulting XML vocabularies are not very dynamically understandable. RDF and DAML promise to give us vocabularies that can be dynamically understandable.

Document your XML-based Web services using HTML. HTML is "good enough".

Use search engines - Google, Yahoo, etc - for searching for Web services. They are "good enough" for today.


I suggest that companies move towards the use of Web services in an evolutionary rather than in a revolutionary fashion. The focus today should be on creating standardized XML vocabularies and modifying your corporate applications to exchanging XML documents over the Web. Describe your Web services in an HTML document. Use standard search engines - google, yahoo, etc - to find services. This is good enough for today. Be satisfied that you have migrated your company applications to being XML- and Web-based. That's a big and important step. Let the mess shake out before jumping into dynamic discovery of services, and dynamic connection to Web services.

This web site contains material that is sponsored by The MITRE Corporation and made freely available in the public interest. Any use of this material must acknowledge The MITRE Corporation.