I'm trying to get a handle on the right way to use JAXB with domain objects. All the accompanying examples imply that the classes generated by the JAXB compiler can be your domain object clases, which doesn't quite seem right to me. Some reasons why I don't think that would be right:

1. Suppose you already had a domain model implementation that you wanted to be able to represent as XML. Obviously you would not want the JAXB created classes to replace the ones you already have.

2. You can't put any business logic, or any other capabilities you might want to include, in the auto-generated classes.

3. There could be more than one schema that corresponds to your domain model.

4. You've coupled your domain model to both JAXB and an XML schema

It seems the "right" way to use these is like "value objects" with an Entity EJB. So am I totally off base here? Or stating the obvious? I haven't been able to find anything about this anywhere.

To me, whenever you use data binding to populate/persist your domain model (be it XML, RDBMS, whatever) you want a layer of separation - a set of value objects that conform to whatever structural concessions you have to make. I usually take a lot of effort to make what I feel is a sound domain model and am not willing to deviate from what I feel is a correct object structure for the sake of a technology that I am using. The reasons you list above are all valid. I don't have much experience with JAXB, but when I use Castor or TopLink I prefer to dedicate a set of value objects to the needed "view" of data and separate interaction with a data access layer (except for interactions initiated by an outside system in which case it would be funneled through a mechanism that is aware of the binding). Just my two cents.

- Kevin

You're right there are limitations to the JAXB API. The Java objects are mapped to the XML Schemas that you create. These are as you mentioned Value Objects. If you want more business logic in your objects, I think you should put those somewhere else.

There are many other customizations you can make with the binding declaration, including:
Name the package, derived classes, and methods
Assign types to the methods within the derived classes
Choose which elements to bind to classes
Decide how to bind each attribute and element declaration to a property in the appropriate content class
Choose the type of each attribute-value or content specification