More on SOAP, Axis and Web Services

While it is only xml in SOAP format that goes over the wire we can do anything with the SOAP xml on either side(client or server) such as bind it to java objects etc. The Axis library can do this for instance. On client/server sides you can pass objects and expect objects in return, similar to java serialization.
Server war + wsdd deployment descriptor = SOAP server.
wsdd is the depl descriptor.
Let’s say you have a java class that you want to expose as a web service (the “server” side of web services). So the java class that we want to expose as a web service we put in WEB-INF/classes of a war file or package in WEB-INF/lib as a jar file.
You put the axis.jar in WEB-INF/lib of a war for instance, edit the web.xml to add an entry for the AxisServlet and package the war and deploy. So the war contains your code and it also contains axis.jar. The axis servlet can be invoked from outside (like http://localhost:8080/AxisServlet), since we added AxisServlet in web.xml. But now the problem is Axis doesn’t know about your java class though they are in the same war. So you write a wsdd, which is like an xml configuration file that tells Axis about your java class at deploy time/ runtime. So when an incoming request comes using http Axis parses the request xml, extracts values from it and converts the parameters to java objects and invokes your class. So the ‘server’ part of webservice is ready.
If we are exposing a service which may not be a simple class but a complex application you can put your java application in a war containing axis.jar or you can put axis.jar in your existing complex app which is pretty much the same thing. If the service has ejb too, the war can be inside the ear and AxisServlet can still be accessed externally. There can be ejbs that can be invoked by your java class, but that’s all back end processing.
So once you have your webservice ready it is available for client applications to invoke it.
The wsdl is a description of your webservice. wsdl creation is automatic. If you are successful in creating your web service, the client can just do http://localhost:8080/AxisServlet/foo?wsdl to get the wsdl.The client programmer takes the wsdl from you and runs wsdl2java tool to create stub java classes. wsdl2java tool can be used to create client side java objects(stub and skeleton) from the web service wsdl and the client code can invoke the stub’s method as usual, and unbeknownst to it the stub will convert the java call to a webservice call over the network in xml.
wsdl+ axis jar file+java proxy = SOAP client.
The client programmer would need axis.jar to access the wsdl2java tool inside the axis.jar The client programmer uses wsdl + axis.jar to create the stub and once the stub is ready he uses the stub + axis.jar to invoke the webservice.
The server side can be java and client side be any technology, or vice versa. As SOAP is technology agnostic and since it is xml going back and forth it could be any technology on either side. You could write the web service with whatever tools .net provides for instance. The soap response format is the same whether its java .net or C++ (basically xml).
Example of a web service using Axis 1.4

About cuppajavamattiz
Matty Jacob - Avid technical blogger with interests in J2EE, Web Application Servers, Web frameworks, Open source libraries, Relational Databases, Web Services, Source control repositories, ETL, IDE Tools and related technologies.

Comments are closed.

%d bloggers like this: