Completed Functionality and CXF analogues

XFire Feature	CXF Analogue
Aegis Binding	Ported.
Configurable Servlet	See the Servlet Transport page.
Eclipse Plugin	Eclipse tooling supported via the SOA Tools project.
HTTP Transport	Ported.
JMS Transport	Ported.
JAX-WS/JSR-181 Annotation Support	Ported and CXF passes the JAX-WS/JWS TCKs.
JAXB	Ported.
MTOM	Ported - Supports fully streaming attachments now.
services.xml	Spring 2 XML will be supported for easy configuration. See the Configuration section.
Spring: XFireClientFactoryBean	See the ClientProxyFactoryBean and JaxWsProxyFactoryBean.
Spring: XFireExporter	Not ported as the *ServerFactoryBeans already enable this functionality. See below.
Spring: ServiceBean	Completed. See ServerFactoryBean and JaxWsServerFactoryBean.
WS-Addressing	CXF has much better WS-Addressing support and its easier to use as well.
WS-Security	Ported.
XMLBeans	Not ported. Will be supported in CXF 2.1

For more details on how to migrate:

• Are you using the ObjectServiceFactory, AnnotationServiceFactory, or JAXWSServiceFactory? Go->
• Are you using services.xml? Go->
• Are you using the XFireServlet? Go->
• Are you using the Spring ServiceBean? Go->
• Are you using the Spring XFireExporter? Go->

Should I Migrate Yet?

XFire users should consider migrating to CXF. Anyone looking to start a new web services project should seriously consider CXF. The main barrier is liable to be documentation at this moment. We will be adding LOTS more documentation though over the next couple weeks as we move toward the 2.0 final release.

CXF includes many new features for XFire users:

• Improved WSDL support
• Improved JAX-WS support
• Improved JMS transport
• Maven plugins
• Spring 2.0 syntax support
• Improved WS-* support
• Cleaned up APIs for building services
• Easier to use extension points
• RESTful services support
• Support for a "bare" XML binding, which doesn't include a SOAP envelope

Who should not migrate

There a couple small areas where we haven't replicated all of the XFire functionality yet. Namely the JiBX and XMLBeans databindings. These will be ported for CXF 2.1. The only other reason not to migrate to CXF that we see is a requirement for Java 1.4. Although, we would encourage users to take a look at using CXF on Java 1.4 via Retrotranslator (but be sure to read this thread first).

Service Factories

XFire included serveral service factories for building services. CXF also includes service factories, but the concept has been improved somewhat to make them easier to use. CXF now includes the concept of ServerFactoryBeans which produce Servers, ClientFactoryBeans which produce Clients, and ClientProxyFactoryBeans which produce Client proxies.

CXF now includes the following classes:

• ServerFactoryBean - This creates a server endpoint from a class
• ClientProxyFactoryBean - this creates a client proxy from a class
• JaxWsServerFactoryBean - This creates a JAX-WS server endpoint from a class or WSDL
• JaxWsProxyFactoryBean - this creates a JAX-WS client proxy from a class

Its important to keep in mind a few differences in how CXF works compared to XFire:

• CXF uses a bean factory approach. This means that there is one (Server/ClientProxy)FactoryBean per endpoint. In XFire these beans could be reused.
• CXF requires that you specify the endpoint address, unless it finds it in your WSDL. If you're using HTTP this has some nice benefits.
  • If you haven't set up the Servlet transport, it will automatically start an embedded Jetty instance for you. In XFire this required you to use the XFireHttpServer class, resulting in additional work.
  • This allows you to map services to different URLs easier. In XFire the way URLs were mapped to Services was much more static.
• When you specify an endpoint address for your service, it's important to remember that when you're using the sServlet you don't need to specify the host name. Lets say you set up the CXFServlet to listen on "http://localhost/services". If you specify your endpoint address as "/myservice" then all requests that come to "http://localhost/services/myservice" will go to your service.
• JAXB is now the default databinding. Any time you want to use Aegis, you must explicitly say so.

Example ObjectServiceFactory Migration

