Not sure if this is the best idea but I would try to convert everything into objects (so the main problem being converting XML into objects). You need a common denominator, no? Objects it is...
You may want to look at RESTeasy as well...
Thanks for the reply.
In a sense, I already have objects in that the Entity and XML annotations are applied to the base Java class object.
With respect to RESTeasy, I am using it to provide the REST service but it really doesn't come into play here since it is more of a way of annotating the HTTP conversation between REST clients and the service.
What I am trying to achieve is a conversation sequence that looks this this:
web - object - XML - HTTP/REST - XML - object - entity (i.e. the request)
and then the response
entity - object - XML - HTTP - JAXB - object - web (i.e. the response)
If I choose to make the XML classes different from the DAO classes, I can get all this to work but I will then need to keep two classes in sync with each other (database entities and XML). I was trying to see if there was a way to use one class to achieve the same ends.
I basically did that. We had to interface with numrous sources from plain text over email up to flull-blown web-services. All information must be gathered, validated, filtered and
fusionedand must be given back to all users (via a web-page or web-service). Our core is a domain model (or canonical datamodel or whatever you want to call it) and it is implemented using JPA. The entities contain all annotations for the entity, validation and marshalling.
Whatever you do, the most important thing you need to keep in mind is that the objects are represented differently. So the rich objectmodel must be annotated in such a way that you can store it and XML'it.
For the first you need to decide on the how to efficiently make the ORM. The most optimal Database scheme doesn't necesarely gets you the most effective objects, so its a matter of choosing the most optimal setting for your specific needs. I choose to implement with the object-model as basis, so some DB-constructs can't be used easily. An additional trick is to define DB-Views and map additional entities to these views. depending on your choice of DB This can rocket your application to light-speed.
For the second (XML) part keep in mind that objects tend to have a lot of references and the most complex ones: to themmselves, meaning that XML-marshalling is quite memory expensive or even impossible. Here you need to use the XML transient annotation a lot without loosing functionality.
To make life easy I use Maven especially to build from the XML-Schema; there is a nice plugin for XJC. For the DB-part I use seam-gen a lot and a lot of try-and-error agony and headache. But I am where I want to be.
RestEasy saved my day for implementing services and in combination with Seam it gets even better.
In short: your idea is feasible but takes a time.
Thanks for the comments. It's nice to know that what I was thinking about is possible. I'm going to have to think about the trade off between the de-normalized database schema and the object model vs. keeping entity and business objects in separate packages.
I agree with your comments about RESTeasy and XJC. I am using both heavily on this project.