An Example: Using an Alternative Approach to UDDI for Finding Cooperative Applications

Another approach in lieu of using a UDDI directory service is to give the user the responsibility to find and link to the service he or she desires. Some "Web services" work by asking whether the user would like to be directed to a site where a transactional or computational service can be obtained. My favorite example of this approach is in Microsoft's Windows XP operating environment.

Have you ever received an e-mail from a friend with a file attachment that was in some file format that you didn't recognize? If you are like many people, you may have e-mailed your friend back and asked what format his or her document was stored as.

You would then have to go to the Web and find the appropriate "reader" in order to be able to view the document that was sent by your friend.

When this scenario unfolds under Microsoft's Windows XP operating environment, a Web service application is automatically activated when you try and read a file type that your system doesn't know. This application essentially says "Would you like to go to the Web to find a reader that can help you read the file that your friend just sent you?" If you answer yes, the program makes a call to a Web site with hundreds of file extensions (a file extension is represented by a dot and three letters that follow the document/file name that you have received in a Microsoft Word document, for instance, this extension would be ".doc"). You then chose the appropriate file extension; the site helps you find the reader that you need; and voilá you can now finally read the document or file that your friend has sent to you.

This example shows how applications can be written to provide services for you (albeit in this case the whole transaction was highly manual). And it shows how important having common formats is (because the failure to have a reader capable of reading your friend's document or file caused you to have to go through extra effort in order to read that file). The bottom line in this example is that the Web service requester application knew where to go to help you find the reader that you needed to view your friend's file/document thus providing a valuable service for you (in this case, this service was provided in a semiautomated fashion). Longer term, this type of transaction could be wholly automated using UDDI, WSDL, and SOAP.

The preceding example provides a very simple and straightforward example of how a nonautomated Web service can work. A simple "requester program" went to a known Web address to obtain a service. This address was "known" by the requester program because a programmer put its address in the requester program (the programmer "hard-coded" a location to turn to in order to obtain a service). Once connected to the Web service site, the requester program asked a service program to help find a "reader" for file extensions that the user could not read. Using this Web service approach, the user was able to obtain access to a reader program that solved his or her content-viewing problem.

Note, however, that this particular Web service was provided without using UDDI to find an available service (instead, programmers hard-coded the location of the Web site that contained the readers). In this case, we saw two programs working cooperatively together (notice that the requester made a request to send a file-extension reader, and that a reader was ultimately sent).

Note also that this Web service application didn't use WSDL to negotiate how the service would be provided. And it's doubtful that SOAP protocol was used to bind the file transfer session instead a simple command using TCP/IP's FTP protocol was probably used.

Additionally, observe that the service was provided "semiautomatically" that is, user intervention had to take place to get the service that was originally requested. When all of the Web services protocols are used, this process can be designed to take place transparently; the user may not even be aware that a Web services program acted on his or her behalf to retrieve a reader program. The whole translation task can happen in the background with no user intervention.

The bottom line in this example is that a Web service was provided (as evidenced by two applications cooperating to provide the user with a service), but this service was not based on using Web services protocols or a UDDI registry. Hence, it is possible to receive Web services without using the formal Web services standards but note also that using this approach can be somewhat manual rather than programmatic/automatic in nature.

How This Application Would Work as a Truly Automated Web Service

The following example describes how this program may ultimately work when implemented using formal Web services protocols and directory services:

Sidebar 3-2
How This Application May Some Day Work

• A requester application asks a UDDI directory to find a site that has a reader for a particular file extension;

• The UDDI directory contains a list of sites that have published the availability of such readers;

• The requester's WSDL application then steps-in to negotiate for the use of that reader (some readers are free, others are available on a chargeable basis);

• Once the business terms and conditions have been executed, WSDL turns over the rest of the transaction to SOAP. SOAP binds the communications session and the reader is sent to the user.

• And, if you want to get really fancy, that reader should be able to unpack itself, automatically read the previously unreadable content, and present that content for viewing to the user. And, all of this should be done transparently and instantaneously.

The big difference between the two examples is that the approach in the first one is highly manual in nature, while that in the second example the formal Web standards-based approach enables this format-conversion service to take place automatically and transparently.

Web service applications can be written without the use of Web services protocols and directories. Doing this, however, involves either manual user intervention to instruct the system how and where to obtain a Web service, or "hard-coding" in order to enable applications to find each other and work cooperatively together. User intervention defeats the purpose of Web services it eliminates the "automatic and transparent" service provisioning aspect that Web services have been designed to deliver. And hard-coding defeats the ability of a Web-based application to search the Internet for other applications that may be better suited to the service purpose again defeating fundamental aspects of Web services, such as finding the best service for the job or negotiating with other applications for the best service deal.