Originally posted by ambar patil:
But should I use XFire or CFX ?
From the
XFire site:
XFire is now CXF
User's looking to use XFire on a new project, should use CXF instead. CXF is a continuation of the XFire project and is considered XFire 2.0. It has many new features, a ton of bug fixes, and is now JAX-WS compliant! XFire will continue to be maintained through bug fix releases, but most development will occur on CXF now. For more information see the XFire/Celtix merge FAQ and the CXF website.
From
CXF, Spring, and WS-Policy Internals
In CXF we've taken the philosophy that we want to leverage the containers and appservers that are out there. Our primary container that we support is Spring
From
Axis, Axis2, CXF: Surveying the WS Landscape:
CXF concentrates on developer ergonomics and embeddability. Most configuration is done via the API instead of cumbersome XML files, Spring integration is heavily emphasized, including support for Spring 2.0, and CXF's APIs and Spring configuration mirror one another fairly closely. CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier (and its embeddability helps too).
However this part of CXF should be cause for serious concern:
CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier.
Now "code first design" is of little consequence when you are simply consuming web services, i.e. you are acting as a web service client.
However if you ever are going to
provide a web service then
you should strongly favor the
contract first approach.
"Code first" is usually supported because developers like it. Developers like it because they can "build a web service" without having to invest too heavily into learning about web services and it lets them stay inside the comfort zone of their implementation language. However this approach tends to lead to web service interfaces that are polluted by concepts from the implementation language. This "pollution" creates the risk that at best the web service isn't as easy to use from clients that may be using a different web services stack and/or implementation language, at worse limit its interoperability. For example, even though XML Schema officially supports "inheritance" some experts recommend that it
should not be used in a web services contract as there is no guarantee that the client implementation can adequately support the concept. Then of course there is the entire matter of the
object-hierarchical impedance mismatch (pdf).
[ February 06, 2008: Message edited by: Peer Reynders ]