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

Jacek,

Unfortunately you are still confusing my email example with transport level reliability
issues. Please don't. HTTP facilitating one learning of a transport level failure is
irrelevant.

The issue is 'permitting notification of failures for one-way messages (that do not require
a response)'. Use the most reliable transport you want as for the same WSDL abstract level
service one can use multitude of transports. It is not a transport level failure issue. The
failure condition that needed to be communicated could be in the content of the specific
message.

>This is what I meant by an empty response (as opposed to no response).

Empty response is not the same as no response. The oneway-with-faults is the case of *no
response* going back (as in one-way!).

>If you can have a oneway-with-faults as a special case of
>request/response, I suggest that's what we agree on.

The current request/response type does not cover the *no response* case. I submit that the
current definition of request/response or one-way needs to change to accommodate
oneway-with-faults.

Regards, Prasad


Jacek Kopecky wrote:

>  Prasad, please see inline. 8-)
>
>  > >  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>
>
> In HTTP you get to know about a failure. In case of _any_
> failure, you will at least know something went wrong. In fact,
> sometimes you may think the call failed but the server thinks the
> call succeeded.
>
> On the other hand in email, you don't know something went wrong
> unless you receive a failure message. This is where the seemingly
> irrelevant text below comes in - you may think the message was
> successful and the server may have never received the message or
> it may have failed.
>
>  > > 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>
>
> SMTP is used to send email to a mailserver. POP3 is used to
> receive email from a mailbox. The stuff in between doesn't matter
> now. So while in HTTP this protocol is sufficient to send *and*
> receive a message, in email you need two protocols because it is
> extremely unusual that email be sent directly. No mail receiving
> agent I know is capable of receiving an email message from a mail
> sending agent.
>
>  > > 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>
>
> What I imagined was something like this:
>
>  <message name="request">
>     ... parts ...
>  </message>
>  <message name="response"/>
>  <message name="failure">
>     ... parts ...
>  </message>
>
>  <operation>
>    <input message="request"/>
>    <output message="response"/>
>    <fault message="failure"/>
>  </operation>
>
> This is what I meant by an empty response (as opposed to no
> response).
>
> If you can have a oneway-with-faults as a special case of
> request/response, I suggest that's what we agree on.
>
> Best regards,
>
> Jacek

Received on Wednesday, 22 May 2002 16:31:38 UTC