The Solicit-Response Pattern
The solicit-response operation includes one output element, which is the server’s request to the client, followed by one input element, which is the client’s response back to the server.
Figure 4 – The Solicit-response message pattern
In WeatherSummary.wsdl, the solicit-response pattern is defined in the operation verifySubscription.
<!-- Solicit-response -->
<operation name="verifySubscription">
<output message="tns:verifySubscription"/>
<input message="tns:verifySubscriptionResponse"/>
This operation consists of one output message verifySubscription and one input message verifySubscriptionResponse defined below.
<message name="verifySubscription">
This is the request message from the server to the client used to verify that the client exists and is reachable. There is no message content since the nature of the request requires no data.
<message name="verifySubscriptionResponse">
<part name="status" type="xsd:boolean"/>
This is the response message from the client back to the server. If the request reaches the client, it simply responds with a boolean true. Otherwise, the server receives some kind of error and knows that the client could not be reached.
This pattern requires the server to initiate a message and the client to receive one, so it uses the notification architecture to support this pattern. This architecture is described in Architecture of the Notification Classes.
This operation is implemented on the server side in WeatherSummaryImp.cpp, which makes the call to the notification proxy in WeatherSummaryNotificationProxy.cpp to send the verification request to the client. On the client side, the client implementation WeatherSummaryClient.cpp sets up a listener and a notification class, implemented in WeatherSummaryNotificationImp.cpp, receives the notification message.