Web Service Invocation (Server-Side) 

Purpose

This process describes how the Web services framework of the Application Server Java handles a Web service call.

Process Flow

The figure below presents the process of invoking a Web service implementation.

       1.      A client sends a request to a Web service (WS).

The transport acquires the data, encapsulates it inside a transport object, and gives it to the Web services runtime. The transport must be capable of uniquely identifying a request. The Web services runtime uses this function to find the correct Web service implementation. Once the Web service implementation and configuration have been identified, a list of runtime features required for this service is loaded. Each feature is mapped to a protocol implementation. This mapping is part of the Web service configuration.

       2.      The Web services runtime starts invoking protocols.

The WS runtime invokes each protocol in turn. It possesses its own logic, which may include the processing of the actual message being transferred. The protocol handles the request, the response, and the fault message. Since the protocols are implemented as Java services, they have access to all of the features provided by the J2EE Engine. For example, they may query the Security Service for active user roles, use the Configuration Service to store persistent data, and so on. In addition, the protocol has access to the whole message and to the transport specific properties, such as HTTP headers for the HTTP transport.

A protocol can have a different configuration for each different Web service configuration or even operation. The SAP NetWeaver Developer Studio provides property-based configuration for every protocol.

       3.      The transport binding creates the Java objects that invoke the Web service implementation.

As all other components, the transport binding element is also implemented as a Java service. Its main task is to process the incoming message stream and create the corresponding Java objects. These objects are handled by the implementation container, which invokes the Web service implementation. Since the wire message can have any format, one of the subtasks of the transport binding is to generate the binding part of the WSDL. Thus, the client knows what to send and the transport binding knows how to handle it when it receives it. The transport binding does not have to handle any schema and port-type details. The core part of the Web services framework handles these elements. Since there are several official port-type and schema formats, the binding needs to send to the Web services runtime the format it needs – document/literal, rpc/encoded, or rpc/literal. In the final WSDL, the framework sets a reference from this binding to the proper port-type.

       4.      The implementation container (IC) receives the Java objects and invokes the Web service implementation.

The task of the IC is to find and invoke the proper Web service implementation. For each Web service configuration, there is a set of properties enabling the IC to find and load the proper implementation.

       5.      The implementation container returns a response object to the transport binding, which serializes the object in the fixed wire format. The response message is passed through the protocols and then the transport sends it back to the client.