XFire, the light-weight, next-gen Java SOAP framework, has released milestone 4. New in this release are:
Permalink Comments off
Recently, I have been working on annotation support for XFire, the light-weight, next-gen, Axis-less Java SOAP framework. Basically, what we are aiming for is that you can use JSR-181-like annotations to export your web service:
package org.codehaus.xfire.annotations.sample; … @WebService public class EchoService { @WebMethod public String echo(@WebParam(name=“name”,header=true) String input) { return input; } }
You can see that you no longer need a service interface class to define what methods are exported @WebService annotates the class EchoService and the XFire runtime that it is a web service. @WebMethod annotates the method echo, and tells the runtime that the method can be invoked over the web. Finally, @WebParam tells the runtime that the echo method accepts a parameter, which should be expressed as SOAP header. Note that you no longer need a separate service interface to define the contract of your web service; you do so with annotations.
These are just examples, there are lots more annotations coming. Take a look at JSR-181 if you’re interested.
If everyone was running Java 5, then the above would be nice and dandy. However, some people are three versions behind and stuck on Java 2. Other people already use some sort of annotation framework, and do not want to use two in one project. Thus I decided to offer the annotation for two the most popular old-style annotation frameworks: Commons Attributes, and backport175. (As a matter of fact, these are the only kind of annotations supported at the moment because I’m developing on a Mac, and [Mac OS|Java] Tiger is still a month away).
The Commons Attributes version of the sample above would be very similar:
package org.codehaus.xfire.annotations.sample; … /** * @@WebService() */ public class CommonsEchoService { /** * @@WebMethod() * @@.input @WebParam(name=“name”,header=true) */ public String echo(String input) { return input; } }
And everything would work exactly the same as previously!
For you as a XFire user, this means that you can migrate from for instance Commons Attributes to Java 5 with minimal effort. All it should take is changing some imports and moving the annotations out of the Javadoc.
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.
Permalink Comments off