Wise men often say that the first step to wisdom is learning that we know nothing—not even the right questions to ask. The implication is that we must listen to those with experience and contemplate the deeper meaning of their questions and answers. And in the end, a new experience may undo much of what everyone thought to be true.
This observation applies not only to sages on a mountaintop contemplating esoteric subjects such as philosophy, but also to those of us needing to know about a highly technical subject like providing persistent data within enterprise Java applications.
Imagine you were asked to choose the persistence mechanism for new Java applications within your company, and then review your architectural decision with various stakeholders in the company. Right at the start of the review, you would have to be prepared to answer some questions of general interest:
Which persistence mechanisms were evaluated and why?
Of those evaluated, which ones were chosen for use and why?
Then, depending on the exact role of the stakeholders invited to the review, you would have to be prepared to drill down and answer specific questions about the details of the proposed architecture that are relevant to each reviewer and the job each must do. For example:
Manager and Executive roles evaluate the costs associated with making the transition to a new technology in terms of time, money, and other resources. They are interested in answers to questions about such topics as which vendors market a particular technology, the kinds of licensing agreements involved (and the restrictions those bring), the availability of skills, and references of successful applications using a given mechanism.
Analyst and Architect roles need to assess whether a given mechanism can support the business and IT requirements of applications expected by the End Users and Operators for whom they serve as advocates. They are interested in questions about functionality, such as whether the mechanism supports relationships, a wide variety of attribute types, triggers, and constraints. They are also interested in whether the mechanism can scale up to response time, throughput, and other “nonfunctional” goals of the application.
Developer and Tester roles are most impacted by the complexity of the framework and API in terms of the code they must write when implementing the services as objects mapped to a relational database layer. They are curious about how to handle specific coding tasks like creating connections, and reading/updating data in the context of the detailed database design for representative use cases.
The reality is that architecture of any type is more of an art than a science—which is what makes it such a challenging job to do well. It requires not just deep knowledge about methods and best practices that have worked in the past, but also a good sense of intuition about when to try something innovative.
A search of the Web for “Java and relational databases” returns a number of useful links to articles and books, but most are specific to a given mechanism—such as Java Database Connectivity (JDBC), Enterprise JavaBeans (EJB), Hibernate, or the new Java Persistence API (JPA). Some of these references go into detail on how to design the databases. Others are mainly guides on how to use the APIs to build a sample application. None of these references takes an end-to-end application architecture view that helps you understand the issues involved with choosing a persistence mechanism for relational data stores, and then helps you make a choice.
The reason that this end-to-end view is important is that, as noted above, good architects know the answers to the kinds of questions that will be asked by various stakeholder roles during a review. The better ones anticipate the questions and use those questions to drive their approach to design in the first place. But the best architects document these questions and answers in a cookbook form such that they guide every phase of an application development project, including analysis, design, construction, test, deployment, operations, and maintenance. Having the answers to these questions documented in a reusable form not only increases the quality of the applications, but also accelerates the development process—because the amount of time the team spends “reinventing the wheel” through trial and error is drastically reduced.
That end-to-end view is what makes this book different. We are all consultants with the IBM Software Services for WebSphere (ISSW) team. Our job is to help clients fully exploit our products, such as IBM WebSphere Application Server, WebSphere Portal Server, WebSphere Commerce Server, and WebSphere Process Server. We are often involved in proof of technology and head-to-head bake-offs that pair us with a client’s architects who are making build-versus-buy decisions or vendor and technology selections; so we are experts at taking this broader application-centric view and finding answers to tough questions.
This book looks at persistence frameworks, mostly Java based, in the same way so that you can propose a solution that satisfies all the stakeholders—from your CTO to your fellow architects, to the developers, testers, and operations team. And if you play one of these specific roles and find yourself in a review, this book will help you ask the right kinds of questions and be able to interpret the answers.
Another thing that makes this book different is that we endeavor to capture our unique on-the-job mentoring-based consulting approach. In a nutshell, we like to both “give you a fish” and “teach you how to catch it” at the same time. The ideal result of an ISSW engagement is that you have an early success with our products yet become self-sufficient for the future.
Although a book will never fully substitute for a live consultant directly engaging with you on a project, we make an attempt by informally dividing this book into two parts:
Part I, “A Question of Persistence,” teaches you about fishing so that you can “eat for a lifetime.” Specifically, it helps you understand what the issues and trade-offs are in choosing a Java persistence mechanism for relational data stores. These issues are organized into chapters based on the questions asked by the various stakeholder roles described previously. Specifically, there are three chapters that cover the following topics: Chapter 1 provides a brief history of relevant persistence mechanisms; Chapter 2 covers business drivers and associated IT requirements; and Chapter 3 discusses implementation issues associated with object-relational mapping. We end this part of the book with Chapter 4, which extracts a questionnaire from the issues and trade-offs discussed in the first three chapters so that each mechanism can be evaluated with a consistent “yardstick” and best-practice-based approach.
Part II, “Comparing Apples to Apples,” gives you some fish so that you can “eat for today.” Each chapter gathers the data for five popular mechanisms using the approach and questionnaire found in Chapter 4. In this section we explore Java Database Connectivity, iBATIS, Hibernate, Java Persistence API, and pureQuery as representative examples of the various approaches to Java persistence outlined in Chapter 1. We wrap up this part and the book itself with a summary in Chapter 10 that compares the mechanisms side by side and enumerates some scenarios in which one or the other best applies.
It has been said that “the more things change, the more they stay the same.” But they still change. The questionnaire developed in Chapter 4, “Evaluating Your Options,” is crucial to the longevity of this book because it is relatively easy to apply the same yardstick to new persistence frameworks and APIs as they become available. So to further enhance the value of the book, we include a reference to a download site for the questionnaire and code examples associated with the evaluations that you can use as is or customize for use within your own company as you evaluate these or other mechanisms.
Because this is a developerWorks book, we make use of some special references called “Links to developerWorks” that appear with a special icon in the margin and in their own section at the end the chapter. These references can be linked to the IBM developerWorks site at www.ibm.com/developerWorks/. We have found this feature to be a very exciting one because you can follow along on the site while you are reading the book and get instant access to those and other related articles and online books. The net effect is to extend this book into the World Wide Web, further enhancing its longevity.
We’ve also included a “References” section at the end of the chapters, which lists additional resources cited throughout the chapter. These resources are cited by [Author] within the chapter text.
We hope you agree that this book is worth stealing; but please take it to the nearest checkout counter or click the Add to Cart button now. If this happens to be a friend’s copy, please put it back on your friend’s desk or bookshelf and buy your own—it is available for purchase at online retail web sites and traditional brick-and-mortar stores that sell technical books about Java or database technologies.