Three years ago, Dan Diephouse founded the XFire project to provide an alternative to Apache Axis. In the subsequent years, XFire has matured into an easy-to-use, high-performance SOAP stack with first-class support for the Spring Framework: once the challenging newcomer, now the new standard for deploying web services on the Java platform. I recently had a chance to sit down with both Dan Diephouse and Paul Brown of Envoi Solutions to discuss the merger of XFire and IONA’s Celtix project into a new project, Apache CXF, currently under incubation at the Apache Software Foundation.

In the following interview, I ask both Dan and Paul about CXF. What differentiates CXF from projects like Apache Axis? How has XFire been affected by the Apache Incubator? And, some questions about corporate support of open source projects?

Read on for the full interview with Dan Diephouse and Paul Brown.

The Interview

Apache CXF

Q: What is CXF?

Diephouse: CXF is the newer shinier version of XFire; it is version 2.0. CXF is the combination of the Celtix and XFire communities coming together at Apache. We’re working on building a fully featured easy to use web services framework. Support for SOAP, WS-*, RESTful standards, different data formats like XML and JSON, also CORBA for people that enjoy that.

Q: XFire and Celtix are heading toward a release. What are you doing to maintain backwards compatibility for people who are currently using Xfire 1?

Diephouse: All your XFire services will be deployable inside CXF. The code to deploy those will change a little . It’s like any 2.0 we have improved the API, improved the XML dsescriptors, but your services will still work straight from one to the other. We have a migration guide that we’ve worked on to show you the equivalent lines of code. So, instead of these three lines of code, you have these three lines of code. For most people it should be pretty simple and doable in an hour or two.

Q: Why would I use XFire instead of Axis 2?

Brown:I think that if you took most modern SOAP frameworks and compared them side-by-side and compared features, a lot of frameworks check the same boxes (and, frankly, people check the same boxes using the same components). WS-Security components in common, WS-Policy components in common. I think it comes down to the mode in which you want to interact with a piece of software. Your relationship with the community. People will find things about Axis they like and they will want to use Axis, they will find things about CXF that make them want to use CXF.

Diephouse: I’ll echo what Paul says and say its not so much about the quantity of features, it really comes down a developer’s interaction with the community and code. My personal view is that in CXF there is a big focus on, as Paul calls it, developer ergonomics. The API is pretty friendly. You can reconfigure CXF easiliy without mucking with XML. The APIs and Spring configuration mirror each other quite nicely, making it easier for individuals to understand. We’re also Java 5 based, which can make for a much friendlier experience.

Diephouse: A big difference between CXF and Axis2 is that CXF has much deeper Spring integration including support for Spring 2.0 XML syntax. In the Axis2 demos I’ve seen you still need something like an axis2.xml file which is quite awkward. Unlike Axis2, CXF doesn’t try to be an app server, it lets Spring, JBoss, etc do that work when users need it.

Diephouse: We also have support for our a databinding layer we wrote called Aegis. It makes codefirst services incredibly easy. Unlike JAXB, you don’t need annotations at all. It also works correctly with things like Lists, Maps, etc out of the box. If you’re building a prototype webservice thats really invaluable (and one of the primary reasons I started XFire a while back)

Diephouse: One of the interesting things we’ve enabled is the development of RESTful services via an annotation model. Using URI templates and annotations I can bind a service operation to arbitrary URL/verb combinations. For instance, I can annotate a getCustom method with @Get @HttpResource(”/customers/{id}”). CXF will then listen for GET requests on that URL and using the parameter at the {id} location as a parameter to the service.

Diephouse: There are also a host of smaller things. For instance, we have a “co-location” feature which can auto-detect if the server endpoint for your client endpoint is running in the local process space and if so, it will bypass serialization.

Q: In that list of differentiators, you mentioned support for the Spring Framework. Is Spring Framework support a priority?

Diephouse: Spring support is very much a priority. We have support for Spring through and through, and the default mode of operation actually includes a Spring container We support the Spring 2.0 syntax, and it is easy to declare beans or services inside Spring. It is very easy to use WS-Policy inside Spring.

WS-Policy and WS-Security

Q: Your literature mentions support for WS-Policy. Tell me a little bit more about WS-Policy? What is it? How is it relevant to developers?

Brown: WS-Policy is like the web services version of what happens with HTTPS. There is some autonegotiation, it is part of the protocol, it allows the two ends to talk to each other in a format that they understand.

Q: What are the specific use cases for WS-Security?

Diephouse: You want to secure your service and you want to say I can either use SSL and HTTP or somebody can send a non-SSL WS-Security encrypted message. So policy allows you to express that one of those requirements must be met or you can not use the service.

