XML Driven Software Architecture

As technologies are evolving from a procedural to object oriented and architectural principals as loose coupled and flexible software is ideal, developers are constantly thinking or taught to think that abstraction is good and brittle code is bad. This idea has also evolved in Information Technology (IT) enterprises where the notion of a service has caught. Since IT enterprises involve more than hard-core java drinking code junkies, services have evolved into business services where services abstract business processes from their supporting IT systems. As Business Processes are changing with respec... WAIT!!! This is a Technie blog entry so lets stay in the realm of software, hardware and whatever makes a java drinking, red-bull drinking, dry cereal snacking technie happy.

As software architects and developers are praising the likes of Gavin King, who developed the Object Relational Mapping (ORM) technology Hibernate, since they developed technology which abstracts developers from knowing how the data is stored in a relational database. ORM technologies allow programmers think in objects rather than normalized relational tables with primary and foreign keys. The wide argument is that programmers won't get bogged down by writing sql queries but they can simply think of their code as objects. The problem with this notion is that sometimes ORM queries can be poorly written.

As I was pondering this issue today, I realized that ORM still couples the software code like Java to the structure of the database. From my experience, when new tables or fields were created in the database, the ORM code has to be modified and this in turn may affect the actual business logic code. This could get painful when new requirements or the Database Administrator (DBA) has provided a new design to optimize the database.

One way to get around this issue to design the business datamodel as a XML Schemas (XSD). After working with XSDs, I believe they do a great job of capturing the object model. After creating the XSD, generate XMLBeans or JAXB classes and code to these classes. The JDBC code or ORM code can be then communicate to the business logic tier via the XML binding classes. This way the XML binding classes provide a layer of abstraction between the data tier and the business logic tier. The problem with this approach is that XSD can be hairy however if you understand XML and XML technologies than this may be the way to go. The other issue is that there could be issues in the generate classes or how you created the XSD. Once again if you are comfortable with XML then may be a way to go since I think it could be better than ORM.

Please let me know if you disagree with me.