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:

• dynamically discover Web services
• dynamically learn how to use a Web service
• interact with a Web service by exchanging semantic-rich XML messages

Observations

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

• The Web services vision is a mirage at the present. If you jump on it today you will loose.
• The only thing that's real today is XML. Use it.

Recommendations

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

• Focus today on creating standardized XML vocabularies, and learning to exchange XML over the Web.
• Don't get enticed by dynamic discovery, dynamic connectivity. That's for tomorrow (2-5 years).Tomorrow will take care of itself.
• Don't use SOAP, WSDL, and UDDI. I believe that they will be replaced with superior technologies in short order.
• Stand up Web services using standardized XML vocabularies. Be satisfied that you have migrated your company applications from HTML (or some proprietary format) to XML. That's a big and important step.
• Describe your Web services textually using HTML (see an example of this here). HTML is "good enough" for today.
• Search for Web services using standard search engines - Google, Yahoo, etc. They are "good enough" for today.
• Design XML vocabularies today with your favorite schema language - XML Schemas, DTDs, or RELAX - but be prepared to rip them out within a year or two. RDF and DAML promise to give you the ability to produce vocabularies with much more semantic richness, to enable dynamic understanding.
• Evolve your companies applications to Web services. Don't take the big bang, revolutionary approach.

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:

• SOAP attempts to provide a standard, XML-based envelope for transmitting messages across the Web
• A WSDL document is used to describe how to use a Web service. By parsing a WSDL document a program can dynamically learn how to use the Web service described by the WSDL document
• A UDDI registry contains information about who's got what Web services. The registry can be programmatically queried. Thus, a program can dynamically discover Web services

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:

• First of all, SOAP, WSDL, and UDDI are in a state of flux. None of them are standardized. Further, there is a lot of question about their basic worthiness.

• SOAP has a lot of problems with security, with coexising with Web intermediaries, such as proxies, caches, firewalls, etc.

• WSDL is very complex, not very expressive, and certainly not very intuitive.

• UDDI is so limited in its capabilities as to be useless (for example, I cannot ask it "what Web services can supply map feature data - rivers, roads, etc - for this region").

• There are strong competitors to SOAP, WSDL, and UDDI. Many people believe that REST is a much better approach than SOAP. Many people believe that DAML-S is infinitely more expressive than WSDL. No one is using UDDI in a commercial setting. People are creating their own registries due to the very limited capabilities of UDDI. I believe that the odds are very high that in a few years SOAP, WSDL, and UDDI will not exist.

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.

Summary

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.