A great military strategist once explained how ‘friction’–the unexpected things that happen in the fog of war–can often cause the best-laid war strategies to flounder (Carl von Clausewitz in ‘Vom Kriege’). Similarly, any decent software engineer knows that friction–in the fog of the Software Development Life Cycle (SDLC)–can also have significant impacts on deployment time as well as overall project success. Armed with the knowledge of friction–an ever present foe in every software project–development teams and project managers can maximize project success by minimizing project friction.
JEE Web Application Development and the Status Quo
Given that the shortest distance between two points is a straight line, the same axiom should hold true for data. However, in the SDLC of a typical JEE web application, this is certainly not the case for the data moving through the system. In the early phases of the SDLC, data elements are identified and tables are structured in the RDBMS to logically model and represent this data. Many times, software teams will have to mock-out the data model in the middle and data-tiers while the DBA team builds the table structures the data-tier will talk to. This data modeling and analysis phase introduces significant project and system friction due to its inherent complexity.
Once the logical data model is built, Object Relational Mapping (ORM) frameworks are often employed in the data-tier of the typical JEE web application to retrieve data stored in the RDBMs and to map that data to Java Objects. This process takes the raw data, which we ultimately want to see in the front-end, and adds to it the additional overhead of Java Objects. This takes place through a cumbersome relational-to-object transformation process just so the data can move comfortably through the data and middle-tiers to the client-tier. This data transformation and associated overhead is inefficient and prone to friction.
Now that the data has been retrieved from the RDBMS and mapped to Java Objects, it is now possible to merge this data with JSP-based (or some other rendering mechanism) view-oriented frameworks, such as Struts or Java Server Faces (JSF). Oftentimes, these views have to be compiled server-side before they can be rendered on the client. Not only does this create run-time inefficiencies in adding additional data transformations in the server-side view preparation, but it also slows down development time as well: more unnecessary friction.
Is There A Better Way?