XML vs. object trees

Question

In my current project (an order management system build from scratch), we are handling orders in the form of XML objects which are saved in a relational database.

I would outline the requirements like this:

• Selecting various details from anywhere in the order
• Updating / enriching data (e.g. from the CRM system)
• Keeping a record of the changes (invalidating old data, inserting new values)
• Details of orders should be easily selectable by SQL queries (for 2nd level support)

What we did:

• The serialization is done with proprietary code, disassembling the order into tables like customer, address, phone_number, order_position etc.
• Whenever an order is processed a bit further (e.g. due to an incoming event), it is read completely from the database and assembled back into a XML document.
• Selection of data is done by XPath (scattered over code).
• Most updates are done directly in the database (the order will then be reloaded for the next step).

The problems we face:

• The order structure (XSD) evolves with every release. Therefore XPaths and the custom persistence often breaks and produces bugs.
• We ended up having a mixture of working with the document and the database (because the persistence layer can not persist the changes in the document).

Performance is not really an issue (yet), since it is an offline system and orders are often intentionally delayed by days.

I do not expect free consultancy here, but I am a little confused on how the approach could be improved (next time, basically).

What would you think is a good solution for handling these requirements? Would working with an object graph, something like JXPath and OGNL and an OR mapper be a better approach? Or using XML support of e.g. the Oracle database?

Answer 1

If your schema changes often, I would advise against using any kind of object-mapping. You'd keep changing boilerplate code just for the heck of it.

Instead, use the declarative schema definition to validate data changes and access. Consider an order as a single datum, expressed as an XML document. Use a document-oriented store like MongoDB, Cassandra or one of the many XML databases to manipulate the document directly. Don't bother with cutting it into pieces to store it in a relational db.

Making the data accessible via reporting tools in a relational database might be considered secondary. A simple map-reduce job on a MongoDB, for example, could populate the required order details into a relational database whenever required, separating the two use cases quite naturally.

Answer 2

The standard Java EE approach is to represent your data as POJOs and use JPA for the database access and JAXB to convert the objects to/from XML.

JPA

• Object-to-Relational standard
• Supported by all the application server vendors.
• Multiple available implementations EclipseLink, Hibernate, etc.
• Powerful query language JPQL (that is very similar to SQL)
• Handles query optimization for you.

JAXB

• Object-to-XML standard
• Supported by all the application server vendors.
• Multiple implementations available: EclipseLink MOXy, Metro, Apache JaxMe, etc.

Example

• http://bdoughan.blogspot.com/2010/08/creating-restful-web-service-part-15.html