I'm presently working on several data web services as part of a SOA and am considering utilizing JPA as the data in question could (likely will) move from one database engine to another approximatley 6 to 18 months after the services which operate on them are scheduled to come online (from the group presently reponsible for the data to a data warehouse group which does its own modeling).
The benefits of utilizing JPA in this scenario are obvious. I was wondering if you might respond with a couple of pitfalls or concerns to be aware of or address the issue of collabration so that schema mapping config changes can be kept to a minimum when changing databases.
JPA is definitely something that can help your project. A couple of hints might help you.
The schema generation features in the mappings can be a blessing and a curse. On the one hand, they can be used to generate a schema that is somewhat similar across the databases (as far as the platforms support the similarities), but on the other, having the schema generated by the JPA provider is not at all what you typically want, since the resulting schema is neither design optimal, nor DB optimized.
A more practical way to minimize and isolate the different database mappings is to use XML mapping files when you think that you are mapping something that is specific to a particular database. It is much easier to manage the database-specific bits when they are grouped in a single XML file. Remember that you can use multiple mapping files for the same persistence unit, so use that to your advantage.