The project I'm working on is a small group and expect significant
evolutionary changes to our software, primarily due to an evolving
database schema. I originally annotated our existing Hibernate
generated persistence objects (entity beans) with javax.xml.bind.*
annotation (XmlRootElement, etc) and let JAXB and Jersey create the XML
schema. We will have customers that will be using the current instance
of our ReST resources that will not be able to easily migrate their
software as we evolve. For example, if we remove a column from a
database table, removing the attribute from our entity bean, and from
the URI query string, new clients will be able to communicate with the
newly generated schema but legacy clients will get errors in their query
strings and my resources would get errors trying to parse the incoming
xml. One solution we have looked at is to create multiple versions of
our services:
http://host:7001/app/v1/toy
Would be the first instance and the URI would be mapped to
- com.company.rest.resources.ToyV1Resource.java
and return instances of com.company.persistence.Toy.java
Here is the problem... Toy is an EJB3 entity bean created from
Hibernate that is serviced by our EJB3 Stateless session beans. If I
removed a column from the database, the client still wants access to the
data so if I marked that class attribute (say String toyColor) as
@XmlTransient, JAXB would exclude it from the generated schema but
client 1 still is expecting the color attribute, even if it is
meaningless in the new Schema.
We'd like to create a new resource:
- com.company.rest.resourcres.ToyV2Resource.java
(
http://host:7001/app/v2/toy)
that is agnostic of the change and update the V1 resource to be aware of
the change and for example, return the toyColor XML element or attribute
as an empty string....
Would an external JAXB configuration file be the way to go? Multiple
JAXB configurations, one for each schema instance? It would seem that I
would have to manually implement the JAXBContext using an custom JAX
message body readers and writers...?
In a nutshell, I'm looking for a way to support multiple schemas that
bind to a single object, and support multiple versions of the schemas
concurrently to support legacy ReST service users.
--mark
_______________________________________________
Mark A. Rabick
Software Engineer
Northrop Grumman - C2 Systems (MS/C2SD/IIS)
3200 Samson Way
Bellevue, NE 68123
Ph: (402) 293-7091
Em: mark.rabick_at_ngc.com
Remember PFC Ross A. McGinnis...
http://www.army.mil/medalofhonor/McGinnis/index.html
... MA2 Michael A. Monsoor, Lt. Michael P. Murphy, Cpl. Jason Dunham,
SFC Paul Ray Smith and the rest...
http://www.cmohs.org/recipients/most_recent.htm