Chapter Summary

In Chapter 2 you learned that Web services are standards that enable requester and service programs to easily find each other, agree on how to transfer information, and communicate with each other over the Internet. To be more specific, Web services are based on certain registry services and application program interfaces and on communications protocols that can help applications programs find each other (using UDDI); agree on how to communicate and share information (WSDL); complete the handshake with a "bound" communications session (using SOAP); and use HTTP protocol as a transport for Internet communications.

Also in Chapter 2 you learned how Web services are "supposed to" flow. You learned how requester applications request services and what the respective roles of UDDI, WSDL, and SOAP are in delivering XML-formatted data from a service application to a requester application.

This chapter gave you more in-depth information on Web services technologies with a major focus on XML. You learned that XML represents a way to describe and share data using a common presentation format. You also learned that more than 900 XML schema are being used today meaning that more than 900 "forms" are now being used by various industries to provide a common way to represent industry-specific data and information. You need to understand that representing data in XML form is nontrivial and that much of the pioneering work needed to produce XML data for your particular industry may have already been done.

In this chapter you also learned that Web services are sometimes implemented without the use of UDDI, WSDL, and SOAP registry/directory services and protocols. This point is important, because most vendor write-ups and many news articles neglect to mention that other protocols and program-locator technologies are used in lieu of Web services in order to build many first-generation Web services prototype applications. Web services have tremendous potential to become the preferred method for applications to exchange data with one and other but in the short term many early adopters are using other protocols or application-location services as supplements until Web services protocols mature a bit more.

The benefits of writing Web services applications without using Web services protocols are related to the following:

1. Sophistication The level of sophistication of other approaches (COM, DCOM, CORBA, etc.) is often more mature in security, manageability, reliability, and other important "abilities" necessary for enterprise-class programming environments.

2. Expediency Using existing code or other program-to-program architectures to pass XML data can be more expedient than rewriting applications using Web services protocols.

On the other hand, when Web services are implemented using other approaches, users may find the process to be less automated (more manual) than if the applications had been written using a formal Web services approach (the format-conversion application in this chapter illustrated this point). For instance, when UDDI is not used, developers are called upon to hard-code the location of Web services to be provided (meaning that an application developer has to put directions to a particular Web site into his/her code to direct the requester application to the service needed). The non-standards-based approaches can be more cumbersome for the programmer (and can create a situation where the programmer may have to maintain the code should the hard-coded application be changed) and less automated for the user.

In the short term it is reasonable to expect early-adopter enterprises to use existing application objects, other distributed computing architectures and APIs, and hard-coded directory functions to build their initial Web services implementations. As a result, these implementations will sometimes require manual intervention and hard-coding in order to find cooperative applications, or they may work only with applications that use the same "proprietary" APIs (like the DCOM example cited) meaning that these applications will only be able to communicate with like systems.

In the longer term, in order for true, fully automated, transparent platform-independent, program-to-program communications to take place, applications will need to use common standards such as UDDI, WSDL, SOAP, HTTP, XML schema, and other standards and conventions.