- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Thu, 23 May 2002 08:22:21 -0700
- To: "Nilo Mitra (EUS)" <Nilo.Mitra@am1.ericsson.se>
- Message-ID: <3CED092C.F98214D4@webmethods.com>
The issue of performance constraints (timeouts etc.) are at the concrete or binding level as with all other models and are orthogonal to this. These QoS aspects are identified as something that WSDL perhaps address via extension elements at the binding level already. Regards, Prasad "Nilo Mitra (EUS)" wrote: > 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:20:33 UTC