Title: RE: [wsrm-interop] FW: application level faults
inline:
-----Original Message-----
From: Bob Freund [mailto:]
Sent: Wednesday, December 17, 2003 11:56 AM
To: WSRM Interop Group (E-mail)
Subject: [wsrm-interop] FW: application level faults
-----Original Message-----
From: Mark D. Hansen [mailto:]
Sent: Wednesday, December 17, 2003 2:48 PM
To: WSRM-Implementers (E-mail)
Subject: application level faults
Suppose my RMP-Sender gets an ACK indicating that the message sent has been persisted at the receiving end and is now the responsibility of the RMP-Receiver.
What if the receiver's application now generates a SOAPFault that is not a WSRM fault?
<Jacques> I guess we should focus on the case where the app-level (or post-RMP) SOAP fault is sent back on the HTTP response.
I do not pretend to fully answer this, as this case is
normally relevant to request-response MEPs, that we have not yet
properly addressed in WS-R so far. (We covered one-way ops, which normally
are not expected to produce any soap envelope in the HTTP response,
at least according to WS-I).
My comments would be:
- there must be at most one fault element in a SOAP body, and that is where
your app-level fault would be. But the WS-R fault is a header element.
So the RMP would be able to add a fault, in case of a "Reponse" replypattern,
if needed.
- in case an Ack is required with "Reponse" replypattern, the Ack element can be
added to the header as well.
How should this fault be propagated back to the sender?
<Jacques> This may be an application decision (a new HTTP request with the fault,
vs. the HTTP response to previous request).
If HTTP response expected for the fault, the RMP would process the SOAP response as follows:
For the Ack, depending on the reply pattern cases:
"response" : the RMP would have to wait for the app response - whatever it is -
and piggyback the Ack on it, when sending the HTTP response.
"callback" and "poll": no interference with the fault message above.
The RMP would then just pass any app response as is to HTTP server.
I realize that this is application level communication (not WRSM communication), but is has a lot of practical importance.
How are other implementers handling this?
<Jacques> According to our implementor Hamid:
an RMP may be implemented as a handler, that will "process" any SOAP response
generated by the upper layer of the WS stack (i.e. the application).
So regardless of the MEP type (one-way / req-resp), the receiver RMP will get the
app [SOAP] response, and can process it before passing to HTTP server.
Thanks,
Mark
