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

Hi Sanjiva,

I think as Jean-Jacques indicated this perhaps needs a new name but, this is a
very valid case of one not needing a response but would want to know if the
operation failed. The current spec does not let you model / represent this, that
IMO is going to be needed. This could be as simple as making the response
optional in the request/response model..

Regards, Prasad

Sanjiva Weerawarana wrote:

> IMO one-way operations DO NOT return faults! We're of course talking
> about application level faults that are modeled in WSDL- if one indicates
> an application level fault then its no longer a one-way message!
>
> One can of course get many faults from the transport level for any
> message sent. WSDL doesn't model those faults for any case! That is,
> when opening a socket you may get an error, but obviously modeling
> that in WSDL would be very poor design!
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Sandeep Kumar" <sandkuma@cisco.com>
> To: "Prasad Yendluri" <pyendluri@webMethods.com>; "Jacek Kopecky"
> <jacek@systinet.com>
> Cc: <www-ws-desc@w3.org>
> Sent: Thursday, May 23, 2002 10:13 AM
> Subject: 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
> >
> >
> >

Received on Thursday, 23 May 2002 11:25:38 UTC