ObjectServiceFactory osf = new ObjectServiceFactory();
Service service = osf.create(MyServiceInterface.class);
service.setInvoker(new BeanInvoker(new MyServiceImpl());

ServerFactoryBean sf = new ServerFactoryBean();
sf.getServiceFactory().setDataBinding(new AegisDatabinding();
sf.setServiceBean(new MyServiceImpl());
sf.setServiceClass(MyServiceInterface.class);
sf.setAddress("http://localhost:8080/myservice");
sf.create();

Example AnnotationServiceFactory Migration

AnnotationServiceFactory osf = new AnnotationServiceFactory();
Service service = osf.create(MyServiceInterface.class);
service.setInvoker(new BeanInvoker(new MyServiceImpl());

JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean ();
sf.getServiceFactory().setDataBinding(new AegisDatabinding());
sf.setServiceClass(MyServiceImpl.class);
sf.setAddress("http://localhost:8080/myservice");
sf.create();

Example JAXWSServiceFactory Migration

JAXWSServiceFactory sf = new JAXWSServiceFactory();
Service service = sf.create(MyServiceImpl.class);
service.setInvoker(new BeanInvoker(new MyServiceImpl());

JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setServiceClass(MyServiceImpl.class);
sf.setAddress("http://localhost:8080/myservice");
sf.create();

HTTP and Servlet Setup

CXF supports a much wider range of options for deploying your service over HTTP. XFire created a static mapping between the HTTP URL and the service name - i.e. a service named "HelloService" was accessible at http://localhost/services/HelloService. CXF on the other hand allows you to control the URL which your service is published on. This address is provided to CXF either through the setAddress() call on the ServerFactoryBeans or via your XML configuration.

Another improvement over XFire is that CXF will now transparently detect whether the CXFServlet is being used. If it is, your service will be available on that location. If it is not, CXF will automatically start an embedded Jetty instance (provided the cxf-rt-transports-http-jetty module is on your classpath). No more calls to XFireHttpServer are needed!

To set up the CXF servlet, please read the how-to on the Servlet Transport page.

To use the embedded Jetty instance, no extra work is needed. Simply follow the above ServiceFactory examples.

services.xml

XFire included support for deploying your services via a services.xml file. In CXF this file is named cxf.xml and will be loaded by the CXFServlet

<beans xmlns="http://xfire.codehaus.org/config/1.0">

<service xmlns:t="urn:my:namespace">
	<name>testservice</name>
	<serviceClass>org.example.TestService
	</serviceClass>
	<implementationClass>org.codehaus.xfire.spring.TestServiceImpl</implementationClass>
	<namespace>urn:my:namespace</namespace>
	<serviceFactory>org.codehaus.xfire.jaxws.JAXWSServiceFactory</serviceFactory>

	<properties>
		<property key="myKey">value</property>
        </properties>

	<inHandlers>
		<handler handlerClass="org.codehaus.xfire.spring.TestHandler"/>
	</inHandlers>
</service>

</beans>

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:jaxws="http://cxf.apache.org/jaxws"
      xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd">
 <import resource="classpath:META-INF/cxf/cxf.xml" />
 <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
 <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

  <jaxws:endpoint address="http://localhost/testService"
    serviceName="t:testService"
    xmlns:t="urn:my:namespace">
    <jaxws:implementor>
      <bean class="org.example.TestServiceImpl"/>
    </jaxws:implementor>
    <jaxws:properties>
      <entry key="foo" value="bar"/>
    </jaxws:properties>
    <jaxws:inInterceptors>
      <bean class="org.example.ExampleInterceptor"/>
    </jaxws:inInterceptors>
  </jaxws:endpoint>

</beans>

There are a few important things to note here on the differences:

• Many of these attributes are optional, such as the service name
• You don't need to specify a serviceClass if you are using JAX-WS as your service should be annotated with the @WebService.endpointInterface attribute.
• The equivalent of XFire Handlers is Interceptors inside CXF. They feature a much improved API!

The above sample is for JAX-WS/JSR181 services. For those developing services without annotations, here's an example for the Simple Frontend"

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:simple="http://cxf.apache.org/simple"
      xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/simple
http://cxf.apache.org/schemas/simple.xsd">

  <simple:server address="http://localhost/testService"
    serviceClass="org.example.TestService">
    <simple:serviceBean>
      <bean class="org.example.TestServiceImpl"/>
    </simple:serviceBean>
    <simple:properties>
      <entry key="foo" value="bar"/>
    </jaxws:properties>
    <simple:inInterceptors>
      <bean class="org.example.ExampleInterceptor"/>
    </simple:inInterceptors>
  </simple:server>

</beans>