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

+1

Don Wright



"Sanjiva Weerawarana" <sanjiva%watson.ibm.com@interlock.lexmark.com> on
05/23/2002 10:03:34 AM

To:   www-ws-desc%w3.org@interlock.lexmark.com
cc:    (bcc: Don Wright/Lex/Lexmark)
Subject:  Re: Issue: Can One-Way operations return faults?



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 Friday, 24 May 2002 07:34:31 UTC