Apache CXF 2.0 Released - build services using frontend APIs like JAX-WS

Home

News: Apache CXF 2.0 Released - build services using frontend APIs like JAX-WS

  1. The Apache Incubator CXF team is proud to announce the availability of the 2.0 release! Apache CXF is an open source services framework which is a result of the merge between the XFire and Celtix projects. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. CXF includes a broad feature set, but it is primarily focused on the following areas:
    • Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.
    • Frontends: CXF supports a variety of "frontend" programming models. CXF provides a JAX-WS Compliant frontend. It also includes a "simple frontend" which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.
    • Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.
    • Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.
    This release contains the following features:
    • JAX-WS Compliant frontend - Apache CXF has now passed the standalone JAX-WS TCK.
    • Java2WSDL and WSDL2Java tools and Maven plugin
    • SOAP 1.1 & 1.2, XML and RESTful HTTP bindings
    • JAXB 2.0 Databinding support
    • WSDL 1.1 support
    • WS-Addressing, WS-ReliableMessaging, WS-Security, and WS-Policy support
    • MTOM attachment and SOAP w/ Attachments support
    • HTTP, Servlet, JMS and Local Transports
    • Simple POJO service frontend
    • Javascript frontend
    • JBI Service Engine. CXF services can be deployed into any JBI compliant container (ServiceMix or OpenESB)
    • JCA 1.0 support, J2EE application can integrate with legacy application through JCA 1.0 support in CXF
    • Spring Support
    • JSON support with Jettison
    • Many other bug fixes and feature enhancements
    For more information see the:

    Threaded Messages (21)

  2. is it an ESB?!!![ Go to top ]

    Congratulation ... xfire was a great product and i am using it since its early days without problems,it's easy, fast, solid& feature rich celtix integration is the new thing to me,they promise that it is an ESB so how this feature transfered to CXF,what kind of ESB or ESB feature you implement as ESB is a very loose term this days
  3. They say no.[ Go to top ]

    is it an ESB?!!!
    http://xfire.codehaus.org/XFire+and+Celtix+Merge: "While Celtix has traditionally called itself an ESB, if you look at the code you'll see that Celtix has primarily focused on providing JAX-WS and WS-* support. The new project will NOT be branded as an ESB. It will be primarily focused on service creation and infrastructure. In other words a lot of web services and some support for legacy (i.e. non-XML) integration."
  4. Is it stable now?[ Go to top ]

    I am a user of XFire, but i am not sure if or not i can shift to CXF now!
  5. Re: Is it stable now?[ Go to top ]

    They say it's not "full-fledged" yet (wondering what they actually mean): http://www.apachenews.org/archives/cat_apache_incubator.html I am also curious to know when a stable relase is expected. The project status can be found here: http://incubator.apache.org/cxf/project-status.html
  6. Unique Selling Points[ Go to top ]

    I'm an Axis2 user. Why should I switch to Apache CXF 2.0?
  7. Re: Unique Selling Points[ Go to top ]

    I'm an Axis2 user.

    Why should I switch to Apache CXF 2.0?
    As a CXF author, I'm particularly biased here, and this will probably start a flame war, but you asked for opinions... * CXF is JAX-WS certified - While JAX-WS has some flaws, I think there is a lot to be said for using the standard JAX-WS APIs when possible. They're easy to use, they're well documented (JAX-WS even has a book now somewhere), and they'll be supported well into the future. * Spring 2.0 XML support - It doesn't get much simpler than declaring a in a Spring file. * Support for manipulating non-XML formats inside Interceptors/Handlers. I.e. you can write an interceptor which does GZipping pretty easily. * Annotated RESTful services * Aegis databinding support which transparently handles most datatypes including Maps correctly. (from here on out, this is my subjective opinions, be sure to read the conclusion!) Personally I feel that CXF is simpler as well. Axis2 typically generates (or requires you to generate) a lot of XML descriptors (i.e. services.xml) and java files, which I find a bit confusing. For example, when deploying an Axis2 service inside Spring, you need both write some bean descriptors and also modify/create a services.xml file. In CXF you just need a one line snippet added to your bean definitions: Or possibly: Speaking of containers, CXF takes a different approach here than Axis2. Axis2 is not only trying to help you build services, it is also trying to be an appserver. You can build deployment archives (AARs), deploy them into the container, etc. If you just peruse the documentation, I think it gives off a very appserverish feel. While I realize you can use it in a non-appserverish kind of way, like deploying a POJO via the API, IMO using Axis2 in this way feels more like an afterthought. Axis2 was designed to be an appserver first. My opinion is that we've already got a lot of great containers & appservers out there - Spring, JBoss, ESBs, etc. We want to work with your existing containers to create the best integration possible. Need hot deploy? Then we have a whole host of containers out there which can do that for us, including things like ServiceMix (MULE should support it as well, I just don't know that I've tried it with MULE). CXF is very focused on building clean, extensible, and easy to use APIs to make container/appserver integration easy. Lots of people are doing integration into their own proprietary platforms as they create standardized ways for developers to build services across their organization. I personally think that CXF makes this quite easy to do and quite easy for them to manage their services. YMMV. (BTW, did you see that JBossWS is adding support for pluggable web service frameworks - including CXF? :-)) Ultimately, I don't know that anyone should be comparing frameworks based on features alone. Its not a quantitative issue, its a qualitative one. As such, its quite subjective and I would encourage you to download CXF and try it out. You may just like it :-) I'd be curious to hear more thoughts from those who have actually evaluated both Axis2 and CXF (or XFire). Dan Diephouse (CXF Co-Founder)
  8. Re: Unique Selling Points[ Go to top ]

    I have not used JAX-WS style of web services a whole lot, but what don't understand about JAX-WS address attribute is that if I have to define in spring xml file where the service is being published, then if I have 100 web services, then I have to define 100 such addresses and if some how my server name changes, then I have to go back to xml file and change all those attributes. Also, if I have to switch between development and production servers, then I will have to keep changing all those attributes every time I want deploy my new services. Any advice on this/
  9. Re: Unique Selling Points[ Go to top ]

    I have not used JAX-WS style of web services a whole lot, but what don't understand about JAX-WS address attribute is that if I have to define in spring xml file where the service is being published, then if I have 100 web services, then I have to define 100 such addresses and if some how my server name changes, then I have to go back to xml file and change all those attributes. Also, if I have to switch between development and production servers, then I will have to keep changing all those attributes every time I want deploy my new services. Any advice on this/
    CXF supports using a relative path if you've deployed a servlet. I.e.: Endpoint.publish("/hello", new HelloService()); Hope that helps!
  10. Re: Unique Selling Points[ Go to top ]

    Does CXF support HTTPS like xfire does? the website does not seem to mention it... may be due to lack of documentation. Is this project really production ready?
  11. Here is a simple startup tutorial for exposing a service in both REST and WS-* Styles using CXF. http://soa2world.blogspot.com/2008/05/rest-and-ws-service-same-service-using.html Regards, Siva Prasanna Kumar http://soa2world.blogspot.com
  12. any simple CXF start guide?[ Go to top ]

    Hello! I have been using axis and axis 2 for a while, and now I am wondering to use CXF. There is any simple guide that explains how to deploy a CXF endpoint inside a container. I have tried with netbeans + enterprise pack and all the Java Stuff and everything is a piece of cake (at least the simplest things), while with Eclipse Europa and Apache stuff and just starting is pain! I am restricted to Apache+Ecplise by a Company policy. There is a good guide anywhere about CXF?!!?!? the website is really lacking... thank you!
  13. Re: Unique Selling Points[ Go to top ]

    I'm an Axis2 user.

    Why should I switch to Apache CXF 2.0?
    I pretty much agree with everything Dan D. said. (including being biased considering I'm also a CXF author) The main point I want to expand on is standards support. Both Apache CXF and Apache Axis 2 support many of the "on the wire" standards. Things like SOAP, MTOM, WS-A, WS-RM, WS-Policy, etc... Thus, both projects can provide a toolkit for producing interopable, high performance web services. However, Apache CXF also emphasizes API standards. CXF is JAX-WS compliant and promotes the use of JAX-WS as our primary programming model. We also promote the use of "standard" packaging/deployment models like wars in tomcat or a Spring XML bean file for your Spring application. Finally, Apache CXF is designed to be extensible to other types of interactions. An example of this is the Apache Yoko project. They are producing CXF interceptors and binding that allow CXF JAX-WS applications to talk to CORBA services (and vice versa). Anyway, both toolkits are very good and provide very similar "feature sets". All I can say is download both and give them a try. I personally think CXF is easier to use and since it's based on a standard programming model, the skills needed to use it are transferable to other areas. (Example: new J2EE app servers are required to support JAX-WS. JAX-WS is built into Java 6. Etc..) Dan Kulp
  14. Re: Unique Selling Points[ Go to top ]

    Anyway, both toolkits are very good and provide very similar "feature sets". All I can say is download both and give them a try. I personally think CXF is easier to use and since it's based on a standard programming model, the skills needed to use it are transferable to other areas.
    I will check it in the next project. But anyway I hope, that I don't have to do this web service stuff again... ;-)
  15. CFX vs. Metro[ Go to top ]

    I'm quite new to web services, and I'm currently considering CFX and Metro. I would be pleased to see anyone outline the main advantages by choosing CFX. I've read the features list, but I'm seeking your more opinions on this. Thanks.
  16. What are CXF's Advantages over .NET WCF ?? :-)
  17. What are CXF's Advantages over .NET WCF ??
    :-)
    Umm, its Java based? If you're using .NET, use WCF. Its not half bad. If you're using Java, use CXF. There are of course a load of other differences in the approach each one takes, but I don't think I have the where-with-all today to jump into that. Maybe in the future I'll write a blog entry on it.
  18. Apache CXF vs SCA[ Go to top ]

    I wonder what CXF offer differently from SCA.
  19. What are the improvements?[ Go to top ]

    I want to know are there any killer level improvements in CXF that compare with XFire? What is the fatal drawback in XFire?
  20. Re: What are the improvements?[ Go to top ]

    I want to know are there any killer level improvements in CXF that compare with XFire?
    Soooo many to mention: * Rest support * JAX-WS compliant * Improved tooling * Better APIs and extension points * Better transports - JMS support is actually decent now * Support for non-XML data, i.e. JSON * Better Spring support/integration * Bundled Maven plugins * WS-Policy, WS-Security, WS-Addressing, WS-ReliableMessaging etc, etc, etc I would also like to add that those who have written XFire services should be able to deploy them in CXF. The code you use to do this may have to change somewhat - i.e. use ReflectionServiceFactoryBean instead of ObjectServiceFactory, but API improvements come with any major release. The nice part is that the actual service should not have to change. If it does, its a bug and we'll fix it.
  21. Re: What are the improvements?[ Go to top ]

    Would it be unreasonable to suggest that CXF is a superset of XFire and that whatever XFire users were already getting from XFire they would get the same plus MORE? In that sense it makes moving to CXF from XFire a relatively comfortable hop; keeping in mind that there'll be some changes to cope with.
  22. Re: What are the improvements?[ Go to top ]

    Would it be unreasonable to suggest that CXF is a superset of XFire and that whatever XFire users were already getting from XFire they would get the same plus MORE? In that sense it makes moving to CXF from XFire a relatively comfortable hop; keeping in mind that there'll be some changes to cope with.
    Yes, with a couple minor caveats. The biggest would be that CXF is Java5 only. Also, the XMLBeans/Castor support will be ported in a future release.