As you learned in Hour 17, "HTTP, HTML, and the World Wide Web," the World Wide Web has given rise to a bundle of new technologies. The focus of this development is on building an Web-based infrastructure for custom applications. The programmer creates the application using components and tools associated with the platform, then employs HTTP and XML to deliver the data across the network. In recent years, this technology has outgrown the original vision of the Web as a manifestation of the global Internet. This so-called Web services architecture is regarded now as an approach to building any sort of network application, whether or not that application is actually connected to the Internet. Large and powerful vendors such as Sun, Microsoft, and IBM have invested enormous resources in building component infrastructures to support this Web services vision.
The best way to understand the Web services architecture is to begin by remembering that network applications typically consist of a client, an application requesting services, and a server, an application providing services. The client and server reside on different computers and are essentially two different programs. In the past, a programmer who wanted to write a network application had to write two separate programs, and provide some form of interface for passing data between the programs along the way. Network program interfaces existed of course—otherwise many of the classic applications described in this book would have never evolved—but network programming typically required some significant, high-priced coding at the network interface. By using XML and the Web delivery system for passing data, programmers greatly simplified the trouble and expense associated of writing a network application.
The HTTP delivery system, however, is only part of what we know as Web services. Also significant is the arrival of component architectures that provide ready-made classes, functions, and programming interfaces for working within a Web-based environment. Platforms such as IBM's WebSphere, Sun's SunOne, and Microsoft's .NET provide components that solve many of the problems associated with programming in the Web services environment. The goal is to create a complete infrastructure for the programmer, so that the task of writing a program is reduced to deploying the necessary components and providing any appropriate logic in between.
The parts of the Web services application are as follows:
Figure 23.11 shows a complete Web services scenario. On the front end (the left side of Figure 23.11), the programmer can take advantage of the pre-existing Web infrastructure, which handles data transmission and also provides a user interface through the Web browser application on the client computer. On the back end, the programmer relies on the pre-existing data storage system provided by an SQL database. The programmer is left to concentrate on the center section of Figure 23.11, where the ready-made components of the Web services platform further simplify the task of programming.
Data passes through the components of the Web services system in XML format. As you learned in Hour 17, XML is an efficient, universal means for assigning values to attributes. Experts quickly recognized that the system would work even better if they could use the XML format to actually invoke services or generate responses over the network. Simple Object Access Protocol (SOAP) offers a standard method for passing XML-based data between Web service processes. SOAP also describes how to use the XML and HTTP to invoke remote procedures.
By the Way
The Java programming language is well suited to the Web services architecture, and Java is the basis for several Web service platforms, including WebSphere and SunOne. Microsoft devised a new language called C# with some Java-like properties to go with the .NET platform. Microsoft also added extensions to C++ and Visual Basic to provide some of the background functions necessary for the Web services environment.