cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Axis2 vs CXF
Date Sat, 07 Jul 2007 19:14:21 GMT
I just posted this to TSS as well, but I thought people might want to read
it here too:

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
<jaxws:endpoint .../> 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.<http://netzooid.com/blog/2007/07/01/working-with-non-xml-formats-in-cxf-interceptors/>
* Annotated RESTful
services<http://cwiki.apache.org/CXF20DOC/restful-services.html>
* 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.<http://ws.apache.org/axis2/1_2/spring.html>In CXF you just need
a one line snippet added to your bean definitions:

<jaxws:endpoint id="foo" implementor="FooServiceImpl" address="
http://localhost:8080/foo"/>

Or possibly:

<jaxws:endpoint id="foo" implementor="#fooBean" address="
http://localhost:8080/foo"/>

<bean id="fooBean" class="FooServiceImpl"/>

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<http://netzooid.com/blog/2007/07/02/jbossws-supports-cxf-as-a-pluggable-ws-framework/>?
:-))

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 :-)

Regards,
- Dan

On 7/5/07, Arkady Kasianski <ArikKA@amdocs.com> wrote:
>
> Hi everybody,
>
>
>
> I have to choose between Axis 2 and CXF ....
>
>
>
> Could someone compare  between both WS frameworks ?
>
>
>
> Thanks in advance
>
>
>
> -Arkady
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message