Brown: It’s a constraint statement for, if you, The Client, wants to talk to me, Mr. Service, than you must comply with this policy and the policy is documented in the WS-Policy protocol.

Q: So, if I’m using JSR-181 annotations with XFire, how would I use WS-Policy with XFire?

Brown: You would have to write policy assertions, so these assertions communicate the abilities of your service and the requirements of your service to WS-Security. So you need to write a little mini policy document.

Q: How do you currently configure WS-Security?

Brown: You need to understand how CXF configuration works.

Diephouse: The great thing about CXF is that you have a collection of features. When I declare a JAX-WS endpoint I can also declare various features. One of the features could be an addressing feature. So inside the CXF configuration XML you have a <features> element in the <features> element you just type an <addressing> element, and then addressing is going to be enabled.

Then we also have things for policy so I can add WS-Policy and then put my policy expressions in-line and then all of these will be asserted on your service. If we have a reliable messaing policy expression, if someone is trying to use your service who is not using ReliableMessaging . We’re going to throw an error to that person that says you aren’t using ReliableMessaging, fix that before you talk to us again.

Q: What application servers do you deploy applications that use CXF on? Does it make any difference?

Diephouse: It doesn’t make a huge amount of difference. Standalone, you can deploy in JBoss and Geronimo; pretty much any application server. You might have some security integration that you want to use with your server. You might want to use your container’s authentication facility. You might want to use your application server to deploy and manage CXF. From that point of view it’s not so much CXF using your application as your application server being able to use CXF effectively.

Q: Let’s say I create a SOAP endpoint in XFire, but I really want to get access to the low-level connection to provide security outside of the WS-* standards. What’s the best way to do that with XFire? Create a Servlet Filter?

Diephouse: That would be one way to do it, but XFire also provides extension points. And, these are called interceptors. Similar to the concept of handlers. You can write custom logic to pull out things like the connection info or security information like the SSL certificates so you can verify all of those things.

Apache CXF Project, Building with Apache Maven

Q: As CXF’s feature-set grows, how do you intend to avoid scope creep? How do you avoid becoming an umbrella project?

Diephouse: We’ve tried to address that by creating a very simple API that is easy to use and understandable for the average developer. You start off with a small subset of features, and you only use the other pieces if you are doing something advanced. Even in those advanced use cases we try to really encapsulate everything to make it as simple as possible. We also address it by not creating separate subprojects for things like Addressing and ReliableMessaging. WS-Addressing and WS-ReliableMessaging Security, all these things are bundled inside the CXF distribution. So you don’t have to do anything extra, you just have to flip on the WS-Addressing or flip on the ReliableMessaging in configuration. And, you know, There are no separate projects named it just WS-addressing inside of CXF.

There is a single JIRA project, and a single mailing list. Everything is bundled and tested together, so we know everything works when we do a release.

Q: Speaking of builds, XFire (CXF) uses Maven which is either a blessing or a curse depending on who you ask. Are you satisfied with Maven as a build technology?

Diephouse: Actually, yes. Dan Kulp is focused on our build process and he’s an awesome build engineer. When you know what you are doing you learn to love Maven because you can do things like Maven release:prepare. That’s going tbuild the whole release for you, from start to finish. Maven release:perform is going to publish everything for us, take care of all the little details which we might not have thought of otherwise.

Diephouse: It really paid off for us especially because it handled a lot of the licensing issues. It automatically generates notice files for us, which we need to be Apache compliant. Maven allows us to automate everything and focus on coding Apache CXF.

Apache CXF in the Apache Incubator

Q: You are in the ASF Incubator now? How’s that going? Is there any overhead that you didn’t expect?

Diephouse: Yes, we are in the Incubator. It’s going alright. I expected some overhead. So, I’m not that surprised. We had a few rough starts at the beginning, but things are smooth sailing our mentors have helped us a lot.

Q: Dan, why did you start XFire in the Codehaus community?

Diephouse: Codehaus is a great place to start a community because it is easy to get setup there are a lot of great people there. Some awesome infrastructure. And, I believe in what they are doing. In just enabling open source projects to gain a larger community.

Q: Why did you leave it?

Brown: There are certainly companies that have commercial projects hosted there. For the comfort of the other collaborators on CXF having the Apache brand and that official business-recognized community stamp on the project was something that was desirable.

Q: So you wanted the legal protection?

Diephouse: Definitely the legal protection was a part of it. Access to the TCKs, which Apache has. The community here which we’ve already been pretty integrated with.

Q: Who are you mentors?

Diephouse: We have several mentors Jim Jagielski is one of them. James Strachan is one of them. Peter Royal is one.

