As mentioned in the beginning of this chapter, a web service is a software system designed to support interoperable machine-to-machine interaction over a network. A web service is typically hosted on a remote machine (provider) and called by a client application (consumer) over a network. After the provider of a web service publishes the service, the client can discover it and invoke it. The communications between a web service and a client application to be used can be done by sending XML messages. A web service is hosted within a web server and HTTP is used as the transport protocol between the server and the client applications. The following diagram shows the interaction of web services:

The reason it is called a web service is that it is designed to be hosted in a web server such as Microsoft Internet Information Server, and called over the Internet, typically through the HTTP or HTTPS protocols. This is to ensure that a web service can be called by any application, using any programming language, and under any operating system, as long as there is an active Internet connection, and of course, an open HTTP/HTTPS port, which is true for almost every computer on the Internet.

Web services were invented to solve the interoperability problem between various applications. In the early 90s, along with the LAN/WAN/Internet development, it became a big problem to integrate different applications. An application might have been developed using C++ or Java, and run on a Unix box, a Windows PC, or even a mainframe computer. There was no consistent way that was standardized across the industry for one application to communicate with other applications. It was the development of XML that made it possible to share data between the applications across hardware boundaries and networks or even over the Internet.

For example, a Windows application might need to display the price of a particular stock. With a web service, this application can make a request to a URL and/or pass an XML string such as the following:

<QuoteRequest><GetPrice Symble='XYZ'/> </QuoteRequest>

The requested URL is actually the Internet address of a web service, which upon receiving the preceding quote request, gives a response as follows:

<QuoteResponse><QuotePrice Symble='XYZ'>51.22</QuotePrice> </QuoteResponse/>

The Windows application then uses an XML parser to interpret the response package and display the price on the screen.

Each web service has a unique URL and contains various methods. When calling a web service, you have to specify which method you want to call, and then you need to pass the required parameters to the web service method. Each web service method will also give a response package to provide the execution results to the caller.

Not only can new applications, such as web services, be developed, but also the legacy applications can be wrapped up and exposed as web services. So, an IBM mainframe accounting system might be able to provide external customers with a link to check the balance of an account.

In order for a web service to be invoked by other applications, the invoking system must know how to call the method in the web service. WSDL is a language that provides the ability for a web service to be able to give a description of the methods available through the web service.

WSDL stands for Web Services Description Language. It is an XML format that defines and describes the functionalities of the web service, including the method names, parameter names and types, and returning datatypes of the web service.

For a Microsoft ASMX web service, you can see the WSDL by adding ?WSDL at the end of the web service URL, say http://localhost/MyService/MyService.asmx?WSDL.

A client application calls a web service through a proxy. A web service proxy is a subclass between a web service and a client. It is normally autogenerated, according to the WSDL of the web service, by a tool such as Visual Studio IDE. It can be re-used by any client application. The proxy contains the stub methods mimicking all the methods of the web service so that a client application can call each method of the web service through these stub methods. It also contains other necessary information required by the client to call the web service such as custom exceptions, custom data and class types, and so on.

The address of the web service can be embedded within the proxy class, or it can be placed inside a configuration file. A proxy class of a web service can be created for a specific language. For example, there could be a proxy class for the Java clients, a proxy class for the C# clients, and yet another proxy class for the COBOL clients. A proxy class can also be generated in a commonly understood way such as in XML format. Different clients written in different languages can re-use this same common proxy class to communicate with the web service.

To call a web service from a client application, the proper proxy class first has to be added to the client project. Then, with an optional configuration file, the address of the web service can be defined. Within the client application, a web service object can be instantiated and its methods can be called just as for any other normal method.

There are many standards for web services—SOAP is one of them. SOAP was originally an acronym for Simple Object Access Protocol and was designed by Microsoft. As this protocol became popular with the spread of web services and its original meaning was misleading, the original acronym was dropped with version 1.2 of the standard. It is now merely a protocol, maintained by W3C.

Now, SOAP is a protocol for exchanging the XML-based messages over computer networks. It is widely used by web services and has become its de facto protocol. With SOAP, the client application can send a request in XML format to a server application, and then the server application will send back a response in XML format. The transport for SOAP is normally HTTP/HTTPS, and the wide acceptance of HTTP is one of the reasons why SOAP is also widely accepted today.