Chapters 5 through 9 and the summary tables in the previous sections explore the details of JDBC, iBATIS, Hibernate Core, OpenJPA, and pureQuery within the context of our questionnaire. Within this context, you can see that each mechanism has its strengths and weaknesses. In other words, none is perfect for every situation; so you will likely have to make trade-offs for whichever mechanism you choose. For example:

Some architects will not be willing to make the trade-offs associated with each of these mechanisms and will instead use this knowledge as an excuse to invent their own persistence framework exactly tailored to their requirements. Although inventing your own persistence layer can be fun, especially for architects with a strong computing science background, we advise against doing so because it puts your programmers in the middleware business instead of developing mission-critical enterprise applications.

Why is this? Because it may seem relatively simple to develop a framework on top of a mechanism such as JDBC, but the runtime aspects of such a framework are only the tip of the iceberg. Very quickly, you will find yourself having to develop a number of tools to support other aspects of the application such as:

Further, if you build your own homegrown framework, you must also write documentation and create training programs for each of these tools geared toward the roles that use them. The reality is that the need to support your framework with tooling, documentation, and training will totally consume the resources of your team, leaving them no time to build any enterprise applications.

Invariably your requirements will change as user expectations and underlying technologies change, leaving you in the same situation you are in now—needing to understand how to make hard choices and real trade-offs among existing mechanisms.

If after understanding the challenges you still find yourself tempted to build your own proprietary persistence mechanism, we recommend that you keep in mind the overarching goals of any framework, whether used for providing persistence or another major aspect of the solution architecture:

We also recommend that you use the template developed in Chapter 4 as a guide to the questions you must be prepared to answer. In other words, reuse the questionnaire as an outline of your requirements, and fill in the details of each section the way you imagine your framework will be.

Our hope is that this exercise will lead you back to choosing an existing mechanism instead of building one yourself. But with that said, there may come a time when you must do some invention to meet specific project requirements that cannot be met in any other way.

In this case, we strongly recommend that you exploit an open-source community project like iBATIS or OpenJPA and extend it only as much as is needed for your project. This approach will let you piggyback on the skills and supporting tools developed by the community—including vendors who have embraced the project and any associated standards.

Assuming you take our advice to focus on the business applications that support your enterprise, you can submit your extensions back to the open-source community so that you aren’t stuck supporting them. You will be surprised at how quickly runtime components and associated tools and documentation you never dreamed of will emerge from the collective wisdom of the open-source community.

Exploiting the open-source community is one way to embrace change rather than trying to insulate your team from it. You can design your development processes to embrace change as well. We have found that agile approaches are best because they focus your attention on the practical problems that need to be solved during development of small but essential “increments” of application functions.

Agile incremental approaches fit well with our philosophy to “think before you act—just don’t do all of your thinking before acting.” That is, you should analyze the requirements before you design a solution, and then code, test, and deploy the application components; however, you should not do all the analysis, then design the entire solution, and then code the entire application before you test it on your users.

Although it is not the intent of this book to be a definitive guide for agile methods, Figure 10.1, a graphic from the Rational Unified Process (RUP), shows how a disciplined software engineering method (thinking before you act) can work together with an agile approach (not doing all of your thinking before acting).

Figure 10.1. The Rational Unified Process.

See the excellent IBM Press book on RUP by Joshua Barnes for more details [RUP]; however, the basic idea is that you use all the disciplines (shown as rows in Figure 10.1) to some extent or another in every phase (shown as columns)—each of which represents a project in its own right. And each phase can have a number of smaller, possibly overlapping increments to further break down the deliverable units. The graphs shown in each row indicate the amount of effort devoted to that discipline within that phase or iteration. So, for example, in the early inception phase, which is all about trying to prove the feasibility of the project, you will see more focus on modeling the business processes being supported and their requirements, but with enough analysis, design, implementation, test, and deployment to understand the end-to-end process.

The benefit of an agile approach like RUP boils down to early and often validation, which leads to refactoring the application components into better and better solutions before inertia sets in to your design and makes it nearly impossible to change.

Here is how we have applied RUP to meeting enterprise persistence requirements:

Also consider using the new “pattern authoring tools,” such as the new extended Java Emitter Template (JET) engine to build code generators based on your designs (see the excellent developerWorks article by Chris Gerken and Roland Barcia [A.10.2] for details). You can read more about JET at the associated website [JET].

A.10.2

We like to do these steps as early in the process as possible—such as during the inception phase (although they apply to any phase). Figure 10.2 shows these steps graphically.

Figure 10.2. Steps we like to follow during the RUP inception phase.

This approach ensures that you meet the IT requirements associated with persistence before you invest too much time in a particular “pattern.”

We also recommend that you document your decisions as you make them so that (a) you do not continually have the same discussions over and over again, and (b) you can more easily determine the impact of changing your mind or refactoring the design by understanding the dependencies between decisions. Minimally, we like to capture the following aspects of each decision (again, listed as a set of questions that need to be answered for those who follow you):

Within the context of persistence in the enterprise and this book, Chapter 4 documents the general set of forces we like to consider (with Chapters 1-3 providing the background); and Chapters 5 through 9 give you a good head start on the alternatives to consider, as well as details on how they solve the problem. Your specific project requirements add to the context and forces and will enable you to enumerate the pros and cons and make your decision. Documenting these decisions and dependencies will help you retrace only the steps necessary when and if you change your mind.