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

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