It's not a secret anymore!
The moose likes Java in General and the fly likes Suggest design please Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Suggest design please" Watch "Suggest design please" New topic

Suggest design please

sumit anand kumar
Ranch Hand

Joined: Apr 28, 2010
Posts: 83
I have hosted a webservice application. The client sends a xml request, which i parse it using the xsd and JaxB. Naturally this jaxb generated class is inside the war file.

Now i have a situation, where i have multiple clients who may not be backward compatible xsd files to create a request.

So i have to support multiple xsd versions inside my war file. I thought of auto-generating the convertor class between jaxb generated classes & DAO objects. i did that but looks like i am facing a design issue and may have to generate the communication of different dao objects and database layer.

I don't fully agree with the above design, but i am unable to think of any alternative. Please suggest me a different design to handle this problem.

I don't want any debate about whats better or whats not, just some views that can allow me to improve my design.
Kathleen Angeles
Ranch Hand

Joined: Aug 06, 2012
Posts: 123

If this is in development process yet, use java polymorphism. Add an outer 'version' field. The version field can tell you which version of the data format it is. The polymorphism will be used on the type of data format; e.g. DataArea interface is the parent, DataParent001 and DataParent002 implements this interface to represent the 2 data format versions.

If this already in production, then you have to face the problem and accept that you will need to make 1 interface for each version; e.g. one http request url for each version. This is more of an operational problem thereafter.
sumit anand kumar
Ranch Hand

Joined: Apr 28, 2010
Posts: 83
The xsd contains a version field that can always be retrieved by non-strict parsing of xsd.

So i have a situation where
xsd1 -> convertor1 - > my dao object -> bean processing -> bean objects -> database

xsd2 -> convertor2 - > my dao object -> bean processing -> bean objects -> database

i have used freemarker to generate convertor1 & 2.

My challenge is for any minor upgrades of xsd, that break backward compatibility, i should be able to process the new xsd with minor or no code change.
So i have to do something to do code generation of "bean processing (does mostly nothing but maps/preprocess my dao to bean objects)" such that in future if new xsd is added i should make changes to a properties file and jobs done.

I feel there is some honest and better design that can help me in this problem. Please suggest.
I agree. Here's the link:
subject: Suggest design please
jQuery in Action, 3rd edition