PHP Learning Path: WSDL in detail (ii)

3. Defining logical messages used by the service

When the operation of the service is invoked, the service is defined as a message exchange. In the WSDL document, these messages are defined as message elements. These messages are made up of parts called part elements.

The operation of a service, defined by specifying a logical message. When the operation is called, the logical message is exchanged. (That is, the logical message represents the operation of the service) these logical messages, which define the data transferred on the network as XML documents. He contains all the parameters that are part of the method invocation. (That is, the arguments in the logical message are the set of parameters for the corresponding method of operation)

message and parameter list: each operation exposed by the service can and can only have one input message and one output message. The input message defines all messages that the service accepts when the operation is invoked. The output message defines all the messages that the service returns when the operation is complete. The fault message defines the data when the service returns an error.

In addition, each operation can have a certain number of fault messages. This fault message defines the data that is returned when a service error occurs. These messages usually have a section that provides enough information to let the consumer know what the error is.

The message is designed to integrate with the inherent system: If you define an existing application as a service, you must ensure that each parameter that is used in the method (the method that implements the action) is able to find the corresponding in the message. You must ensure that the return value is also in the output message of the operation.

One way to define your message is: RPC style. When using RPC style, you define a part with each parameter in the parameter list. Each message part is based on the type of the top one in types.

Your input message corresponds to one part for each input parameter, and the same output message corresponds to one part for each output parameter. In addition, add a part to correspond to the return value. If a parameter is both an input and an output, it is listed as an input and as an output message.

RPC-style message definitions are useful when the service enables the system to be in stock. It uses a pattern transmission similar to TIBCO or CORBA. These systems are designed around processes and methods. Precisely because of this, they are the easiest to model with messages. RPC style is also a clear mapping between services and applications.

designing messages for SOAP services: when RPC style is used for modeling the inventory system, but the service Association strongly likes to wrap the document style. In the wrapper document style, each message has a part. The part of the message references a wrapper element, which is defined in the types element. Packaging elements have the following characteristics:

• He's a composite type that contains a series of elements
• If it is a wrapper for the input message, then: each of its elements corresponds to an input parameter; his name is the same as the associated operation name.
• If it is an output message wrapper, then: each of its elements corresponds to the input parameters, also corresponding to the output parameters. Its first element represents the method return value. His name will be added by adding response to the name of the operation with which to associate the wrapper.

Message naming: Each message has a unique name in its namespace, it is recommended that you use the following naming convention:

• Messages should be used by a single operation
• Enter the message name to add the request after the operation name
• The output message name is incremented after the operation name response
• The error message name is added fault after the wrong reason

Message Part : A message part is the most commonly used unit of a logical message. Each part is defined, with the part element. And with the Name property, specify the data type with the Type property or the Element property.

The message allows the part name to be reused. For an instance, if a method has a parameter: foo, he is applied or passed through in/out, he can exist in the request or reply message as a part. The following example:

<message name= "Foorequest" >
<part name= "foo" type= "Xsd:int"/>
<message>
<message name= "Fooreply" >
<part name= "foo" type= "Xsd:int"/>
<message>

Example: Suppose you have a server that stores personal information and provides a way to swap back employee data, based on employee ID. The method is as follows:

Personalinfo lookup (Long empId)

The WSDL that is mapped to the RPC style is as follows

<message name= "Personallookuprequest" >
<part name= "EmpId" type= "Xsd:int"/>
<message/>
<message name= "personallookupresponse>
<part name= "return" element= "Xsd1:personalinfo"/>
<message/>

Map to the packaging style as follows:

<types>
<schema ...>
...
<element name= "Personallookup" >
<complexType>
<sequence>
<element name= "EmpID" type= "Xsd:int"/>
</sequence>
</complexType>
</element>
<element name= "Personallookupresponse" >
<complexType>
<sequence>
<element name= "return" type= "Personalinfo"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name= "Personallookuprequest" >
<part name= "EmpId" element= "Xsd1:personallookup"/>
<message/>
<message name= "personallookupresponse>
<part name= "return" element= "Xsd1:personallookupresponse"/>
<message/>