Zero Fat( read: XML), Zero Cholestrol(read: Annotations) Web Services!

I have never been an advocate of XML per-say.
And I was faced with the difficulty of writing one recently overwhelmed by the amount of XML and Annotations, well I was looking forward to a hard day ahead. 

Then motivated to defeat XML in my own war, and reducing its footprint in the codebase I am working on, I put on the searching glasses and XFire came to the rescue(credits to them for integrating WS in the most cleanest manner done with Spring, that I know of!)

Now that the plot is set, here’s simple how to:

Presumption: You have two different projects one is the WS other is the consumer of the WS.

Step 1/ Write your service and its implementation in the WS project.
(eg: XXXService/XXXServiceImpl for the project YYY)

Step 2/ Configure the usual project as a spring web project.

Step 3/ Add the following snippet into the web.xml(append incase you have contextConfigLocation predefined.). This makes your project XFire aware.


Step 4/ Expose the service as Http WS through XFire Exporter:


Step 4.2/ Inject the Service Impl Bean.

Step 4.3/ Configure the Url for accessing the Service.


Step 5/ Deploy the WS project an tomcat/jboss.


|| End of Server Side Configuration||

Step 6/ Test using the soap url:: http://localhost:8080/YYY/XXXws?wsdl

Step 7/ Configure the XFire client on the other project as follows:


Step 8/ Inject it in your client


Step 9/ The client should be configured as::

public class WsClient{    private XXXService xxxService;}
|| End of Client Side Configuration||

Step 10/ Done!

Things to remember::
1/The Java Interface XXXService needs to be shared with the client.
One can overcome this by creating a third common project shared for the WS Provider and WS Consumer.

2/Any changes in the WS provider, would require re-deployment of the first project.
This is the least a java developer(xml unfriendly) can absolutely live with!

3/Once these configurations are done, forget that you ever need to look into the xml’s!
Also any change addition/removal of the methods that needs to be exposed will be purely a java exercise, without requiring to smell XML.
Well you won’t be able to find any xml!!!, thanks again to the wonderful folks at XFire!

PS: All these steps are written here with the help of and implementing this in a production environment!

Hope this helps you in reducing the amount of unnecessary XML’s in your java projects!