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

[Jacques Durand <JDurand@us.fujitsu.com>]

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:sunil.kunisetty@oracle.com]
Sent: Tuesday, February 24, 2004 9:56 PM
To: Jacques Durand; wsrm@lists.oasis-open.org
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:Sunil.Kunisetty@oracle.com]
Sent: Tuesday, February 24, 2004 12:38 PM
To: wsrm@lists.oasis-open.org
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.