3.2. Flow of a Web Service Call

In a Web service scenario, a client makes a request to a particular Web service, such as asking for the weather at a certain location, and the service, after processing the request, sends a response to the client to fulfill the request. When both the client and the Web service are implemented in a Java environment, the client makes the call to the service by invoking a Java method, along with setting up and passing the required parameters, and receives as the response the result of the method invocation.

To help you understand the context within which you design Web services, let's first take a high-level view at what happens beneath the hood in a typical Web services implementation in a Java environment. Figure 3.1 shows how a Java client communicates with a Java Web service on the J2EE 1.4 platform.

Note: Figure 3.1 changes when a non-Java client interacts with a Java Web service. In such a case, the right side of the figure, which reflects the actions of the Web service, stays the same as depicted here, but the left side of the figure would reflect the actions of the client platform. When a Java client invokes a Web service that is on a non-Java platform, the right side of the figure changes to reflect the Web service platform and the left side, which reflects the actions of the client, remains as shown in the figure.

Once the client knows how to access the service, the client makes a request to the service by invoking a Java method, which is passed with its parameters to the client-side JAX-RPC runtime. With the method call, the client is actually invoking an operation on the service. These operations represent the different services of interest to clients. The JAX-RPC runtime maps the Java types to standard XML types and forms a SOAP message that encapsulates the method call and parameters. The runtime then passes the SOAP message through the SOAP handlers, if there are any, and then to the server-side service port.

The client's request reaches the service through a port, since a port provides access over a specific protocol and data format at a network endpoint consisting of a host name and port number.

Before the port passes the request to the endpoint, it ensures that the J2EE container applies its declarative services (such as security checks) to the SOAP request. After that, any developer-written SOAP handlers in place are applied to the request. Note that SOAP handlers, which are optional, let developers apply application-specific processing logic common to all requests and responses that flow through this endpoint. After the handlers operate on the SOAP message, the message is passed to the service endpoint.

The J2EE container extracts the method call invoked by the client along with the parameters for the call, performs any XML-to-Java object mapping necessary, and hands the method to the Web service interface implementation for further processing. A similar set of steps happens when the service sends back its response.

Note: All the details between the method invocation and response just described happen under the hood. The platform shields the developer from these details. Instead, the developer deals only with typical Java programming language semantics, such as Java method calls, Java types, and so forth.