Spring’s Quest for SOAP draws at an end

This is the third post in a series about using Spring and SOAP. It started with this post, then I rambled on, and this is probably the conclusion.

When I started this quest, it seemed simple. I wanted to expose my business interfaces via SOAP. I wanted the WSDLs to be generated automatically, and I wanted the value objects I used as parameters to be converted automatically. Most of all, I didn’t want to change my business interface just to support a remoting protocol. After all, I might want to support another protocol in a year or so, and did not want to change it again then.

While the quest seemed easy, I had to fight through fightthroughmanyspecifications just to figure out how SOAP was supposed to work in Java.

Then, the cavalry arrived, in the form of Dan Diephouse. He pointed me to his excellent XFire framework, which he updated this weekend to include Spring support. With the code currently in the XFire CVS (which will be part of the M4 release), you can export you business interface ServiceManager, with the implementing bean called myService like so:


  
  
    jteam.managers.ServiceManager
  
    
    

Just what I wanted! :-) The above is just a short extract; for more information on XFire and Spring, visit this web page.

Of the three Java SOAP frameworks I’ve tried (the other two being Axis and ActiveSOAP, I tend to prefer XFire. Axis seems too complicated, and ActiveSOAP just doesn’t feel finished. XFire is simple, and does what it needs to do.

Comments are closed.