Title: RE: [wsrm-interop] FW: application level faults
Bob / Jacques - thanks for the
responses. See additional comment (inline):
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.
<Mark> But, if the receiving RMP waits for the SOAP response of the
upper layer before sending an ACK, then if there is a problem with the upper
layer, an ACK never gets sent - but the message has been received and persisted
to the store.
Thanks,
Mark
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: Wednesday, December 17, 2003
7:34 PM
To: 'Bob Freund'; WSRM Interop Group
(E-mail)
Subject: 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
