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

Prasad:

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

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
semantics.

Jacek:

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.

Comments?

Cheers,
Sandeep

 -----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?


  Jacek,
  Please see below in <PY>

  Regards, Prasad

  Jacek Kopecky wrote:

     Prasad,
     I respectfully disagree with making fire-and-forget a special case of
one-way-with-fault.
     Your example of email is not correct because email is unreliable by
definition.
  <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 !!).
  </PY>
    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
response.
    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:operation>
      </wsdl:portType >
  </wsdl:definitions>

  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.
  </PY>



     Best regards,
                       Jacek Kopecky

                       Senior Architect, Systinet (formerly Idoox)
                       http://www.systinet.com/

    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
describing
     > this  from an *intiator* perspective :-).
     >
     > In general there are cases when the sender would want to know if the
request
     > did not succeed. E.g. email, I want to know if there was a problem
delivering
     > 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
faults.
     > >  > 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