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

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

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.