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

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

Mark: inline.

  
-----Original Message-----
From: Mark D. Hansen 
  [mailto:]
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:]
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