Codehaus XFire
DocumentationQuicklinksDevelopers
Sponsors |
On June 20, the XFire and Celtix communties submitted a proposal to the Apache Software Foundation for a new project called CeltiXfire. CeltiXfire is a proposed merge of the XFire and Celtix communities and code. On July 22, the proposal was accepted. We, the XFire team, are very excited about this. As we started to think about XFire 2.0 there are a lot of things we want to do. Things like full support for JAX-WS and support for other web service specifications, like WS-RM. We'd also like to improve on a lot of features that we already have, like our JMS support. Both the Celtix code and team are strong in many of these areas. After talking to them, it was clear that both project's goals lined up quite nicely. Additionally both projects were looking to start on their next version, so the timing was just right to start working together. After much discussion, we decided a merge would benefit both projects and their communities. As an XFire user, we understand that you may be concerned about the merge. It is helpful to think of the merge like XFire 2.0. While the APIs will change a bit as we improve on them, the same ideas and features will in the merged code. The major difference between doing 2.0 on our own and merging is that there will be more developers, more support, and more features than the XFire community could do on its own. We also want you to know that XFire 1.x will be supported long into the future. For instance, we have a new feature release coming out soon - 1.2 - which adds support for things like Aegis inheritance, GZIP, and JMS topics. And most importantly, we will continue to make bug fix release as often and as long as needed. We are still waiting for our proposal to be officially accepted, and once we do we will have Apache mailing lists set up for discussion and questions. In the mean time if you have questions or concerns, please email the XFire mailing lists. FAQWhat are the goals of the merge?Some of the goals we have highlighted are:
What are the non goals of the merge?
What is Celtix?Celtix is a web service framework with support for legacy integration. It primarily focuses on providing JAX-WS and WS-* support. This makes it an ideal candidate for merging with XFire as those are two areas where XFire is weak. It also has support for CORBA services via Apache (incubating) Yoko. Is Celtix an ESB?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. Whats going to happen to XFire 1.x and applications which use it?XFire 1.x will be supported long into the future. For instance, we have a new feature release coming out soon - 1.2 - which adds support for things like Aegis inheritance, GZIP, and JMS topics. And most importantly, we will continue to make bug fix release as often and as long as needed. We are currently planning to add a compatability layer for XFire 1.x users in CeltiXfire. Most importantly, the Aegis binding and the Handler interface should both be able to be supported in the new version. Other APIs will chance (as in any 2.0), but there wil be a straightforward migration path. What will the merge look like?After spending some time looking at both Celtix and XFire it was clear that neither one was 100% suitable to just start merging in code from the other project. After some delibiration, we've decided to write a small core and merge bits from each project on top of that. The analagous portion of code in XFire would be the XFire Core module. The idea is to take XFire's architectual ideas - Handlers, the service model, ServiceFactorys, etc - and tweak them to meet a larger set of requirements. One thing we're looking to do is create cleaner separation of bindings and transports. In XFire the two run together. We want to support more bindings than just SOAP - like REST or Plain Ol' XML and this is a necessary step in doing so. Other important departures will be a better databinding API and better support for WS-ReliableMessaging semantics. On top of this new core we are looking to merge in modules from each project. These include (but are not limited to):
The other major change for XFire users is that the API will be Java 5 based. For users wishing to run on Java 1.4, retrotranslator is available as a solution. Note that we've outlined this plan before the merge officially starts. Once the Apache mailing lists are set up there will be a chance for discussion and voting on particular issues that people feel are controversial. What is the timeline?While we are not ready to announce an official timeline, it is clear that many people will be working on the merge from both XFire and Celtix. Once we solidify the core APIs, releases should proceed very quickly. Who works on Celtix?Celtix is funded by IONA Technologies. The project has around 15 committers, with many of them working full time on the project. How do I get involved in the merge?We will have Apache mailing lists set up soon. We would love for you to join in in the new project once they are set up! Check this space in the future for more information. I'm concerned about X! Where can I get further information?We are currently waiting for the Apache mailing lists to be set up. In the mean time if you have questions, please email the XFire mailing lists. |