OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrm-interop] FW: application level faults


Title: RE: [wsrm-interop] FW: application level faults
Mark: inline.
-----Original Message-----
From: Mark D. Hansen [mailto:khookguy@yahoo.com]
Sent: Thursday, December 18, 2003 5:51 AM
To: WSRM Interop Group (E-mail)
Subject: 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.
[Jacques Durand] That is only true in case of "response" reply pattern. And in case of a one-way, since no app response is expected, the RMP needs not wait for a response (however, the app may decide of the HTTP status code to be sent back, and that may require same delay). In case of a req-resp, it is clear that the Ack will have to wait for the app response. But there is little we can do here, except use other reply patterns. (e.g. Sender could poll to get the Ack well before hte response is sent back.)

Your point that some message may be received and delivered, yet never acked, is right: but it is understood that there are cases where a Sender may never receive an ack for a delivered message. The reverse we guarantee: a Sender will NOT receive an Ack for a non-delivered message. Or, the following proposition is true as well: "When the Sender receives an Ack, it can be certain that the message has been delivered."

 

Thanks,

Mark

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
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:Bob.Freund@hitachisoftware.com]
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:khookguy@yahoo.com]
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]