Before Web Services

Connecting computers to transfer data was already an important concept in 1969 when just four computers were connected via telephone lines to form the ARPANET. In 1976 the TCP/IP protocol was invented. To make this protocol easy to use, the University of Berkeley created the socket model for network programming.

When programming with the Sockets API, the client had to initiate a connection to the server and then send and receive data. To call some operations on the server to get results, additional protocols are needed to describe request and response codes. Examples of such so-called application protocols are File Transfer Protocol (FTP), Telnet, and Hypertext Transfer Protocol (HTTP). The FTP protocol is used to get some files from the server and to put the files on the server. The FTP protocol supports request codes such as GET and PUT, which are sent across the wire from the client to the server. The server analyzes the data stream it receives, and, according to the request codes, invokes the corresponding method. The HTTP protocol works very similarly to the FTP protocol.

Remote Procedure Call (RPC)

With the Sockets API and the TCP/IP protocol calling custom methods on the server, the programmer would have had to create a means by which the server analyzes the data stream to invoke the corresponding method. To make all this work more easily, some companies created an RPC (remote procedure calls) protocol, an example of which is the still popular DCE-RPC protocol (Distributed Computing Environment – Remote Procedure Calls) from the Open Software Foundation (OSF), which later became the Open Group (www.opengroup.org). Using RPC, you defined methods in an IDL (Interface Definition Language) format, which the server has to implement, and which the client can call. You no longer have to define a custom protocol and parse the request codes to invoke the methods. This work is done by a special program, called a stub, generated by an interface compiler.

RPC is designed to invoke methods, which means that you have to do procedural programming. The RPC technology came in relatively late, when most developers had already started to work with the object-oriented paradigm. To bridge the technology gap, several technologies came into being, including CORBA and DCOM.

CORBA

In 1991 the Object Management Group (OMG, www.omg.org) initiated CORBA (Common Object Request Broker Architecture) to add object-orientation to network programming. Many vendors such as Digital Equipment, HP, IBM, and others implemented CORBA servers. Because the OMG didn't define a reference implementation though, only a specification, the servers of these vendors didn't really interoperate. The HP server needed an HP client, the IBM server an IBM client, and so on.

DCOM

With Windows NT 4, Microsoft extended the DCE-RPC protocol with object-oriented features. the DCOM (Distributed COM) protocol made it possible to call COM components across the network and is used in COM+ applications. After some years in which Microsoft operating systems were a requirement for DCOM, Microsoft opened the protocol for others with The Active Group. DCOM was made available for Unix, VMS, and IBM systems. DCOM was heavily used in the Microsoft environments, but the initiative to bring it to other systems was not really successful. What IBM mainframe administrator wants to add Microsoft technology to his or her system?

RMI

Sun Microsystems took a different route with its Java technologies. In a pure Java world, the RMI (Remote Method Invocation) protocol can be used to call objects remotely. Sun added some bridges to the CORBA and COM world, but the major goal for Sun was to bring the masses to a Java-only solution.

SOAP

All the technologies that we have seen were used for application-to-application communication, but if you have a CORBA, a DCOM, and an RMI solution, it is hard to get these different technologies to talk together. Another problem with these technologies can be found in their architectures: because they are not designed for thousands of clients, they can't achieve the scalability required for Internet solutions.

As a result, several companies, including Microsoft and UserLand Software, (www.userland.com) created SOAP in 1999 as a completely new way of invoking objects over the Internet, one that builds upon already accepted standard protocols. SOAP uses an XML-based format to describe methods and parameters to make remote calls across the network. A SOAP server in the COM world could translate the SOAP messages to COM calls, whereas a SOAP server in the CORBA world translates them to CORBA calls. Originally, the SOAP definition made use of the HTTP protocol, so that SOAP calls could be done across the Internet.

With SOAP 1.2, Web services are independent of the HTTP protocol. Any transport protocol can be used. However, the most used transport protocol for Web services is still HTTP. In this chapter, the focus will be on Web services that can be created with the Visual Studio 2005 Project Wizard that makes use of SOAP and HTTP.

Note

SOAP specifications can be found at www.w3.org/TR/SOAP.

Where to Use Web Ser vices

To get another view of what Web services are, you can distinguish between user-to-application communication and application-to-application communication.