Q: When are you graduating from the Incubator? Have you already graduated?

Diephouse: We have not already graduated, we are in the midst of finalizing our 2.0 release. And, hopefully that’s going to attract a few more committers from the outside, and so we’re going to push graduation hard after we get this release out.

Q: Has the Apache Incubator been a net positive for XFire/CXF?

Diephouse: Yeah, I would say so. Some overhead.

Q: Has it delayed releases?

Diephouse: It has delayed releases because Apache’s pretty finicky about how things come together. But, overall it hasn’t been that much overhead except when we’re trying to do releases.

Brown:I really don’t think you should look at things at Apache as overhead. There are aspects of a project that are a part of the Apache brand. It’s a very strong thing, and it’s no different from somebody saying here’s how you use our logo. With Apache, it’s here’s how you distribute the software, here’s how you build the community.

Q: Apache has strict rules to try to prevent any one company from dominating a specific project. Does Envoi Solutions control the XFire project? Are you trying to attract others to the community?

Diephouse: Well we’ve been working really hard to get our releases out so we can bring in other people to our project. Definitely IONA has a big presence on this project. But, we’ve started adding a lot of individual committers and committers from other companies.

Paul Brown: Previous Work with BPEL, Work with Apache ODE

Q: Paul, are you still working on BPEL?

Brown: Sure I’m a lazy committer on Apache ODE in that I haven’t committed much in a while. ODE is approaching its 1.0 release, we just had a third release candidate. There was a lot of work done there in the Incubator to comply with Apache because there were some LGPL dependencies. And, then the work that was done to put PXE from Intalio together with BPE from Sybase involved taking a lot of things out and then integrating with Axis 2 and with ServiceMix.

Q: ServiceMix is an alternative to MULE?

Brown: ServiceMix is a JBI implementation with some additional features, meaning that ServiceMix is primarily concerned with moving XML messages around, while Mule takes a more agnostic approach to payloads.

Q: Paul, your previous venture FiveSight was focused on orchestration and BPEL. How can you make BPEL easier to learn, more accessible, etc.? Does it lend itself to the 10 minute introduction?

Brown: I’m writing-up a “dip your toes in Ode” article, so that’s one place to start. Realistically, BPEL will be something that’s under the covers for a lot of people. Users will interact with BPEL through a piece of higher-level tooling, by which I mean BPMN and its cousins as opposed to a direct graphical representation of BPEL. On the plus side, after four years at OASIS (270 page spec, no detail left uncovered within reason), BPEL is baked to the point where there is both the hope and expectation of interoperability between tools and implementations.

Q: Is SOAP relevant?

Brown: It’s not about how SOAP isn’t relevant. If you sit down from first principles to do your personal discovery as a developer with SOAP, you have to read some specs, you have to write XML documents, you have to post them to a location to a URL you have to think carefully about namespaces and different pieces, and frankly that’s why things like CXF exist. It makes a lot of sense for doing these kinds of things. But, those bits of complexity and opacity give people a hard time because it’s not something you can just sit down and stick your fingers in. On the other hand, I think that that level of accessibility is something that is addressed by CXF both because you have a very fine grained configuration model and because you have other ways to get to the internals and externals of your endpoints.

Envoi Solutions: Supporting Apache CXF

Q: Why are you at JavaOne 2007?

Brown: To start trying to make a connection between the business entity and a project. We do offer services, we do offer support, we offer training, and people have very little association between Envoi Solutions and XFire. They walk by they look at Envoi Solutions they keep going and then they see XFire. And, they want to stop and chat.

Brown: When you are an open source project you know you do a good job providing documentation and in making things easy to use. But, you don’t get to touch your customer. People come up, they grab the chotchky, the run off. And, it’s a bit nice, you know people come and say, “Yeah, Hi. We’re using XFire” and you would have no idea otherwise. And, from what we’ve heard, they are happy with the software.

Brown: And, it is also a nice time to say well what would you like to be different, would you like added um are there any issues that you’ve had.

Q: Feedback and connecting with the customer wouldn’t happen if you weren’t here?

Brown: Right there’s a level of it that doesn’t happen on the developer mailing lists. Or, other places, unless your catching them out of the flow of their day to day work they are not going to stop and submit requests for enhancement or tell you what they liked best or what they found a little difficult.

Q: Have you been getting leads?

Brown: Yeah, it’s nice. Nobody’s thrown rocks or fruit or eggs at us. Everybody’s been pretty happy. One guy had a little trouble signing the jars for his WebStart application

Q: Nobody hates XFire?

Brown: As far as we can tell, no one hates XFire.

CXF Resources

People, Organizations Mentioned in this Article