3. Define the logical messages used by the service
A service is defined as a message exchange when its operations are invoked. In the wsdl document, these messages are defined in the message element. These messages are composed of parts called part elements.
The operation of a service is defined by specifying logical messages. When operations are called, logical messages are exchanged. (In other words, logical messages represent the operations of the service) These logical messages define the data transmitted on the network as xml documents. It contains all parameters that are part of the method call. (In other words, the parameters in the logical message are the parameter set of the corresponding method of the operation)
Message and parameter list: Each operation exposed by the service can have only one input message and one output message. Input messages define all messages that the service accepts when the operation is called. Output messages define all messages returned by the service when the operation is completed. 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 returned when an error occurs in the service. These messages usually have a section that provides enough information to let the consumer know what the error is.
Messages are designed to integrate with existing systems: if you define an existing application as a service, you must ensure that every parameter used in the method (the method that implements the operation) can be found in the message. You must ensure that the return value is also included in the operation's output message.
One way to define your messages is: RPC style. When using RPC style, you define a part for each parameter in the parameter list. Each message part is based on the first type in types.
Your input message has one part for each input parameter, and your output message has one part for each output parameter. In addition, add a part to correspond to the return value. If a parameter is both input and output, it is listed as both an input and an output message.
RPC style message definitions are useful when the service is enabled on an existing system. It uses a mode transmission similar to TIBCO or CORBA. These systems are designed around processes and methods. Because of this, they are easiest to model using messages. RPC style also makes the mapping between services and applications clear.
Designing messages for SOAP services: While the RPC style is used to model inventory systems, service associations strongly prefer the wrapper document style. In wrapped document style, each message has one part. This part of the message refers to a wrapper element defined in the types element. The packaging element has the following characteristics:
Message naming: Each message has a unique name in its namespace. It is recommended to use the following naming rules:
Message part: The message part is the most commonly used unit of logical messages. Each part is defined using the part element. And through the name attribute, use the type attribute or element attribute to specify the data type.
Messages allow reuse of part names. For an instance, if a method has a parameter: foo, which is applied or passed in/out, it can exist as a Part in the request or response message. For example:
Example: Suppose you have a server that stores personal information and provides a method that returns employee data, based on the employee ID. The method is as follows:
personalInfo lookup(long empId)
The WSDL mapped to RPC style is as follows
The mapping to the packaging style is as follows:
...