《电脑编程》教学参考书籍文献（JAVA）EJB Design Patterns Advanced Patterns, Processes, and Idioms（2002, Floyd Marinescu, Wiley）

EJBT Design Patterns Advanced Patterns,Processes and ldioms Floyd Marinescu Wiley Computer Publishing 韧 John Wiley Sons,Inc. NEW YORK·CHICHESTER·WEINHEIM·BRISBANE·SINGAPORE·TORONTO

EJB™ Design Patterns Advanced Patterns, Processes, and Idioms Floyd Marinescu Wiley Computer Publishing John Wiley & Sons, Inc. NEW YORK • CHICHESTER • WEINHEIM • BRISBANE • SINGAPORE • TORONTO

Contents Foreword.......... Introduction .......................................................xii Acknowledgments …xix About the contributors..........................................xxiii Part One EJB Pattern Language ........................1 Chapter 1 EJB Layer Architectural Patterns 3 Session Facade.............. Message Facade 12 EJB Command ............................................18 Data Transfer Object Factory ................................26 Generic Attribute Access. .32 Business Interface........................................40 Chapter2 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

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 Contents

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 UUIDforEJB............................................112 Stored Procedures for Autogenerated Keys .117 Part Two Best Practices for EJB Design and Implementation ...........................121 Chapter 6 From Requirements to Pattern-Driven Design .123 TheServerSide's Forum Messaging System Use Cases .........124 A Quick 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 。年，。。。。。年。。。。。年。。g。 .137 Inter-Tier Data Transfer Patterns .137 Application Layer Patterns .. 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

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 Chapter 6 From Requirements to Pattern-Driven Design . . . . . . . . . . . .123 TheServerSide’s Forum Messaging System Use Cases . . . . . . . . .124 A Quick 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 viii Contents

Contents ix Automating Environment Administration with Ant.....19 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............... 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 CMP Entity Beans. .200 Don't Get and Set Value/Data Transfer Objects on Entity Beans.............. .201

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 CMP Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 Don’t Get and Set Value/Data Transfer Objects on Entity Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 Contents ix

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 setRollbackOnly when Application Exceptions Occur...................203 Limit Parameters to ejbCreate 202 Don't Use Data Transfer Objects in ejbCreate.................204 Don't Use XML to Communicate as a DTO Mechanism Unless You Really,Really Have To 204 Appendix Pattern code Listing ..................................207 References....… ....241 ...243

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 setRollbackOnly when Application Exceptions Occur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Limit Parameters to ejbCreate . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Don’t Use Data Transfer Objects in ejbCreate . . . . . . . . . . . . . . . . .204 Don’t Use XML to Communicate as a DTO Mechanism Unless You Really, Really Have To . . . . . . . . . . . . . . . . . . . . . . . . . .204 Appendix Pattern Code Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 x Contents

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 actual EJB 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

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 actual EJB 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. Foreword 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 Bea,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 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

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 xii Foreword

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 Java2Enterprise Edition (J2EE).In relatively new fields such as this,there is always a large deficit of 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

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 Introduction 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 ma 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 pattem 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 Facade pattern than trying to explain all the semantics of how the session beans wrapped entity beans. Provides much of the design work upfront.A well-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 pattems serves to create what is called le: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

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. A well-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. xiv Introduction

Introduction xv In this book in particular,we take a very low level,EJB-specific patterns focus.That is,rather than document general abstract patterns that could potentially be applied across technologies,we focus on how to get things done with EJB,discussing EJB-specific problems,and EJB-specific intricacies of implementation.Thus,in this book we part from many other patterns books in often showing exact implementations of a pattern (where the pattern is not project specific).The goal is to provide you,the EJB developer/architect with all the information you need to readily begin using these patterns in your EJB/J2EE-based applications. Origins of Patterns For many people,patterns were first introduced to them via the landmark book,Design Patterns:Elements of Reusable Object-Oriented Software (Gamma, et al.,1994).Not the first work on software patterns,this book had the positive effect of bringing the concept and use of patterns for software development into the mainstream. The actual origin of patterns begins long before Design Patterns was pub- lished in 1994.Patterns were first described by Christopher Alexander,applied to the construction/architecture of towns and buildings in the 1970s.In A Pat- tern Language (1977),Alexander writes:"Each pattern describes a problem which occurs over and over again in our environment,and then describes the core of the solution to that problem,in such a way that you can use this solu- tion a million times over,without ever doing it the same way twice." Patterns are a great way of organizing knowledge and solutions in any domain of life,not just civil engineering and software design.What makes pat. terns well suited for cataloging knowledge is their structure and hands nature.Good patterns show ways to solve problems and are structured in a style that lends itself well to explaining the aspects of the problem and solution at work. Pattern Style Used in This Book The patterns in this book are described with a style very similar to the original style used by Alexander,called Alexandrian form.The form I use consists of a pattern written up in a prose-like form,separated by a problem and solution statement as follows: Context:One or two sentences to describe the context in which the pattern applies. Problem:A question that illustrates thethe problem this pattern is solving. 米装举

In this book in particular, we take a very low level, EJB-specific patterns focus. That is, rather than document general abstract patterns that could potentially be applied across technologies, we focus on how to get things done with EJB, discussing EJB-specific problems, and EJB-specific intricacies of implementation. Thus, in this book we part from many other patterns books in often showing exact implementations of a pattern (where the pattern is not￾project specific). The goal is to provide you, the EJB developer/architect with all the information you need to readily begin using these patterns in your EJB/J2EE-based applications. Origins of Patterns For many people, patterns were first introduced to them via the landmark book, Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al., 1994). Not the first work on software patterns, this book had the positive effect of bringing the concept and use of patterns for software development into the mainstream. The actual origin of patterns begins long before Design Patterns was pub￾lished in 1994. Patterns were first described by Christopher Alexander, applied to the construction/architecture of towns and buildings in the 1970s. In A Pat￾tern Language (1977), Alexander writes: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solu￾tion a million times over, without ever doing it the same way twice.” Patterns are a great way of organizing knowledge and solutions in any domain of life, not just civil engineering and software design. What makes pat￾terns well suited for cataloging knowledge is their structure and hands-on nature. Good patterns show ways to solve problems and are structured in a style that lends itself well to explaining the aspects of the problem and solution at work. Pattern Style Used in This Book The patterns in this book are described with a style very similar to the original style used by Alexander, called Alexandrian form. The form I use consists of a pattern written up in a prose-like form, separated by a problem and solution statement as follows: Context: One or two sentences to describe the context in which the pattern applies. Problem: A question that illustrates the the problem this pattern is solving. * * * Introduction xv