Comparative Analysis: XML Data Binding tools
In the article XML.com: Comparing Java Data Binding Tools last year, JAX-B and something called XGen scored very highly, consistently taking second and first place in the tests and evaluations.
Castor came in somewhat lower.
It is a good article. They have a really in-depth feature-checklist comparison table in the article that could be very helpful to people. There are some graphs too, which by themselves are not very enlightening but with the other material to back things up they can be of some use.
Most companies, unfortunately meaning most programmers, have not woken up to how easy it is to convert the data objects floating around in their programs to XML using less effort in many cases than writing a dump using a lot of print statements, push it through a series of one or more XSLT stylesheets in a similar fashion to what programmers have been doing piping Unix commands output into other commands' input for over a generation, and then doing a final conversion into the ultimate output document format with a pre-existing utility.
Sounds like you don't have to do much work to get reports, web pages, and documents generated practically directly from your existing application programs and services, right?
Duh!
What did you think people were talking about when they said XML technology was revolutionary?
Anyway, the first step in this magic data-to-document pipeline is a good object-to-XML conversion mechanism. You can write it yourself using a little introspection and/or reflection - or you can use one of these prewritten data binding libraries. The choice of which you use probably depends on how much effort you want to put in up front to get the data in a format or two that will feed into XSLT-to-document converters. It is nice if you can get the data arranged so it is not, well, just data. Passing it as high-level information without too many extraneous levels can be helpful. So is some regularity. Because if all the similar forms of information have a similar overall arrangement, instead of wildly differing ones, it makes the stylesheet easier to write.
Pulling data from an SQL database is such a done deal. Every major database (Oracle, Microsoft, etc.) and XML-environment (Cocoon, etc.) provides at least one or two ways to do this, as does J2SE 1.5 itself (javax.xml.WebRowSet class). So chiefly it is only the data already in objects that you have to worry about. With this article tucked under your arm, you won't have much trouble picking one out. And if one of these Java Data to XML bindings is not too your liking, you can always code your own without too much trouble.
Castor came in somewhat lower.
It is a good article. They have a really in-depth feature-checklist comparison table in the article that could be very helpful to people. There are some graphs too, which by themselves are not very enlightening but with the other material to back things up they can be of some use.
Most companies, unfortunately meaning most programmers, have not woken up to how easy it is to convert the data objects floating around in their programs to XML using less effort in many cases than writing a dump using a lot of print statements, push it through a series of one or more XSLT stylesheets in a similar fashion to what programmers have been doing piping Unix commands output into other commands' input for over a generation, and then doing a final conversion into the ultimate output document format with a pre-existing utility.
Sounds like you don't have to do much work to get reports, web pages, and documents generated practically directly from your existing application programs and services, right?
Duh!
What did you think people were talking about when they said XML technology was revolutionary?
Anyway, the first step in this magic data-to-document pipeline is a good object-to-XML conversion mechanism. You can write it yourself using a little introspection and/or reflection - or you can use one of these prewritten data binding libraries. The choice of which you use probably depends on how much effort you want to put in up front to get the data in a format or two that will feed into XSLT-to-document converters. It is nice if you can get the data arranged so it is not, well, just data. Passing it as high-level information without too many extraneous levels can be helpful. So is some regularity. Because if all the similar forms of information have a similar overall arrangement, instead of wildly differing ones, it makes the stylesheet easier to write.
Pulling data from an SQL database is such a done deal. Every major database (Oracle, Microsoft, etc.) and XML-environment (Cocoon, etc.) provides at least one or two ways to do this, as does J2SE 1.5 itself (javax.xml.WebRowSet class). So chiefly it is only the data already in objects that you have to worry about. With this article tucked under your arm, you won't have much trouble picking one out. And if one of these Java Data to XML bindings is not too your liking, you can always code your own without too much trouble.
posted by John Collins | 4:43 PM
0 Comments:
Post a Comment
<< Home