Mastering Enterprise Javabeans

• Authors: Ed Roman;Scott W. Ambler;Floyd Marinescu
• Venue: Mastering Enterprise Javabeans
• Year: 2001

From the Book:As I write these words, I can't help but think back to an inflection point that occurred in my life almost three years ago. I remember sitting in my cubicle at Trilogy Software, an e-commerce company in Austin, Texas, lost in deep middleware thoughts. My challenge was to devise an interesting load-balancing strategy for our in-house application server, which we called the backbone. The backbone was a superb software system. It was cleanly written, easy to use, and boasted some very high-end features聴features such as distributed object support, object-relational mapping, and extensible domain object modeling. It had almost anything you needed for Internet development. It was a worthy investment for Trilogy. I was part of a task force to add enterprise features to this backbone, such as transaction control, security, and load-balancing. Our goal was to improve the backbone into a product worthy of large-scale deployment. So that day, after hours of racking my brain, I finally finished crafting what I believed to be a highly creative and optimal load-balancing strategy. Looking for feedback, I walked to my friend Court Demas' office. Court is one of those developers who can really pick apart almost any design and expose its flaws聴 a unique quality that only a few developers I know have. Walking into Court's office, I was expecting a typical developer-level conversation, and that's what I received. We turned the design inside and out, marking up my freshly printed hard copy with scribbles and other unintelligible comments that only we could understand. Finally, satisfied that we had reached a conclusion, I thanked Court and walked toward the door, prepared to implement the changes we had agreed upon. But I didn't make it that far. Court said something to me that would change my way of thinking. His comment baffled and confused me at first, but would eventually result in a complete paradigm shift and career move for me. What did Court say? Nothing profound, but simply, "You know Ed, this stuff is really what Enterprise JavaBeans is for." At first, I had no idea what he was talking about. Enterprise JavaBeans? What's that? Something like regular JavaBeans? Eventually, Court managed to explain to me what EJB was. And once he explained it, I knew that Trilogy had to do a 180-degree turn or lose its competitive advantage. You see, EJB is a specification for a server-side component marketplace. EJB enables you to purchase off-the-shelf components from one vendor, combine them with components from another vendor, and run those components in an application server written by yet a third vendor. This means companies can collaborate on the server side. EJB enables you to buy, rather than build, elements of server-side applications. The EJB value proposition had strong ramifications for Trilogy. EJB represented a way for Trilogy to get out of the middleware business and concentrate on its e-commerce strategic efforts. This meant discarding the backbone completely in favor of a third-party vendor's architecture. Not only would this reduce Trilogy's maintenance costs, but it would also solidify its software suite, since their middleware would now be written by professionals who had been in the business for 20 years. This proposition would eventually lead to Trilogy forming an entirely new business unit. I decided to start researching EJB and pushing for Trilogy to adopt it. I went to the Sun Microsystems Web page, downloaded the EJB 1.0 specification in PDF form, and printed it out. Back then, the specification was about a third of the size it is today. Understanding the specification turned out to be much more challenging than downloading it. The specification was written for system-level vendors and was not meant to be a tutorial for end developers. The section on entity beans, for example, took me a good two months to really grasp, as the notion of persistent components was new to me. This arduous struggle with understanding the EJB specification is what eventually led me to write this book for you. This book represents everything I wish I had when I first started using EJB in 1998. So what is this book about? Well, it may be more accurate to tell you what this book is not. This is not EJB propaganda. It is not a book on how to write EJB code on any single application server. This is not a nice book that paints a perfect picture of the EJB world. Nor is it an advertisement for any particular EJB product or a campaign to rid the world of Microsoft. The goal of this book is to help you. I want you to be able to craft solid, secure, and scalable server-side deployments. As you read this book, you'll learn how to design, implement, and deploy EJB solutions. This book covers both the vision and the reality of EJB from an independent developer's perspective. I hope it will prepare you for the challenges you will face. I wish the grass was greener and that I could write a book on how clean and portable EJB is; but the truth is that this technology is not perfect, and you should know exactly what the imperfections are. I will expose you to the gruesome and incompatible parts of EJB and also explain how the industry is solving these problems. Indeed, the newer specifications (especially EJB 2.0) improve portability and reduce incompatibilities tremendously. I hope that by the time you're done reading this book, you are convinced that the vision of EJB is solid, and the future is very bright. My hope is that I can save you time and energy, and aid you in designing wellcrafted server-side deployments. But this is merely the beginning. The EJB marketplace is just getting started, and there's a whole lot more work ahead. I encourage you to take an active role in the middleware industry and to work with me taking EJB to the next level. Feel free to write your experiences, tips, and design strategies, and post them on TheServerSide.com to share with others. Our goal is to increase our knowledge of EJB as a community, and together, we can do it. Ed Roman