The XFire team has released version 1.1, an open source Java SOAP framework with support for Web services standards, Spring, JBI and pluggable bindings.

New features in this release include:

• MTOM attachment support
• WS-Security support
• Improved WSDL code generator

Download XFire 1.1.

Congratulations from your colleagues from the XINS team :-)

I looked at your Quick Start and it's really nice. It's really really quick and it shows already what the approach is, more or less, and what role XML, WSDL and Java play in XFire.

Ernst
http://xins.sourceforge.net/

I used XFire for a project last year (large bank, I hope/ think they are now using it for all their web services), and really liked it. It was a pleasure to step throught, and a perfect example of a framework that really helps you out instead of getting in your way.

I used XFire for a project last year (large bank, I hope/ think they are now using it for all their web services), and really liked it. It was a pleasure to step throught, and a perfect example of a framework that really helps you out instead of getting in your way.

As Rolf Howarth writes: A good framework can sometimes help developers by avoiding you having to reinvent the wheel each time, but a bad framework is infinitely worse than no framework at all. Designing good frameworks is very, very hard.

See: http://www.squarebox.co.uk/download/javatips.html

We use Axis now and have all problems mentioned in the previous thread (too complex to debug, slow, etc). This weekend we have tried to replace Axis with XFire and found it similar to Axis in complexity and its just slight faster (about 20-25%) for our tasks. Some problems: 1) Documentation (as said before). Examples are too basic. 2) JDK 1.4.2 does not supported for client. 3) How to generate WSDL if we have no application with XFire online (something like Java2WSDL)? 4) XFire generates stubs (using wsgen) using own types (for example, JAXBElement instead of String). How to avoid this ? Maxim Kramarenko TrackStudio - Hierarchical Issue Tracking

...
This weekend we have tried to replace Axis with XFire and found it similar to Axis in complexity and its just slight faster (about 20-25%) for our tasks.

Hi Maxim. Just out of curiosity, did you move from Axis 1.x? And also, what size are your typical messages? Although speed differences vary a lot, usually difference is somewhat higher than 20-25%, esp. for bigger message sizes, at least for actual messaging part (parsing, data binding, serializing).

>Hi Maxim. Just out of curiosity, did you move from Axis 1.x? And also, what size are your typical messages? Although speed differences vary a lot, usually difference is somewhat higher than 20-25%, esp. for bigger message sizes, at least for actual messaging part (parsing, data binding, serializing).

No, we have decided to stay with Axis because after 15 hours of debugging, XFire doesn't finally work. I cannot say that Axis was simpler (actually, it was complex too), but we have no reasons to replace one complex thing with another. Most messages quite small (several KBs), but we need a lot (100 calls per second on localhost, for example) of simple and small calls. Possible, this means that such perfomance is not possible with SOAP and we should modify our API to avoid such calls. -- Maxim Kramarenko TrackStudio Enterprise - Hierarchical Issue Tracking

No, we have decided to stay with Axis because after 15 hours of debugging, XFire doesn't finally work.

Means you, XFire is failing or means you, XFire's performance differs from your general ideas of this aspects. What are the real performance-differences of your debugging-tests between XFire and e.g. Axis with identical requirements ? I think, performance is a criterion which depends deeply from various factors (e.g.: what systems are used, how are the tests implemented, ...). Using generalized protocols how SOAP, needs naturally more time for things how parsing ..., but makes on the other site an integration more transparently and independently. -roland

Means you, XFire is failing or means you, XFire's performance differs from your general ideas of this aspects.

I mean that we have implemented some basic functionality (enough for perfomance testing), but cannot get it working in some other cases: 1) Stub classes generated using wsgen uses JAXBElement instead of String. This is a problem for us, because it means that we (and our customers) should rewrite a lot of code. 2) Using XFire, we cannot call SOAP API directly from browser, like described there http://www.trackstudio.com/documentation/35/html/Using_SOAP_from_Web_Browser.html 3) We cannot call method that should return our custom class, got an exception === org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Couldn't instantiate class. javax.xml.bind.JAXBElement === We even tried to generate stub classes using wsdl2Java (instead of wsgen), but method call just returns null in this case. I suppose that some of above mentioned problems can be resolved, I just mean that XFire is not too easy compared to Axis in our case.

What are the real performance-differences of your debugging-tests between XFire and e.g. Axis with identical requirements ?

We have about 17 calls per second for XFire and 14 calls per second for Axis.

I think, performance is a criterion which depends deeply from various factors (e.g.: what systems are used, how are the tests implemented, ...).

Using generalized protocols how SOAP, needs naturally more time for things how parsing ..., but makes on the other site an integration more transparently and independently.

We use SOAP API to let our customers to integrate our system with third-party systems. Actually, our SOAP API is just a wrap over kernel methods, both web client and Swing client (over SOAP) uses the same set of API calls: http://www.trackstudio.com/documentation/35/html/Integrating_with_Third-Party_Systems.html But some API calls (load an object by ID, for example) should be called quite often. This is not a problem for direct calls but too slow for SOAP calls, and XFire cannot help us :-( Maxim Kramarenko TrackStudio Enterprise - Hierarchical issue tracking.

Stub classes generated using wsgen uses JAXBElement instead of String.

XFire uses JAXB? Why would anyone choose to use JAXB?

Why would anyone choose to use JAXB?

Why not? It's great for small and mid-sized XML files!

Why would anyone choose to use JAXB?

Why not? It's great for small and mid-sized XML files!

The why not would be that it doesn't really perform the task of xml to Object mapping. It's a code generator and not a very good one. Any change to the schema requires regenerating the classes and then modifying code in order to get the data in the right places. The whole design was poorly thought out.

Why would anyone choose to use JAXB?

...

It's a code generator and not a very good one. Any change to the schema requires regenerating the classes and then modifying code in order to get the data in the right places. The whole design was poorly thought out.

Actually, JAXB 2.0 is quite different from JAXB 1.0, and MUCH better. So if your experiences are from 1.0, you may want to check out 2.0. I have heard many developers (esp. ones who found 1.0 less than optimal) think highly of 2.0.

Why would anyone choose to use JAXB?

...

It's a code generator and not a very good one. Any change to the schema requires regenerating the classes and then modifying code in order to get the data in the right places. The whole design was poorly thought out.

Actually, JAXB 2.0 is quite different from JAXB 1.0, and MUCH better. So if your experiences are from 1.0, you may want to check out 2.0. I have heard many developers (esp. ones who found 1.0 less than optimal) think highly of 2.0.

I just looked at the tutorial and it looks pretty much the same to me. Schema in, classes out. Please be clear that I am not really talking about the implementation of this approach but the approach itself. It's compeltely unecessary. If there is a way to map xml without generating any data clases using JAXB, I'd be willing to reconsider my assessment. I can't find documentation on how that would be done (not that I looked all that hard.)

Regarding performance, in my tests XFire is at a baseline 2-2.5x faster than Axis 1.x. It can reach up to 5 or 6x faster if you have large messages and do other tweaks. A couple notes if you're trying to do some performance tests with XFire: * Make sure that you aren't using the stax reference implementation, make sure you're using the latest woodstox - 2.9.3. * Make sure you let the performance tests run for at least 30 or 40 seconds before trying to take a reading. JIT does a lot for xfire. Its not uncommon to see the performance double over the first minute * Make sure you're running the jvm with "-server -XX:+UseParallelGC"

Means you, XFire is failing or means you, XFire's performance differs from your general ideas of this aspects.

I mean that we have implemented some basic functionality (enough for perfomance testing), but cannot get it working in some other cases:

1) Stub classes generated using wsgen uses JAXBElement instead of String. This is a problem for us, because it means that we (and our customers) should rewrite a lot of code.

This is a bug in 1.1 I believe. We'll be post a 1.1.1 soon with fixes. We hope you'll give it another whirl then.

