Michael Poulin wrote:
> Actually, I do not catch the point "but if you're using essentially
> all the document data in your processing, this approach is going to be
> both very slow and very awkward for developers who are coming at the
> problem from a programming language background" because XMLBeans do
> not transform the whole doc but only the part you work with at the
> time, they use lazy-transformation, this is why they fast.
The lazy transformation approach gives great performance if you only
need to apply it to small portions of the document, but if you end up
applying it to most of the document it involves a lot more overhead than
just a direct data binding approach which transforms the entire document
at once.
As for the awkwardness of the interface, here's a sample web services
client call using XMLBeans:
// retrieve a book directly
GetBookDocument gbd = GetBookDocument.Factory.newInstance();
GetBookDocument.GetBook gb =
GetBookDocument.GetBook.Factory.newInstance();
gb.setIsbn("0061020052");
gbd.setGetBook(gb);
GetBookResponseDocument gbrd = stub.getBook(gbd);
BookInformation book = gbrd.getGetBookResponse().getBook();
System.out.println("Retrieved '" + book.getTitle() + '\'');
Here's the same call using JAXB:
// retrieve a book directly
GetBook gb = new GetBook();
gb.setIsbn("0061020052");
GetBookResponse gbr = stub.getBook(gb);
BookInformation book = gbr.getGetBookReturn();
System.out.println("Retrieved '" + book.getTitle() + '\'');
And here's the same call using JiBX or ADB binding with an unwrapped
interface:
// retrieve a book directly
Book book = stub.getBook(isbn);
System.out.println("Retrieved '" + book.getTitle() + '\'');
In my experience, most developers find the extra layers of wrapper
classes and factory classes, and the mix of outer/inner classes used by
XMLBeans, a bit painful. Certainly it leads to considerably more verbose
code, at any rate.
- Dennis
