SOAP Body

The SOAP body includes business data, such as that shown in Listing 5.13.

Listing 5.13: Sample SOAP body

 <SOAP-ENV:Body>    <q0:getMotorVehicleRecord>       <VIN>A123</VIN>       <State>NC</State>       <Category>sport</Category>    </q0:getMotorVehicleRecord> </SOAP-ENV:Body> 

The data is structured in a way that reflects a WSDL format called document-literal wrapped, which means that

• on receiving the message, the service accesses the operation name (getMotorVehicleRecord) and can easily dispatch the message to that operation

• the elements lack the encoded data-type attributes (as shown earlier) that would otherwise degrade performance

• every data value can be validated by an XML Schema definition

SOAP at Run Time

We now outline how the SOAP engine fits into a larger scheme.

The main purpose of the SOAP engine is to convert data between a language-specific format and the format used in the transmitted message. A data conversion is required on both the requester and service sides of the transmission.

When the requester is written in Java, the runtime events are often as shown in Figure 5.2. On the client side, the requester invokes a JAX-RPC stub, which is Java code that your development environment created for you, in most cases. The Java code is based on service-specific details in a WSDL definition and lets you invoke the service as if you were invoking a local function.

Figure 5.2: SOAP at run time

The stub frees the requester from interacting directly with the SOAP engine. In response to the stub's access, the engine converts data from the Java data types into a SOAP format and transmits the data.

On receiving a return message, if any (it may be business data or an error message), the stub uses the information from the WSDL definition again, in this case to convert data from a SOAP format into the data types expected by the requester.

On the service side, the SOA runtime code responds to its invocation by using a service-side WSDL definition to create data that the service can use. That WSDL definition is equivalent to the definition used during creation of the client-side stub.

The SOA runtime code submits the data to the service. When the service returns data, the SOA runtime first uses the service-side WSDL definition to convert data from the native-language data types into a SOAP format. The service then returns the message to the client.

When intermediaries are in use, the message is passed from one SOAP engine to another, and data conversions occur as needed when a message is transmitted first over one transport protocol, then over another.