First of all , thanks everyone for the informative replies. I may be sounding stupid here, but. If http://www.mysite.com/GetOrderStatus?OrderNumber=100 can be used for accessing a web service, then what is the difference between a normal web based app and this kind of web service? then can we term every web based app as "web service"?or how does it qualify to be called as the web service? Then someone said these kinds of web services dont need a WSDL. They how will these web services be "self describing"? How will the clients know the interface to this service? sorry for asking so many questions, but I am confused I guess. If these questions are too stupid, ignore them. I will try to do some research myself. :)
thanks all sudhir ----- Original Message ----- From: "Steve Loughran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 22, 2002 9:05 AM Subject: Re: Clients using GET and POST > > ----- Original Message ----- > From: "Tako Schotanus" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, May 22, 2002 12:47 AM > Subject: RE: Clients using GET and POST > > > > >Ah, it all becomes a lot clearer now. After reading the MSDN article I also > understand yesterday's post >about SOAP not needing WSDL and vise versa. The > fact that AXIS being a SOAP toolkit only supports >the SOAP binding for WSDL > is only logical. (That doesn't mean I wouldn't still like GET and POST > >bindings but I can live with the fact that the tasks may be at the bottom > of the pile :-) > > the nice feature of the .net toolkit for me is not the GET interface, it is > the form based UI, right? > > What would be nice would be a servlet to take a WSDL file, generate the > form, handle the form POST and turn it into a SOAP request against a > local/remote endpoint. > > There is some SOAP endpoint testing stuff on gotdotnet, but not a pure > server-side thingy > > >
