I note (from the contents page) that Chapter 5 of your book covers JAXB 2.0. I used a previous incarnation of JAXB some time (around 4-5 years) ago when creating a remote service manually and found it to be very useful. More recently I have been involved with a contract-first (from WSDL) Web Service currently implemented using Axis2. As I'm sure you know Axis2 provides it's own, slightly limited, data binding framework (ADB) and integration to some degree with JibX and XMLBeans. I believe that the intention is to include better integration with JAXB in a future release.
My question is really what you think about the alternative forms of data binding (particularly ADB and XMLBeans) in comparison with JAXB with regard to ease of development, maintenance, and performance.
Additionally, what are your views on implementing services on frameworks such as Axis2 and XFire in practise? Are the benefits worth the restrictions.
Data binding is really the most critical issue when it comes to Java Web Services. You've got 3 primary issues: performance, ease of development , and flexibility (which you mentioned as "maintenance").
I have not used ADB, but my understanding is that its primary design goal is performance.
I think that JAXB and XMLBeans are roughly equivalent, but the current implementation of JAXB 2.0/2.1 (Sun's RI) is said to be faster.
JAXB 1.0 was inferior to XMLBeans because it forced you to work with interfaces. So, I started working with XMLBeans and came to really like its flexibility and speed of development. However, when JAXB 2.0 came out, I switched back. It is almost as flexible and intuitive as XMLBeans, and its a standard.
Because JAXB 2.0 is part of the Java specification, it is almost as easy to work with, and it has better performance than XMLBeans, I think that it is the best choice.
My book and this blog post describe how to use JAX-WS with other data bindings. In the case of my blog post - its Castor.
Got to run - write me back if you want more details.
The blog post you linked was interesting. The reasons for avoiding JAXB might, then, be either to avoid changing existing code or to continue using a familiar binding framework. The first of these doesn't apply to me since I've chosen to implement an Adapter to translate between my business level components (most of which are used in other applications) and my service operation class (I want as little coupling between my chosen Web Service implementation and business logic as I can get away with). The second of those reasons is closer to my situation but not quite the same motivation. My motivation is the choice of binding framework on the basis of it working as easily, and as effectively, as possible with Axis2 (my current requirements allow me to use ADB).
Do you think that the wish to use Axis2 is a sufficient reason to avoid JAXB, or is this restriction imposed by the use of Axis2 (in it's current implementation) not a reasonable compromise in your opinion? Would the wish to use JAXB prompt you to find an alternative to Axis2 in this case?
My current feeling is that the most pragmatic approach is for me to stick with Axis2 and ADB for now, and migrate to JAXB if a compelling reason appears later on and Axis2 has more evolved support for JAXB. A potential pitfall here is the possibility of that compelling reason emerging before Axis2 works well with JAXB, but I figure that's a bridge I may never need to cross. My experience in this area is fairly limited so I'd appreciate your views on the use of frameworks such as Axis2, XFire, or others?
I know you must be very busy and this is perhaps getting a little lengthy, but any overview comments from your experience would be much appreciated.
If you want to work on the Axis2 platform, then I see no problem sticking with ADB.
I've ported code from one binding framework to another (mostly XMLBeans to JAXB), and its tedious, but not terribly difficult. I have not worked with ADB, but I cannot imagine that its too difficult to port to JAXB. But, if you really want an informed opinion, you should post the question on the Axis2 mailing list.
BTW, Axis2 is designed to plug-in different data bindings. I am sure that if you had the time, you could get a few people from the Axis2 mailing list to work with you on a JAXB implementation for Axis2. The Sun JAXB 2.0/2.1 implementation is open source and I believe the license is compatible with Apache, so it could probably be used as a starting point. But, again, that is a good question for the Axis mailing list. I know that Dennis Sosnoski (the author of JiBX) wrote his plugin for Axis2 and I don't think it was a huge undertaking.
Unfortunately, I do not have a tremendous amount of experience with Axis2 or XFire. However, I can tell you that the people working on XFire (Dan Diephouse in particular) are highly regarded and I've heard very good things about it. Many people like using XFire with Spring. FYI, XFire has merged with Apache Celtix. Celtix has been supported by IONA - a firm with a rich history of distributed computing programming prowess. The merged project is Apache CXF. I'm excited about it and can't wait to have some time to start working with it.
Of course, Axis2 has its own pedigree Much of the development is now handled by WSO2 - a firm founded by Sanjiva Weerawarana, one of the authors of the original WSDL specification.
There is a lot of good innovation going on in the SOA-stack space. My book focuses on the mainstream Java technologies (JAX-WS, JAXB, and JSR-181) because those topics have the most relevance to the largest audience. But, by no means is that the only way to go.
If you like Axis2 and it works for you, I'd say stick with it. But, keep an eye on what is going on with the mainstream Java stack and also with XFire/Spring and CXF.
Many thanks for your comments. That's a very helpful overview for me. I'm using Spring, which is providing many benefits, and will definitely keep an eye on the Apache CXF project (I have read good things about XFire).