This chapter is from the book
This chapter is from the book
This chapter is from the book
Project Background
I’d like to explain the patterns by using my experience with two projects that both decided to build a framework in order to facilitate application development. My experience in these projects were both positive and negative, and I’ll use the projects as running examples throughout this chapter. Let’s therefore first take a look at the two projects.
The Data Access Layer Framework
An insurance company faced the problem of having a large number of legacy systems that didn’t work together well. The company felt it was time for a change and decided to build several new applications, including new policy systems for health insurance, life insurance, and property insurance, as well as new customer, payment, commission, and workflow systems. It was a huge endeavor involving several teams, ranging from 8 to 40 people each, working on the various applications more or less simultaneously.
Early on, the project established a team that worked on what was called the "horizontal tasks": the specification, design, and coding of modules that many—and perhaps all—other teams could use. The motivation was to save time and costs, and to ensure a consistent architecture across the new applications.
It soon became clear that providing database access would be among these horizontal tasks. All applications required database access, and in order to hide the objects’ physical representations from the applications, all applications were supposed to introduce a data access layer into their architecture.
The team decided to build a framework that would provide the data access layer. The framework had to abstract over the individual applications’ data models and therefore allowed application developers to specify a mapping from domain-specific objects onto database tables. The framework also provided a mechanism for object versioning that was quite powerful. Application developers could tailor the framework to the individual needs of their projects by configuring the extent of object versioning that they needed.
The framework offered the advantage that the application programmers didn’t have to bother with the details of database access, including the intricate versioning mechanisms.
The Web Portal Framework
The goal of this project was to develop a Web portal for the financial industry. The portal included both Web content and applications, and was used by a bank to sell insurance products. The Web content covered general information about the available products, while the applications provided access to different insurance systems running on various back-end servers that stored and processed contracts and customer information.
Several of these applications had existed for a while when the plans for the portal were made, but a few still had to be developed. The project’s main task was to integrate old and new applications into the portal. The team decided to develop a J2EE-based framework that would provide a reusable infrastructure for all applications that had to be integrated into the portal.
The framework extended over the Web server and application server layers. Its task was to take user requests, forward them to the back-end applications, transform the results into HTML and integrate them into a Web presentation. The framework also managed the use cases for the entire portal and performed the necessary session handling.
Application developers essentially had to define the use cases their application required, and to provide a mapping from client requests onto application calls. They could then rely on the mechanisms the framework provided. The definition of the use cases required a bit of programming, but the bulk of integration work was done by the framework and hidden from the application developers.