RE: [wsrm] Issues with RM with WSDL 1.1 R-R operation

What can we say in this 
WS-R version, regarding the handling 
of Request_Response ops 
(Jacques / Hamid):

Short answer:

- Guaranteed delivery: Not 
supported, and in fact not really relevant.

the case for (first leg 
of) R-R is weak as Sunil pointed out. Technically, the GD contract is supported 
without need for RMP functions: we know 
that a failure will always be detected (see details), but at application 
level. "Retries" cannot be supported transparently 
to the application. So the point here 
is not so much that a Response stands for 
a synchronous Ack, but that a failure cannot be handled transparently from the application layer, which defeats the purpose of a transparent resending 
mechanism the goal of which is precisely to recover from a 
failure.

- Duplicate Elimination: relevant, and available as is.

This still makes sense for 
(first leg of) R-R. Although duplicates 
will not be caused by a resending mechanism (see above), they may be generated from an intermediary. Note that "Ack 
for delivered duplicates" would not makemuch sense like it does in One-Way 
cases, because precisely we assume no deliberate resending behavior on the 
Sender RMP side (so there is no point trying to "restrict" these).  

- Message Ordering: not relevant to R-R ops (see below). 

 

Detailed answer:

Guaranteed delivery: 

- WS stacks make R-R operations as part of a same application 
transaction: an application sending a 
request will usually block while waiting for the response.

- An RMP implementation has little control on the connection. If 
the connection that carries the req-resp 
fails, the sender RMP cannot generally "recover" 
or simulate a good connection to the application: in most stacks this 
will translate in an exception at 
application level. So a resending mechanism 
would not be able to "hide" the failure to the application, and recover 
transparently. Unless the (sender) RMP is 
implemented as a separate SOAP node that controls the coupling between its upstream and downstream 
connections.

Message Ordering: 

- Because req-resp are synchronous calls from the application, a 
sequence of such calls cannot get out of 
order to the receiver (a response has to be obtained before the next call is executed). So the Ordering feature is not necessary.

 

Hamid & 
Jacques

 

  
-----Original Message-----
From: Sunil Kunisetty 
  [mailto:]
Sent: Tuesday, February 24, 2004 
  9:56 PM
To: Jacques Durand; 
  
Subject: Re: [wsrm] Issues with RM with 
  WSDL 1.1 R-R operation

  
  
Sunil Kunisetty wrote: 
    
    
Jacques Durand wrote: 
      
      
There was also a 4 pages study we did back in October on 
      the implications 
of supporting 
    R-R.
 Isn't that document related 
    to Ack on 'Response' scenarios? As far as I recollect 
 it is not related to the 'Request' case as we are dealing 
    correctly. Oops. I meant 'as we are 
  dealing currently'. 
    
     
I wouldn't rule out RM for the 
      first leg of R-R, 
unless we face real issues or 
      that requires more work, Don't you 
    think the issues (1) & (2) mentioned below are for real? 
    
 -Sunil 
     
which I am not sure it is the 
      case. 
Can we hold on this one? I'd like our 
      developers to look into this 
within the next 
      couple of days, as the main issues we seem to have 
are on the deployment side within existing WS stacks. 
      
Jacques 
      
-----Original Message----- 
From: 
      Sunil Kunisetty [mailto:] 
      
Sent: Tuesday, February 24, 2004 12:38 PM 
      
To:  
Subject: [wsrm] Issues with RM with WSDL 1.1 R-R operation 
      
  
      
 Just for the heck of it, I wanted to consolidate 
      the problems with using RM 
 with WSDL 1.1 
      R-R operation: 
      
 1) Issues with batching/piggybacking Acks or Faults 
      as mentioned in this thread and many other threads: 
        http://www.oasis-open.org/archives/wsrm/200402/msg00194.html 

      
 2) Issues with DE in R-R case as Tom mentioned in 
      this mail: 
        http://www.oasis-open.org/archives/wsrm/200402/msg00212.html 

      
3) Message ordering is not that useful and efficient in 
      the R-R case 
      as 
      the clients may be blocked for the 'buffered' messages. 
      
 4) GD in general is not a big requirement as a 
      Response can be 
     
      construed as an Ack. 
      
 5) If not for Response pattern, the use of RM fault 
      mechanism to 
     report RM 
      errors is a clear winner. The only case SOAP Fault 
     mechanism can be used to report RM errors 
      is the Response 
     pattern 
      case. 
      
 So do we really need to support RM features for 
      WSDL 1.1 R-R operation? 
      
 Again, I'm not suggesting to remove it haphazardly, 
      but lets think about it 
 for one final time 
      before it becomes too late. 
      
 -Sunil 
      
To unsubscribe from this mailing list (and be removed 
      from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.