A client of a service wants to use the service to get something done. When a service is implemented using SOAP, this means that the client needs to send SOAP messages to the service, targeted at specific operations and ports provided by the service, and if these ports and operations generate response messages, the client needs to receive these messages and interpret them.
In order to do this, the client needs a way to map the Java objects and data it has into the ports and operations and messages exposed by the SOAP service, and back again. You can accomplish this Jusing JAX-RPC and SAAJ in several ways, which can be roughly grouped into the following three categories:
This approach involves mapping the service’s WSDL descriptor to a set of client-side Java code. All classes needed by the client are pregenerated by this mapping, and the client uses them to interact with the service.
This approach is similar to the static proxy, except that the stub used by the client is generated dynamically by the JAX-RPC runtime instead of using a class file being generated offline by mapping the WSDL. The client only needs to have a Java interface available that is compatible with the WSDL description of the service.
In this approach, the client dynamically constructs a call to the target service, specifying all the particulars of the service explicitly when configuring the service call.
In terms of the mapping ...