EJB design patterns : advanced patterns, processes, and idioms

275 Pages·2002·0.665 MB·English

by  Floyd Marinescu

EJB™ Design Patterns
Advanced Patterns, Processes,
and Idioms
Floyd Marinescu
Wiley Computer Publishing
John Wiley & Sons, Inc.
NEW YORK • CHICHESTER • WEINHEIM • BRISBANE • SINGAPORE • TORONTO
Publisher: Robert Ipsen
Editor: Robert Elliott
Developmental Editor: Emilie Herman
Managing Editor: John Atkins
Text Design & Composition: John Wiley Composition Services
Designations used by companies to distinguish their products are often claimed as
trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the
product names appear in initial capital or ALLCAPITALLETTERS. Readers, how-
ever, should contact the appropriate companies for more complete information
regarding trademarks and registration.
This book is printed on acid-free paper. ∞
Copyright © 2002 by The Middleware Company. All rights reserved.
Published by John Wiley & Sons, Inc.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system or trans-
mitted in any form or by any means, electronic, mechanical, photocopying, recording,
scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976
United States Copyright Act, without either the prior written permission of the
Publisher, or authorization through payment of the appropriate per-copy fee to the
Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA01923, [phone],
fax [phone]. Requests to the Publisher for permission should be addressed to
the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York,
NY 10158-0012, [phone], fax [phone], E-mail: [email protected].
This publication is designed to provide accurate and authoritative information in
regard to the subject matter covered. It is sold with the understanding that the pub-
lisher is not engaged in professional services. If professional advice or other expert
assistance is required, the services of a competent professional person should be
sought.
ISBN: 0-471-20831-0
Printed in the United States of America.
10 9 8 7 6 5 4 3 2 1
Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xix
About the Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxiii
Part One EJB Pattern Language . . . . . . . . . . . . . . . . . . . . . . . .1
Chapter 1 EJB Layer Architectural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . .3
Session Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Message Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
EJB Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Data Transfer Object Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Generic Attribute Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Business Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Chapter 2 Inter-Tier Data Transfer Patterns . . . . . . . . . . . . . . . . . . . . . . . . .45
Data Transfer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Domain Data Transfer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Custom Data Transfer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Data Transfer HashMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Data Transfer RowSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
viii Contents
Chapter 3 Transaction and Persistence Patterns . . . . . . . . . . . . . . . . . . . . .69
Version Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
JDBC for Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Data Access Command Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Dual Persistent Entity Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Chapter 4 Client-Side EJB Interaction Patterns . . . . . . . . . . . . . . . . . . . . . .91
EJBHomeFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Business Delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Chapter 5 Primary Key Generation Strategies . . . . . . . . . . . . . . . . . . . . . .105
Sequence Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
UUID for EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Stored Procedures for Autogenerated Keys . . . . . . . . . . . . . . . . . .117
Part Two Best Practices for EJB Design and
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Chapter6 From Requirements to Pattern-Driven Design . . . . . . . . . . . .123
TheServerSide’s Forum Messaging System Use Cases . . . . . . . . .124
AQuick Referesher on Design Issues and Terminology . . . . . . . .126
What Is a Domain Model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Understanding the Layers in a J2EE System . . . . . . . . . . . . . . .127
Pattern-Driven EJB Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Domain and Persistence Layer Patterns . . . . . . . . . . . . . . . . . . .130
Services Layer Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Asychronous Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Synchronous Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Other Services Layer Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Inter-Tier Data Transfer Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Application Layer Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Chapter 7 EJB Development Process: Building with
Ant and Unit Testing with Junit . . . . . . . . . . . . . . . . . . . . . . . . .143
Order of Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Layer-Independent Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Domain First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Persistence Second . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Services Third . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Clients Last . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Contents ix
Automating Environment Administration with Ant . . . . . . . . . . .149
What Is a J2EE Application Environment? . . . . . . . . . . . . . . . . .149
What Does It Mean to Administer
a J2EE Application Environment? . . . . . . . . . . . . . . . . . . . . . . . .151
Using Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Unit Testing with JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Chapter 8 Alternatives to Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Entity Beans Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Entity Beans and Cognitive Dissonance . . . . . . . . . . . . . . . . . . . . .180
In Defense of Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Alternatives to Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Use Straight JDBC/Stored Procedures . . . . . . . . . . . . . . . . . . . .183
Use a Third Party O/R Mapping Product . . . . . . . . . . . . . . . . .184
Build a Custom Persistence Framework . . . . . . . . . . . . . . . . . . .184
Use Java Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
An EJB Developer’s Introduction to Java Data Objects . . . . . . . .185
Class Requirements and Dependencies . . . . . . . . . . . . . . . . . . .185
Build and Deployment Processes . . . . . . . . . . . . . . . . . . . . . . . .187
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Client APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Dynamic versus Static Discovery Mechanisms . . . . . . . . . . . . .189
An EJB Developer’s Guide to Using JDO . . . . . . . . . . . . . . . . . . . .189
Preparing Your EJB Environment . . . . . . . . . . . . . . . . . . . . . . . .189
Configuring Session Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Executing Use Cases and Transaction Management . . . . . . . .191
Container-Managed Transactions . . . . . . . . . . . . . . . . . . . . . . . .191
Bean-Managed Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Caching/Lazy Loading and Reference Navigation . . . . . . . . .193
Finding Java Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Inter-Tier Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Chapter 9 EJB Design Strategies, Idioms, and Tips . . . . . . . . . . . . . . . . . .199
Don’t Use the Composite Entity Bean Pattern . . . . . . . . . . . . . . . .199
Use a Field-Naming Convention to Allow for Validation
in EJB 2.0 CMPEntity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Don’t Get and Set Value/Data Transfer Objects
on Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
x Contents
Using Java Singletons Is OK If They’re Used Correctly . . . . . . . .201
Prefer Scheduled Updates to Real-Time Computation . . . . . . . . .202
Use a Serialized Java Class to Add Compiler Type Checking
to Message-Driven Bean Interactions . . . . . . . . . . . . . . . . . . . . . . .202
Always Call setRollbackOnlywhen Application
Exceptions Occur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Limit Parameters to ejbCreate . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Don’t Use Data Transfer Objects in ejbCreate . . . . . . . . . . . . . . . . .204
Don’t Use XMLto Communicate as a DTO Mechanism
Unless You Really, Really Have To . . . . . . . . . . . . . . . . . . . . . . . . . .204
Appendix Pattern Code Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Foreword
Most well-architected EJB projects make use of design patterns. Whether or not
a developer is actually aware that he’s using design patterns is another story.
Oftentimes developers conceive of best practices during their projects, and
aren’t aware that these best practices are actually design patterns—reusable
approaches to programming—that are beneficial to other developers on their
projects as well.
That is the beauty of the EJB design patterns presented in this book—they
are practical, real-world patterns extracted from actualEJB projects. Members
of the J2EE community were encouraged to share their patterns on TheServer-
Side.com, a Web site where J2EE developers learn from each other. We’ve all
worked together as a community to flesh out those patterns and bring them to
you.
Floyd Marinescu, the world’s leading expert in EJB design patterns, led this
EJB design patterns project initiative. Floyd and I have been working together
for the past several years building The Middleware Company, a training and
consulting company that helps developers master Enterprise Java. At The
Middleware Company, we’ve been consulting on real-world projects to
enhance the quality of the design patterns. We’ve also been teaching training
courses on EJB design patterns to developers like you, and the feedback from
those courses have improved the quality of this book tremendously.
In this book, Floyd will show you a multitude of EJB design patterns that
you can harness to enhance your EJB projects today. By applying these design
patterns with proper judgment, you can improve the quality of your architec-
ture, make your code more reusable and elegant, and architect your systems to
be easily understood by developers who are familiar with these patterns.
xi
xii Foreword
The best news about this book is that it’s very approachable. Floyd has cho-
sen to use an easy-to-understand style of writing patterns, called the Alexan-
drian form. This makes it easy for anyone who knows how to program with
EJB to read and learn from this book. (And if you don’t know EJB yet, you may
want to read my book, Mastering Enterprise JavaBeans, Second Edition, which is
available in bookstores and as a complimentary download on TheServer-
Side.com.) Another choice is for you to take a training course in EJB, such as
one of those we offer at The Middleware Company.
When you’re ready to read on, you’re in for a treat. Floyd has devoted an
entire year of his life to tackling the toughest EJB design patterns concepts, and
the results benefit the entire EJB community. I’m honored to have worked with
Floyd on this project, and I’ve learned a lot myself along the way. I’m sure you
will as well.
Ed Roman
CEO, The Middleware Company
Author, Mastering Enterprise JavaBeans, Second Edition
Introduction
It’s all about quality of life. Whether you’re a developer, architect, or project
manager, at the end of the day we all want to feel good about building and
deploying well-designed applications, without making costly mistakes, work-
ing long hours, and going through months of stress. At the end of the day, we
are all human, we all want to see the project proceed on schedule and go home
with enough free time to spend on anything we like.
Unfortunately, well-designed applications are not easy to come by when
using new and still maturing technologies such as Java 2 Enterprise Edition
(J2EE). In relatively new fields such as this, there is always a large deficit of
information about designing good systems. Developers are either reinventing
the wheel or simply making costly design mistakes on projects every day. With
no clear set of best practices to follow, the job of the EJB developer is very dif-
ficult. Learning good design is particularly difficult for newcomers to the tech-
nology, many of whom have never built distributed systems before and don’t
understand the fundamental needs that influence distributed systems design.
What makes things worse is that changes in the EJB specification from ver-
sion to version tend to bring about significant changes to the way that good
EJB systems should be designed. Particularly with the introduction of EJB 2.0,
many years worth of best practices discussed in even the most recently pub-
lished books on EJB simply no longer apply or do not have the same purpose,
and using such best practices can result in poorly designed systems.
It is with the concern for spreading good design ideas and improving the
quality of applications that developers design, and as a result the overall qual-
ity of life of the developers themselves, that this book (and The Middleware
Company’s EJB for Architects course—where the patterns in this book are
xiii
xiv Introduction
taught) was written. The end result is that we hope to help you learn the top
design strategies used in the industry today so that you will be able to quickly
design efficient, scalable, and maintainable systems.
The mechanism by which we hope to impart design knowledge to you is the
pattern.
What Is a Pattern?
I like to think of a pattern as a best practice solution to a common recurring prob-
lem. That is, a pattern documents and explains an important or challenging
problem that can occur when designing or implementing an application, and
then discusses a best practice solution to that problem. Over time, patterns
begin to embody the collective knowledge and experiences of the industry that
spawned it. For example, the patterns in this book represent the collective
knowledge of thousands of EJB developers from TheServerSide and in and
around the industry, all of whom contributed via ideas or reviews the material
in this book.
Benefits of Patterns
Of course there are many uses of patterns, but the following are some of the
most important benefits that can help drive the maturity of a new software
platform such as J2EE:
Helps provide a high-level language for discussing design issues. EJB
developers can use the pattern names in this book to discuss implemen-
tation details together efficiently. Imagine how much quicker it is to say
that an application was built using the stateless Session Façade pattern
than trying to explain all the semantics of how the session beans wrapped
entity beans.
Provides much of the design work upfront.Awell-written pattern dis-
cusses in detail the problem and issues that need to be solved and shows
how the problem solves it, with a good discussion of the pros, cons, and
other issues to be aware of. By reading a pattern, many challenging and
potentially hidden issues can be discussed and considered upfront.
Combinations of patterns lend themselves to reusable architectures.
Patterns tend to reference and built upon each other. This connection
between patterns serves to create what is called a pattern language: a
series of interconnected patterns that, as a whole, often suggest an over-
all architecture for an application. Thus, when reading this book, certain
sets of patterns in combination will form a reusable architecture that can
be applied across projects again and again.