Hi Sudhir. >My question though was, AXIS provides the api's to write clients for >document and the rpc based services. There are certain WSDL's with the >binding which reads like > ><binding name="AddressLookupHttpPost" type="s0:AddressLookupHttpPost"> ><http:binding verb="POST" /> ><operation name="CheckAddress"> ><http:operation location="/CheckAddress" /> >................. >verb could be GET as well.
Umm... I'll stick with my answer. Someone can correct me on this, but I believe the GET option applies to the MS trick I mentioned in the last email. With the MS trick, you're not submitting a SOAP Envelope at all; you are encoding your input parameters in the URL, like this: http://www.somecompany.com/somewebservice?param1=blah¶m2=blahblah which is all that HTTP GET allows. As Steve said (rather acutely), you can't submit an XML body in a GET request because a HTTP GET request is headers and a URL and that's all. Here's an example GET request from tcpmon: GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/pdf, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; .NET CLR 1.0.3705) Host: localhost:8000 Connection: Keep-Alive The top line is the GET command ("get the resource at / using HTTP 1.1") and the rest is headers. >Axis provides API's to write clients for document/rpc based services. Does >it provide API's to write the client for POST/GET based services? I assume >no. How else can I invoke it then. document/rpc refers to how the endpoints treat the SOAP envelope (as serialized objects or as an XML document), not the transport over which the envelope is carried. If you have the Axis servlet running and are sending requests with a typical client to a deployed service, you *are* using HTTP POST. >Moreover, if "You submit the form (also via HTTP GET) to the > > webservice, and it responds with a SOAP envelope. This is a trick that > > really has nothing to do with SOAP; the .NET client is acting as a > > miniature web server, and when you submit the form, the parameters are > > passed to the webservice in the URL as though the service were an ordinary > > CGI program or server page. " is the way to attck the problem, then the >concept of web services (applications talking to each other without need for >user intervention) is jeopardised. Am I correct or I missed somthing here? yup. MS does this for testing and showing off. Note that if you enter your Axis webservice's address in a browser's URL bar, you get a message that someday there may be a form there, indicating that the Axis developers see the usefulness of such an auto-generated form for testing (and perhaps showing off ;). But like I said, that really has nothing to do with "real" SOAP (other than that the results come back as a SOAP envelope). It's a convenience thing. Andrew
