- From: Nilo Mitra (EUS) <Nilo.Mitra@am1.ericsson.se>
- Date: Thu, 23 May 2002 10:02:25 -0500
- To: www-ws-desc@w3.org
- Message-ID: <C358DED30DFED41192E100508BB3922701EE7A7A@eamrcnt716.exu.ericsson.se>
Jumping in as an "outsider", I have a question: In the case of the so-called "one way with faults", how long should the requester wait before assuming success, i.e., that a fault is unlikely to be returned? I think it is issues like this that make the "one way with faults" somewhat difficult to model. One crude solution is to define a timer....but this is not clean. Thoughts, comments? Nilo Nilo Mitra Ericsson, Inc. phone: 516-677-1073 mobile: 516-476-7427 mailto:nilo.mitra@ericsson.com -----Original Message----- From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] Sent: Thursday, May 23, 2002 10:04 AM To: www-ws-desc@w3.org 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 Thursday, 23 May 2002 11:02:28 UTC