Mr. DiFrango has over 15 years experience specializing in architecture, design, and construction of distributed, integrated systems in the enterprise and web environments. This experience includes expertise in Enterprise Systems Integration, Application Development, Service Oriented Architecture, Content Management Integration and Portal Solutions. Mr. DiFrango specializes in the JBoss Portal, Alfresco, Weblogic and Tibco product suites. Product expertise pertains primarily to Application Servers, Service Enablement Products, Content Management Integration, and Portal frameworks. Mr. DiFrango is experienced in architecting, designing and developing J2EE standardized Applications. This experience includes full lifecycle development from creating OO designs through to product testing. Mr. DiFrango also has experience leading teams of analysts, developers, and testers through troubleshooting complex development, mentoring staff, managing development schedules and work assignments, and providing architectural guidance. He is experienced in software development methodologies including procedural or waterfall, and Agile projects. He also has extensive experience with modeling systems during analysis, design, and construction using UML.
Where The Rubber Meets The Road With Your SOA Domain Model
Nov 26 2007
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.
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.
© 2010 CapTech Ventures, Inc. All Rights Reserved. Legal Notices.