The Codehaus XFire team is proud to announce their 1.0 release! XFire is an open source Java SOAP framework built on a high performance, streaming XML model. XFire includes support for web service standards, an easy to use API, Spring integration, JBI support, and pluggable bindings for POJOs, JAXB, and XMLBeans.

Find out more information by downloading it yourself or viewing the user's guide.

XFire 1.0 features include:
* Support for WSDL 1.1, SOAP 1.1 and 1.2, WS-Addressing, WS-I Basic Profile 1.1
* Pluggable bindings for POJOs, XMLBeans, JAXB 1.1, JAXB 2.0, and Castor support
* Support for many different transports - HTTP, JMS, XMPP, In-JVM, etc.
* Spring, Pico, Plexus, Loom, and Yan support
* Embeddable and Intuitive API
* Client and server stub generation
* JSR 181 2.0 API to configure services via Java 5 and 1.4 (Commons attributes JSR 181 syntax)

XFire is reallye cool when used with Spring POJOs but unfortunatle it does not provide easy hook to have XFireServlet->EJB->POJO (the XFireServlet->POJO forces POJO to be thread safe) setup like Weblogic SOAP adapter provides.

Hi Tsolak, did you know you can create your own Invoker for your service very easily? In fact, there is an example EJB invoker in the manual that someone wrote:

http://xfire.codehaus.org/Invokers

Hope that helps.

Thanks Dan,
That is close what I want but would like to have XFire generate and invoke Session Bean transparently for me.

Hi,

Can any one from Spring Framework team or XFire team compare the Spring Web Service project and XFire?

Are they trying to achieve the same thing?

Thanks,

Jason

Hi, Can any one from Spring Framework team or XFire team compare the Spring Web Service project and XFire?Are they trying to achieve the same thing?

Well, since I did work on both, I guess I should answer this one. To answer your last question first: they achieve the same thing in the sense that they both do SOAP.

XFire is an integrated SOAP solution that is based on StAX, the fast Streaming API for XML. I would say that the focus of XFire lies on exposing Java classes as remote SOAP objects, using various XML bindings. For instance, it is really easy to expose a Spring-managed class as SOAP service using XFire, or to use JSR 181 annotations in it. I believe there are also plans to support JAX-WS.

Spring-WS really consists of two modules. First, there is a module that abstracts over various XML marshalling toolkits. You can use this module in various surroundings, Web Services being just one of them. Second, there is the Web Service module itself, which focusses on doing document-driven, contract-first SOAP with a design based on Spring-MVC.

I think that both solutions have their place; it all depends on the specific requirements for the Web service you are making.

There are no lies with regards to the high performance SOAP features of XFire. Recently I did a performance run on XFire with our security product IDX. I was able to achieve almost 220 TX/sec with the framework.

You can read about the results here: http://www.jstepka.name/blog/?p=18

XFire + Spring + XMLBeans = a winning combination in ease of use, performance, strong validation and configurability.

Only thing I still miss in XFire is the support for attachment handling.

Great work!

I totally agree on the missing attachments need.. I think XFire looks really nice and has done a good job working with other environments. I hope Attachment support is forthcoming.

I also know that WS-Security is on the road map, and that will be great once it comes along..

XFire + Spring + XMLBeans = a winning combination in ease of use, performance, strong validation and configurability.

If I recall correctly then XMLBeans could kill all the performance gains easily because they always work with underlying XML document. I mean that an attempt to XMLBeans as regular POJO Beans leads to very slow code execution.

Am I correct?

Konstantin,
Yes and no. Check out the performance metrics here:

https://bindmark.dev.java.net/

XMLBeans is actually quite fast. BUT, if you start workign with the objects all the time as you would pojos, thats goign to cause a lot of overhead because you'll be modifying the XML structure everytime. So, the lesson is, IMHO, to use XMLBeans as data transfer objects, but not business objects.

I prefer JAXB 2 to XMLBeans though. It has a great API and is also quite fast.

If I recall correctly then XMLBeans could kill all the performance gains easily because they always work with underlying XML document. I mean that an attempt to XMLBeans as regular POJO Beans leads to very slow code execution.Am I correct?

If performance is the number one priority, then you might be better of with plain POJOs and Aegis binding. On the other hand, if you care about XML schema model and validation options that it provides for crafting clean APIs, then XMLBeans is a very good option.

XMLBeans is based on the same StAX API as the XFire uses, so its performance is quite decent:

http://workshop.bea.com/xmlbeans/schemaandperf.jsp
https://bindmark.dev.java.net/

"Unlike DOM, XMLBeans doesn't take the approach of unmarshalling an entire XML document and providing an object for each node in the XML document. With XMLBeans, unmarshalling and marshalling happens on demand, so if you never look at a piece of data, it's never unmarshalled or marshalled. This improves the performance of the XMLBeans solution."

http://www.onjava.com/pub/a/onjava/2004/07/28/XMLBeans.html?page=2

Congrats to Dan and the XFire team!!!

Xfire is really a nice package for web services, and especially easy to use with Spring and JSR-181 annotations. I can't wait to try out the JAXB 2.0 bindings.