WSDL Messaging Exchange Patterns





WSDL Messaging Exchange Patterns

There are four basic message exchange patterns (MEPs) used in Web services: Request/Response, One-Way, Notification, and Solicit/Response. Although Notification and Solicit/Response messaging are supported by WSDL, they are not supported by the Basic Profile,BP and are rarely used in practice. Most WSDL-based Web services today use either Request/Response or One-Way messaging,[2] and they're the only MEPs that can be used with J2EE Web Services.

[2] This may change with the introduction of WSDL 1.2, which supports a larger set of messaging patterns.

A WSDL document can dictate the MEP for a specific operation by the way it declares its input and output elements. Figure illustrates the chief difference between Request/Response and One-Way messaging: In the former, the sender expects a reply; in the latter it doesn't.

Comparing Messaging Modes: Request/Response versus One-Way

graphics/05fig03.gif

1 Request/Response Messaging

In Request/Response messaging the client initiates the communication by sending the Web service a request message, and the Web service replies with a response message.

If an operation is declared with a single input element followed by a single output element, it defines a Request/Response operation. By listing the input first, the operation indicates that the Web service receives a message that is initially sent by the client. Listing the output second indicates that the Web service should respond to the message. The following snippet from Listing 5-2 represents a classic Request/Response operation, with exactly one input and one output.

<!-- portType element describes the abstract interface of a Web service -->
<portType name="BookQuote">
  <operation name="getBookPrice">
    <input name="isbn" message="mh:GetBookPriceRequest"/>
    <output name="price" message="mh:GetBookPriceResponse"/>
  </operation>
</portType>

In addition to its one input and one output, a Request/Response operation may also include fault elements, which are returned to the client in the event of an error. A Request/Response operation can have zero or more faults. The following snippet illustrates.

<portType name="BookQuote">
  <operation name="getBookPrice">
     <input name="isbn" message="mh:GetBookPriceRequest"/>
     <output name="price" message="mh:GetBookPriceResponse"/>
     <fault name="InvalidArgumentFault" message="mh:InvalidArgumentFault"/>
     <fault name="SecurityFault" message="mh:SecurityFault"/>
  </operation>
</portType>

2 One-Way Messaging

In One-Way messaging, the client sends a message to a Web service, but doesn't expect a reply message. This MEP is typically thought of as asynchronous messaging. Next to Request/Response, it is the most popular MEP employed today.

If an operation is declared with a single input but no output, it defines a One-Way operation. By listing only an input message, the operation indicates that clients will send messages to the Web service without expecting a response. The following snippet shows the SubmitPurchaseOrder portType that defines a One-Way operation.

<portType name="SubmitPurchaseOrder_PortType">
  <operation name="SubmitPurchaseOrder">
     <input name="order" message="mh:SubmitPurchaseOrderMessage"/>
  </operation>
</portType>

Unlike Request/Response operations, One-Way operations may not specify fault elements and do not generate fault messages. The messaging model is strictly unidirectional—faults cannot be sent back to the client.

3 Notification and Solicit/Response Messaging

Neither the Notification nor the Solicit/Response MEP can be used in J2EE Web Services. The unwillingness to support these styles is practical because they are poorly specified by the WSDL 1.1 specification and tend to introduce more problems than they solve. On the other hand, it's probably a good idea for you to understand the basic mechanics of these MEPs just for general purposes.

In Notification messaging the Web service sends a message to a client, but doesn't expect a reply message. A Web service that uses the Notification MEP follows the push model of distributed computing. The assumption is that the client has registered with the Web service to receive messages (notifications) about an event. The clients that register to receive notifications are called subscribers. In Notification messaging, the portType contains an output element but no input message definitions.

Solicit/Response is similar to Notification, except that the client is expected to respond to the Web service. As with Notification messaging, clients of Solicit/ Response Web services must subscribe to the service in order to receive messages. In this MEP the portType first declares an output message, then an input message—exactly the reverse of a Request/Response operation.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows