- From: Jacek Kopecky <jacek@systinet.com>
- Date: Wed, 22 May 2002 22:00:18 +0200 (CEST)
- To: Prasad Yendluri <pyendluri@webMethods.com>
- cc: www-ws-desc@w3.org
Prasad, please see inline. 8-)
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Wed, 22 May 2002, Prasad Yendluri 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>
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:00:22 UTC