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
>