W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

RE: Issue: Can One-Way operations return faults?

From: Sandeep Kumar <sandkuma@cisco.com>
Date: Wed, 22 May 2002 21:13:57 -0700
To: "Prasad Yendluri" <pyendluri@webMethods.com>, "Jacek Kopecky" <jacek@systinet.com>
Cc: <www-ws-desc@w3.org>

I support your viewpoint that  "One way operations SHOULD be able to return

However I disagree with your reliability argument. I agree reliability is at
the protocol/transport layer but
all the Operations have a semantics associated with it, though implicit.

For instance, Req/Resp means that a "response" is *reliably guaranteed* if
the *request* reaches the service provider/handler.
One could use Reliable or not so reliable transport to guarantee the above


If a requestor issues a one-way request such that the End-Point/Service
which happens to be in a state of NOT accepting messages
(it could be for a variety of reasons), the requestor should get a FAULT
from the Service Handler so that it can Re-Try.



 -----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Prasad Yendluri
Sent: Wednesday, May 22, 2002 12:45 PM
To: Jacek Kopecky
Cc: www-ws-desc@w3.org
Subject: Re: Issue: Can One-Way operations return faults?

  Please see below in <PY>

  Regards, Prasad

  Jacek Kopecky wrote:

     I respectfully disagree with making fire-and-forget a special case of
     Your example of email is not correct because email is unreliable by
  <PY>Where does reliability enter into picture at the abstract message
exchange pattern level? Reliability is a feature of the transport/message
service. A service definition at the abstract level makes no guarantees
about reliability. Email was an example for the use case where the sender of
one-way message would want to lean of a failure but not a success.
Substitute anything else for email something that uses SOAP/HTTP at the
message level (which are unreliable as well !!).
    Messages may disappear without anyone knowing. The
    fact that this doesn't happen much and the fact that most systems
    do report failures doesn't really change that - you can never
    rely on email.
  <PY>Sorry, irrelevant to the issue per above.</PY>
     Anyway, my point is that for fire-and-forget you only need
    one-way data channel. One end can be an SMTP sender and the other
    end can be a POP3 receiver.
  <PY>I guess this is not related to the subject issue as well but, I don't
believe SMTP<->POP3 interaction is valid. SMTP is an email MTA level
protocol and POP3 is a UA protocol.</PY>
    If a node is able to receive failures, it is able to receive success
responses, too. A
    one-way-with-fault is a special case of request/response with empty
    Already doable in WSDL, I believe.
  <PY> Not True! Here is the grammar for request/response in the current
spec. Note that note that wsdl:output is "required" and not optional.
  <wsdl:definitions .... >
      <wsdl:portType .... > *
          <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
             <wsdl:input name="nmtoken"? message="qname"/>
             <wsdl:output name="nmtoken"? message="qname"/>
             <wsdl:fault name="nmtoken" message="qname"/>*
      </wsdl:portType >

  The point is one-way with failure notification is a very valid and
practical usage pattern. If that can be realized as a special case of
request/response or enhanced one-way is acceptable. We need to cover the
case and either one requires a change to the current spec.

     Best regards,
                       Jacek Kopecky

                       Senior Architect, Systinet (formerly Idoox)

    On Wed, 22 May 2002, Prasad Yendluri wrote:

     > Jacek,
     > I see fire-and-forget as one special case of this that does not
really care
     > about knowing if the request succeeded or not. BTW, here you are
     > this  from an *intiator* perspective :-).
     > In general there are cases when the sender would want to know if the
     > did not succeed. E.g. email, I want to know if there was a problem
     > the message as in the recipient I am trying to reach is not a valid
one etc.
     > Regards, Prasad
     > Jacek Kopecky wrote:
     > >  Prasad,
     > >  I don't believe this is needed. An other name of one-way
     > > messages is fire-and-forget. This feature is seldom suitable, but
     > > sometimes you just don't need to know. 8-)
     > >  If we added the possibility of a fault, we would be adding the
     > > response at the same time, if only because no response ==
     > > success response.
     > >  IMHO one-way operations are exactly that, with the possibility
     > > of finding out the result or failure by other means, if the
     > > application requires it.
     > >  My proposal is to resolve this issue by saying "the current way
     > > is how we want it."
     > >
     > >                    Jacek Kopecky
     > >
     > >                    Senior Architect, Systinet (formerly Idoox)
     > >                    http://www.systinet.com/
     > >
     > > On Tue, 21 May 2002, Prasad Yendluri wrote:
     > >
     > >  > Currently the One-Way operations do not provide for returning
     > >  > That is, they only have a input message but no fault. Does that
mean a
     > >  > one-way operation must always succeed? What if the the request
is bad or
     > >  > somehow can not be processed and/or meets one of the SOAP-Fault
     > >  > conditions (assuming SOAP binding)?
     > >  >
     > >  > It seems desirable to permit faults with One-Way operations?
     > >  >
     > >  > Comments?
     > >  >
     > >  > Regards, Prasad
Received on Thursday, 23 May 2002 00:14:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC