XFire 1.2 Released

Discussions

News: XFire 1.2 Released

  1. XFire 1.2 Released (14 messages)

    The Codehaus XFire team is proud to announce XFire 1.2! 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 plugable bindings for POJOs, JAXB, and XMLBeans. XFire 1.2 incorporates several new features and improvements since 1.1:
    • JiBX databinding support
    • HTTP GZIP Support
    • WSDL2Java now auto generates services.xml
    • Aegis binding inheritance support
    • Option to disable server stub generation

    Threaded Messages (14)

  2. Re: XFire 1.2 Released[ Go to top ]

    How does XFire compare to Axis? I have (unfortunately) only used Axis in the past.. Does XFire allow you to easily work with the pure XML, deciding how, if and when to parse and build it? How does XFire perform? On both these accounts, I have found Axis to quite honestly be... A steaming pile of donkey turd, to put it mildly, especially point 2 compared to pure XML over a Servlet.
  3. Re: XFire 1.2 Released[ Go to top ]

    Here is a short comparison of XFire, Axis and some others frameworks features : http://xfire.codehaus.org/Stack+Comparison XFire is one of the fastest and easiest to use WS framework. You can read some articles here http://xfire.codehaus.org/Articles to see how fast and user friendly it is.
  4. Re: XFire 1.2 Released[ Go to top ]

    In my opinion Axis 1.x is crap. Axis2 is much better than Axis 1.x, but its improvements are because it is now more like XFire. I think XFire is for the most part a better Axis2. All its missing that is really important is SOAP with Attachments. That isn't due until version 2.0.
  5. Re: XFire 1.2 Released[ Go to top ]

    Correction: XFire is asking to merge with Celtix (IONA sponsoered ESB) to create CeltiXfire instead of XFire version 2.0. A lot of changes - mostly improvements - are in store. I hope they hurry because I am about to commit a major project to a web services framework and I'd prefer it be XFire than Axis2.
  6. Re: XFire 1.2 Released[ Go to top ]

    I think XFire is a perfectly good choice until CeltiXfire is ready. As I outlined in my blog (http://netzooid.com/blog/2006/08/29/celtixfire-20-xfire-20-celtix-20/), your service will probably look the same whether or not you use XFire or CeltiXfire. It will really be a matter of configuration. Additionally we'll be supporting XFire 1.x for quite a while. It is very widely deployed and we'll be doing further releases in the future. On a side note: I don't really qualify Celtix as an ESB. It is a JAX-WS implementation with support for WS-* and some integration code for things like CORBA. Whether or not that makes it an ESB, I'll let you decided :-). Dan Diephouse http://envoisolutions.com
  7. Re: XFire 1.2 Released[ Go to top ]

    On a side note: I don't really qualify Celtix as an ESB. It is a JAX-WS implementation with support for WS-* and some integration code for things like CORBA. Whether or not that makes it an ESB, I'll let you decided :-)
    Ha! If the sales- and marketing guys say it's an ESB, then it is! I've seen people claim that an end-user GUI based desktop applications was "SOA" with a straight face, so I'd say the buzzwords are getting pretty pointless at this time..
  8. ESBmongificatorSOAfierFingLonger[ Go to top ]

    I've seen people claim that an end-user GUI based desktop applications was "SOA" with a straight face, so I'd say the buzzwords are getting pretty pointless at this time..
    Wow thats rich. I find buzzwords & features charts a very poor indication of software. Its not checkboxes, its how well each check box is implemented. A really good piece of software that does less out of the box, may help more than a piece of software that claims to do it all. Dan Diephouse Envoi Solutions
  9. Re: XFire 1.2 Released[ Go to top ]

    I can tell you from personal experience (although your mileage will vary) that we have abandoned Axis a long time ago. Why? Well, we were using the Axis integration with Mule (a very good project btw) with both Axis 1 and Axis 2 integration, and after spending/wasting a lot of time (days to be honest) snaking through the type mapping delegation we decided to just try XFire, and were able to get it up/running/integrated within a day. What we had to do with Axis: - read through and trace *ALL* the type mapping delegation code - write custom code to get Castor to bind properly (b/c the default one in Axis doesn't load mapping files, ick) - test, cry, test, weep, test, hit something (inanimate). What we had to do with XFire: - run schema gen - cry with smiles on our faces - test, look at perf, smile, test, jaws dropping from SoapScope positive results, test, perform the Chad Johnson Irish step dancing jig Of course, you should try both yourself, but you will probably find that things are simpler/faster with XFire for those cases that are non trivial, meaning custom schemas, etc. One other big point to note, that it is nearly damn impossible (without taking a *HUGE* performance hit to do schema validation in Axis, whereas in XFire, it is as trivial as a single method call. To be honest, we had huge hopes for Axis, both initially and up to a few months ago. I'm not quite sure where/how things started to fall apart, but it is clear in my view that most will choose XFire when doing an honest and objective comparison. Jin
  10. Re: XFire 1.2 Released[ Go to top ]

    Jin, Have you used SOAP attachments (not SOAP with Attachments) with XFire? If so, since it doesn't support the official "SOAP with Attachments" how did that work out for you in terms of compatibility with non-XFire endpoints?
  11. Re: XFire 1.2 Released[ Go to top ]

    No, we don't have a use case for attachments, we are simply remoting our core trading server over SOAP, using both HTTPS and JMS (SonicMQ). For what we need, it has been quite good. Jin
  12. Attachments[ Go to top ]

    Jin,

    Have you used SOAP attachments (not SOAP with Attachments) with XFire? If so, since it doesn't support the official "SOAP with Attachments" how did that work out for you in terms of compatibility with non-XFire endpoints?
    Just a clarification, we do support MTOM attachments, which are very standard and a much better way to do things than soap with attachments. Basically the difference is that you get a 30% smaller message with MTOM compared to SwA. I have personally used it successfully with .NET quite a bit.
  13. Working with pure XML[ Go to top ]

    Yes, XFire does allow you to work with pure XML quite easily. Simply build a service that receives/sends XML documents: public class MyService { // example using DOM public org.w3c.dom.Document doFoo(org.w3c.dom.Document doc) { // do something with the document } // Example using StAX // You'll want to use the MessageBinding if you use // StAX as its optimized for the completely stream // case. See the User's Guide for more info. public XMLStreamReader doFoo(XMLStreamReader stream) { // do something with the document } // A one way operation using the JSR 181 annotations @OneWay public void receiveOrder(org.w3c.dom.Document doc) { // do something with the document } }
  14. I have been working on axis for a long time. I use JAXM and SAAJ for calling webserives from my client application. Can I call XFire webservice with JAXM (SAAJ)...? What are the advantage and dis-advantages of XFire over Axis.
  15. You should be able to call XFire via JAXM/SAAJ - if you have any issues feel free to post on the users mailing list. As for the differences between XFire and Axis, I would encourage you to read the comments in this thread :-)