Using Web Service Client JAXB Generated Classes as JPA Entities

Question

I am working on a project to retrieve data from a SOAP webservice and store it in a database for later use using JPA. Presently, I am using Spring WS as the client, and generating web service classes using JAXB.

The goal is to replicate all of the data contained in these classes (which are rather large) faithfully in the database, and to that end it is mildly tempting to apply JPA annotations to the JAXB generated classes. In the long run this seems dangerous, because the generated classes seem rather ephemeral, and I would do a lot of work re-applying jpa annotations while regenerating code if the wsdl ever changed.

The other option is to have my webservice client copy data into JPA entities created by me, possibly using a factory pattern. This decouples JPA persistence from the possibly changing whims of the WSDL designer, and somehow feels safer. It also feels safer because the entity classes can never be overwritten by a build task.

What is the best practice for this situation? Obviously, excessive decoupling does not pay off when it means lots of data transfer objects, but is this case special? Should JAXB created classes be used only in the webservice client, and quickly forgotten by the higher level application?

Answer 1

As a principle DO NOT change the objects generated by JAXB. As very rightly pointed out by you, these would change with every minor change to the WSDL.

The most accepted process would be to decouple your JAXB objects and the JPA Entities. There would be 2 primary advantages of the same

1. You can change your data binding provider at a later point of time if you feel JAXB is too slow or too memory intensive
2. You are not tying your JPA code to your DB code. So if tomorrow your WSDL changes or your DB structure changes either of these are not impacted.

To transfer data between the 2 you can use a factory pattern or use a bean mapping framework like

1. Dozer
2. Orika
3. Other options