Conceptual Technical Overview

It s important to understand how all of these acronyms come together to form a technical solution. Assuming a Web Service has been created (details of which will be discussed shortly), it is appropriate at this juncture to understand the mechanics of how a Web Service gets called. For a visualization of the following steps, refer to Figure 17-1:

• Step 1 Once the service is created, a WSDL file is created that can be registered or published. The WSDL file can be published in a file, on the Internet, or in a service directory (i.e., using UDDI).

• Step 2 A client that wishes to use the Web Service can learn about it via the self-describing WSDL file or through UDDI.

• Step 3 Once a Web Service client understands the inputs, outputs, and methods available, it will execute the service remotely, but transparently , to the client. The request to execute the service is made via SOAP (which is composed of XML) through HTTP or HTTPS to the SOAP processor. The SOAP processor breaks down the SOAP message to understand which service is being called and to determine the input parameters to pass along to the service. The service is called, which returns its respective output parameters. The SOAP processor packages the results into a resulting SOAP message that is transmitted back to the Web Service client.

• Step 4 The client extracts the output parameters from the SOAP message and returns this information to the calling program (in its native speak).

  
  Figure 17-1: Web Services conceptual overview

The client program doesn t realize the subroutine that it just called exists on another server; rather, it just knows it received its results.