Let's start with a user-to-application communication example, getting some weather information from the Web. There are a large number of Websites, such as www.msnbc.com and www.weather.com, that present the weather information in an easy-to-digest format for a human reader. Normally, these pages are read directly by a user.

If you wanted to create a rich client application to display the weather (application-to-application communication) your application would have to connect to the Website with a URL string containing the city for which you want to know the weather. You would then have to parse the resulting HTML message returned from the Website to get the temperatures and weather conditions, and then you could finally display this information in an appropriate format for the rich client application.

That is a lot of work, considering that you just want to get some temperature readings for a particular city. And, the process of getting the data from the HTML is not trivial, because HTML data is designed to be displayed in the Web browser and is not meant to be used by any other client-side business application. Therefore, the data is embedded in the text and is not easily extracted, and you would have to rewrite or adapt the client application to retrieve different data information (such as rainfall) from the same Web page. Compared to using a Web browser, users can immediately pick out the data they need and can overlook what is not needed.

To get around the problem of processing HTML data, a Web service provides a useful means for returning only the data requested. Just call a method on the remote server, and get the information needed, which can be used directly by the client application. At no point do you have to deal with the preformatted text that is meant for the user interface, because the Web service presents the information in XML format, and tools already exist to process XML data. All that is required from the client application is to call some methods of the .NET Framework XML classes to get the information. Better still though, if you are writing a client in C# for a .NET Web service, you don't even need to write the code to do that — there are tools which will generate C# code for you!

This sort of weather application is one example of how Web services can be used, but there are a lot more.

A Hotel Travel Agency Application Scenario

How do you book your holiday? By going to a travel agency that does all the work for you. Have you already booked your holiday on the Internet? On an airline's Website, you can look for possible flights and book them. A Web search engine can be used to look for a hotel in the desired city. Maybe you are lucky and find a map showing how to get to the hotel. When you find the hotel's home page, you navigate to the booking form page, whereupon you can go ahead and book the room. Next you would search out a car rental firm, and so on.

A lot of the work you have to do today is to find the right Websites with the help of search engines, and then to navigate these sites. Instead of going through that, you could create a Home Travel Agency Application that uses Web services containing details about hotels, airlines, car rental firms, and so on. Then you can present the client with an easy-to-use interface to deal with all the holiday issues, including a not-to-be-forgotten early booking of a special musical event. With your Pocket PC on location during your holiday, you can use the same Web services to get a map to some leisure-time activities, and to get accurate information about cultural events or cinema programs, and so on.

A Book Distributor Application Scenario

Web services can also be useful for two companies that have a partnership. Assume that a book distributor wants to provide bookshops with information about books in stock. This can be accomplished with a Web service. An ASP.NET application using the Web service can be created to offer this service directly to users. Another client application of this service is a Windows application for the bookshop, where at first the local stock gets checked and then that of the distributor. The sales person can immediately answer questions about delivery dates without having to check different stock information in different applications.

Client Application Types

The client of a Web service can be a rich Windows application created using Windows Forms, or an ASP.NET application using Web Forms. A Windows PC, a Unix system, or a Pocket PC can be used to consume (use) the Web service. With the .NET Framework, Web services can be consumed in every application type: Windows Forms, Web Forms, or console applications.

Smart client is a new term for a rich client application that makes use of Web services. The smart client can operate without being connected to the Web service because it caches data locally. Microsoft Outlook is an example of a smart client as all the mail data is stored on the client system, and when the Exchange server can be connected the data is synchronized.

Application Architecture

What does an application using Web services actually look like? Regardless of whether you develop ASP.NET or Windows applications, or applications for small devices (as you have seen in the application scenarios presented here), Web services is an important technology.

Figure 20-1 illustrates a scenario showing how Web services can be used. Devices and browsers are connected through the Internet to an ASP.NET application developed with Web Forms. This ASP.NET application uses some local Web services and some other remote Web services that can be reached across the network: portal Web services, application-specific Web services, and building block Web services. The following list should help to elucidate the meaning of these service types:

Figure 20-1

• Portal Web services offer services from different companies with the same subject matter. This is an easy-to-use access point for multiple services.

• Application-specific Web services are created just for the use of a single application.

• Building block Web services are services that can easily be used within multiple applications.

The Windows application in Figure 20-1 can use the Web services directly without going through the ASP.NET application.