Chapter Summary

This chapter described program-to-program communications in greater detail. Essentially, program-to-program communications is a way for applications to work cooperatively with other applications, using:

1. Some method of locating a cooperative application;

2. Application program interfaces (verb sets) for communicating with other applications and databases; and,

3. Common network protocols (an agreed-to method of transporting data between systems).

Today's Web services follow this model. XML is the means to create and present content in a consistent and readable form. WSDL is a template that helps describe how applications can communicate with each other. SOAP is an API (application program interface) that allows programs to talk with each other. And the Internet has become the common network environment (with HTTP as the common transport protocol).

UDDI allows public and private programs to find each other. [In the past, programmers "told" most applications where to go to get the service they needed (by hard coding the ports or addresses where service programs could be found). UDDI enables requester applications to search the Internet (or an intra- or extranet) to find the best service application to meet the requester's need]. In this respect, UDDI is a new and different function now found in distributed computing architecture.

After describing program-to-program communications, this chapter considered other program-to-program schema of the past. It concluded that Web services will succeed where other approaches have not. What is different this time is that:

• Building the connections between cooperating applications is far more straightforward and far easier than ever before. Previous attempts had to deal with different network types and APIs and conflicting vendor interests as they attempted to standardize this form of program-to-program communications. With the use of the Internet as a common network and with standards developed to work specifically over the Internet across development-language environments Web services has a strong advantage over previous architectural attempts at cross-platform program-to-program communications.

• All of the industry's major hardware and software vendors have endorsed this newly evolved, standards-based Web services approach. Several vendors have made Web services central to their product and services strategies over the next several years and have committed the resources to build and market Web services-based solutions.

The primary obstacles to Web services are related to delays in standards committees as well as the prospect for partial implementations or incompatibilities on the vendor's side. Market demand from early adopters indicates that significant pressure will be put on both camps. Demand from buyers and users will pressure standards bodies to get standards out of committee and into the market (or users will create their own solutions). Vendors who are slow to respond with products that enable their customers to stay competitive may find themselves losing customers to vendors who do offer rich Web services products.

But is this approach a "sure thing"? Should your company consider changing its approach to programming and invest heavily in Web services application development? Conventional wisdom has it that there's no such thing as a sure thing but with such as strong commitment being exhibited by all of the major vendors of computer hardware and software to this architecture, Web services architecture looks pretty darn close.