Monday, November 26, 2007

Where The Rubber Meets The Road With Your SOA Domain Model

As discussed in an earlier posting, creating a Domain Model is critical to a successful SOA implementation. But how do you effectively utilize this model within your code base as you start to develop applications that are in tools or languages that do not manipulate the XML directly?

In my most recent project I had a team of off-shore and on-shore developers developing a new service based web application. We followed best practices and created our Domain Model in XML Schema. The architecture consisted of a Web front end that was to be implemented with a combination of Java Server Faces and Spring and a Business Service Layer that utilized TIBCO Business Works. On both sides of the equation we had to convert the XML Stream into Java objects that could be manipulated for display on the client side and rules execution on the Service side. The dilemma I had was how to eliminate the need for multiple sets of XML parsing code and the proliferation of Data Transfer style objects that typically followed along.

After some thought, I decided to create an single project that utilized an XML Binding framework to process the underlying schema. This ensured that we had one code base for both sides. In order to ease the integration, we evaluated frameworks that would work well with Spring on the client side; JAXB, XML Beans and Castor. After careful review of the features of each and some quick prototyping on which one would work well on both platforms, we settled on Castor. The main reason we choose Castor was because it interacted the smoothest with the JBoss Rules Engine that we were running on the service tier. The Castor generated objects act more like POJO's in that we can create them on the fly then perform the marshaling/unmarshaling as needed.

To ease the introduction of this approach to the development team, I created an ANT based process that pulled the Domain Model from our repository, built our Java Classes from the schema via Castor's Source Generator, and then created a standardized JAR file that both the web and services teams could utilize.

We estimated that this approach reduced the amount of code generated by at least 50% and simplified both code bases greatly. I will definitely leverage this approach on all my future projects.

1 comment:

  1. I think choosing Castor was a good move. I've used it in the past and found it to be very flexible.