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
|
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
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
|
The
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
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.
The following example describes how this program may ultimately work when implemented using formal Web services protocols and directory services:
Sidebar 3-2
|
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.