... between XFire and e.g. Axis with identical requirements ?

We have about 17 calls per second for XFire and 14 calls per second for Axis. This sounds awfully slow, at least if you have multiple clients: throughput should definitely be measured at hundreds of messages per second, not a dozen. However, if you only have a single client doing end-to-end requests, the speed increase is more limited. Speed of a single request can not be increased as much or as easily as the total throughput. Like Dan mentioned, there have been major performance improvements within XFire, as well as underlying parser implementation (Woodstox) during past few months. So trying out XFire 1.1 is worth it, even if one has experiences from earlier versions.

No, we have decided to stay with Axis because after 15 hours of debugging

Oh, what I meant to ask was if you were using Axis 1.x, instead of Axis 2.x. The reason is that Axis 2.x is supposed to be quite a bit more performance than 1.x, and thus performance differences might be smaller.

Now, getting 100 requests per second through should actually be a breeze (assuming business logic is fast enough); SOAP part should not prevent such load. Anyway, good luck with your development.

Document, Document, Document!!!

The documentation is unfortunately extremely incomplete. Also, it's not quite trivial to specify a custom schema for operation inputs and outputs.

Otherwise, XFire is looking like it's going to beat the pants off Axis2 and JAX-WS RI...

Document, Document, Document!!!

he said, and volunteered to do it.

Congrats to Dan and the team! XFire is definitely the best SOAP stack out there that I've seen. We use it and we're very happy with the ability to declaratively define web services from our service methods using annotations and have them automatically exposed via Spring when the beans are loaded.

When is JAX-RPC is going to be supported?
I would really like XFIRE being able to work with JaxRpcPortProxyFactoryBean.

Have you seen our JaxRpcPortProxyFactoryBean look alike? http://xfire.codehaus.org/maven/api/org/codehaus/xfire/spring/remoting/XFireClientFactoryBean.html

I would have been easier to use xFire if the documentation was improved. I was a bit suprised by lots of empty javadocs.

Works as expected. For me documentation is not as important as the following to the existing patterns and naming conventions. In JaxRpcPortProxyFactoryBean the method which takes service interface is "serviceInterface" versus "serviceClass" in XFireClientFactoryBean. It would make sense to follow JaxRpcPortProxyFactoryBean naming convention.

serviceClass was chosen because with JSR-181 you need to pass along the implementation class since it contains important annotations - like the @SoapBinding or @WebService annotations.

Congratulations for this new advance.

We use XFire for integration-scenarios with Apache ServiceMix. Both solutions are very powerful and building together a very flexible and potent integration-engine.

-roland

I'd like to try out XFire, but there is an outstanding JIRA issue that says it doesn't work with Spring 2.0 because of an XBean bug that is difficult to fix without major work in XBean. It appears to still be an open issue.

There is only one thing that doesn't work with spring 2.0 and that is the services.xml file format. However if you're using Spring 2.0 you can use the normal spring bean syntax. Check out how to use the ServiceBean class here: http://docs.codehaus.org/display/XFIRE/Spring%2C+XBean%2C+Servlets+and+more

Does anybody know what happened with XFire site ? I'm unable to acess it for about a week?

I noticed too! they're in trouble?? this helped me: http://netzooid.com/blog/2006/05/16/xfire-site-down-mirror-available/

Sorry for the downtime everyone. Hopefully we'll be back up and fully functioning the end of this weekend.

I have generated the Web Services client classes using XFire, directly against an WSDL file. I have written Java code that calls the client which returns a complex Object called "SessionResult" (not a simple String for example). However, I couldn't find from the XFire documentation how I can convert this object to "my" Session object. eg ServiceClient client = new ServiceClient(); ServicePortType portType = client.getServiceHttpPort(); SessionResult result = portType.login(userid, password); //Now how do I convert this from a JAXBElement to my "Session" //object JAXBElement j = result.getSession(); regards James jimmyblonde_au at yahoo dot com --