Guideline
Pseudo One Way (POW) is one concrete realization of the conceptual One-Way operation. Functionally it behaves as a One Way operation to the application layer.
Technically POW is a SOAP Request-Reply over HTTP, but with a reply element indicating successful delivery of the message at the server side. This DLW wrapper for the response MUST only contain a {MetaInfo}ApplHeader element.
<xs:element name="ReceiveDebtSearchResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="ApplHeader" type="meta:ApplHeaderStruct" />
xs:sequence>
xs:complexType>
xs:element>
Explanation
The only transport protocols officially supported in SOAP/WSDL are HTTP and SMTP. HTTP is great for RR, since HTTP itself is request-reply. SMTP would be a solution for OW, but is not useable – it is not reliable and not suited for large messages3. Better candidates for OW are FTP and JMS, but FTP is not supported as a transport protocol by web service code generation tools or ESB’s and JMS is only supported in the Java world. Hence, for One Way there is not a good underlying transport solution.
Since HTTP is well supported in web services, could we have the advantages of FTP or JMS while still using HTTP? Yes, by decoupling http transport and business processing, as described below. We call this pseudo one-way.
Figure 1 - Pseudo One-Way
In Pseudo One-Way, the SOAP/HTTP message is technically request-reply, but functionally one-way. A Sender Application delivers the message through a SOAP Service Client at the SOAP Service Server. The latter only does schema validation, immediately followed by writing the message to a persistent store. The SOAP Service Server then sends a response element back to the SOAP Service Client, indicating that the message is successfully received and will be processed later on.
Somewhat later, probably after the SOAP Service Client has received the response, the Receiver Application will read the message from the persistent store and process it.
When the SOAP Service Server detects a validation error, or when it cannot write the message to the persistent store, it returns a fault to the SOAP Service Client. Errors are described later in this document.
‘Practical Problems’ with current Web Service standards.
The SOAP specification both supports request-reply and one-way using HTTP as the underlying protocol. Using HTTP for one-way just involves not specifying an HTTP response (because HTTP requires this) but the client will not receive a SOAP response, even if it contained an error indication!
Also note that in WSDL 1.x an operation can only be specified if there is also an
Therefore, in pseudo one-way, we use HTTP in request-reply for delivering the message by specifying a standardized
|
The pseudo one-way with HTTP is still not as reliable as JMS, which can be configured to be really transactional end-to-end. To achieve the same reliability as JMS this mechanism should be augmented by WS-Reliable Messaging. But if programmed correctly the solution described here is at least as good as FTP.
Share with your friends: |