Mastering Enterprise JavaBeans

Mastering Enterprise JavaBeans

Paperback(Older Edition)

$37.59 $45.00 Save 16% Current price is $37.59, Original price is $45. You Save 16%.

Temporarily Out of Stock Online

Eligible for FREE SHIPPING

Overview

Mastering Enterprise JavaBeans by Ed Roman, Tyler Jewell, Floyd Marinescu, Scott W. Ambler

Building on the overwhelming success of his previous two editions, renowned author Ed Roman has returned-along with Enterprise JavaBeans (EJB) gurus Gerald Brose and Rima Patel Sriganesh-to offer you the inside scoop on the EJB 2.1 specification and related enhancements in J2EE 1.4. Continuing the tradition of providing you with an unparalleled EJB tutorial, this expert team of authors has revised more than 30 percent of the book and added new chapters that explore the dramatic changes in the way EJB is now used for building applications.

Serving as the ultimate resource that boasts the most up-to-date information on EJB, this edition begins with the fundamentals of building an EJB system and gradually moves on to a discussion of programming with EJB. You'll learn about advanced EJB concepts and best practices that you won't find anywhere else, such as transactions, persistence, clustering, integration, performance monitoring, security, and choosing an EJB server. Along the way, you'll get in-depth coverage of: EJB security mechanisms, Best practices for EJB application development, deployment, and testing, Tips for selecting appropriate Web frameworks and EJB containers, EJB integration with back-end enterprise information systems using J2EE Connector technology, Performance optimizations for various types of EJB

Product Details

ISBN-13: 9780471417118
Publisher: Wiley
Publication date: 12/14/2001
Edition description: Older Edition
Pages: 673
Product dimensions: 7.54(w) x 9.20(h) x 1.56(d)

About the Author

Ed Roman is one of the world's leading authorities on server-side Java technologies. He is CEO of The Middleware Company (www.middleware-company.com), a firm specializing in server-side Java training and consulting, and CEO of TheServerSide.com (www.TheServerSide.com), an online server-side Java community.

Scott W. Ambler is the author and editor of a series of successful books on Java and object technology. He is also a frequent speaker at major conferences.

Tyler Jewell is a software engineer at Talarian SmartSockets and is the primary author of all BEA WebLogic Server courses. He is also a speaker at a wide variety of conferences including Java Expo, Object Expo, Cysive, and JavaOne.

Read an Excerpt

Chapter 8: Introduction to Message-Driven Beans

In this chapter, we will learn about messaging, which is a lightweight vehicle for communications. Messaging is more appropriate than RMI-IIOP in numerous scenarios. We'll also learn about message-driven beans, special beans that can be accessed via messaging and a new addition to the EJB 2.0 specification.

Specifically, you'll learn about the following:

  • An introduction to messaging, including an overview of asynchronous behavior and message-oriented middleware
  • A brief tutorial of the Java Message Service (JMS), which message-driven beans depend on
  • Features of message-driven beans
  • How message-driven beans compare with entity and session beans
  • How to develop message-driven beans
  • Advanced message-driven bean topics, gotchas, and possible solutions

Motivation to Use Message-Driven Beans

In previous chapters, you learned how to code session and entity beans—distributed components that are accessed using RMI-IIOP. RMI-IIOP is a tradi-tional, heavyweight way to call components. While RMI-IIOP may be useful in many scenarios, several other areas are challenging for RMI-IIOP. Here are just three examples.

Performance. An RMI-IIOP client must wait (or block) while the server per-forms its processing. Only when the server completes its work does the client receive a return result, which allows it to continue processing.

Reliability. When an RMI-IIOP client calls the server, it has to be running. If the server crashes or the network crashes, the client cannot perform its intended operation.

Support for multiple senders and receivers. RMI-IIOP limits you to a single client talking to a single server at any given time. There is no built-in functionality for multiple clients to broadcast events to multiple servers.

Messaging is an alternative to remote method invocations and is shown in Figure 8.1. The idea behind messaging is that a middleman sits between the client and the server. (A layer of indirection solves every problem in computer science). This middleman receives messages from one or more message producers and broadcasts those messages to one or more message consumers. Because of this middleman, the producer can send a message and then continue processing. He can optionally be notified of the response later when the consumer finishes. This is called asynchronous programming.

Messaging addresses the three previous concerns with RMI-IIOP as follows.

Performance. A messaging client does not need to block when performing a request. As an example, when you purchase a book using Amazon.com's one-click order functionality, you can continue browsing the site without waiting to see if your credit card authorizes. Unless something goes wrong, Amazon.com sends you a confirmation email afterwards. This type of fire-and-forget system could easily be coded using messaging. When the user clicks to buy the book, a message is sent that results in credit card processing later. The user can continue to browse.

Reliability. If your message-oriented middleware supports guaranteed delivery, you can send a message and know for sure that it will reach its destination, even if the consumer is not available. You send the message to the MOM middleman, and that middleman routes the message to the consumer when he comes back alive again. With RMI-IIOP, this is not possible because there is no middleman: If the server is down, an exception is thrown.

Support for multiple senders and receivers. Most message-oriented middleware products can accept messages from many senders and broadcast them to many receivers. This allows you to have n-ary communications.

Note that messaging also has many disadvantages. Performance, for one, can be slower in many circumstances due to the overhead of having the messaging middleman. For a complete comparison of when to (and when not to) use messaging, see Chapter 13.

Message-oriented middleware (MOM) is a term used to refer to any infrastructure that supports messaging. Avariety of products are considered to have a MOM-based architecture. Examples include Tibco Rendezvous, IBM MQSeries, BEA Tuxedo/Q, Microsoft MSMQ, Talarian SmartSockets, Progress SonicMQ, and Fiorano FioranoMQ. These products can give you a whole host of value-added services, such as guaranteed message delivery, fault tolerance, load balancing of destinations, subscriber throttling of message consumption, inactive subscribers, and much, much more. By allowing the MOM server to address these infrastructure issues, you can focus on the business task at hand.

The Java Message Service (JMS)

Over the years, MOM systems have evolved in a proprietary way. Each prod-uct has its own API, which creates vendor lock-in because code is not portable to other messaging systems. It also hurts developers, because they need to relearn each messaging product's proprietary API.

The Java Message Service (JMS) is a messaging standard, designed to eliminate many of the disadvantages that MOM-based products faced over past years. JMS has two parts: an API, which you write code to send and receive mes-sages, and a Service Provider Interface (SPI) where you plug in JMS drivers. A JMS driver knows how to talk to a specific MOM implementation. The JMS promise is that you can learn the JMS API once and reuse your messaging code with different plug-and-play MOM implementations (an idea similar to the other J2EE APIs, such as JNDI or JDBC).


How Does Guaranteed Message Delivery Work? With guaranteed message delivery, the MOM system persists your messages to a file, database, or other store. Your message resides in the persistent store until it's sent to a message consumer, and the message consumer acknowledges the consumption of the message. If the acknowledgement of a message is not received in a reasonable amount of time, the message remains on the persistent store and is redelivered.

This feature is beneficial when the message consumer is brought down on a regular basis for maintenance, and lost messages are unacceptable. This is especially true in industries such as financial services, where messages represent securities changing hands.

A variation on the guaranteed message delivery theme is certified message delivery. Certified message delivery not only ensures the delivery of a message from a producer to a consumer, but also generates a consumption receipt that is delivered to the message originator, indicating a successful consumption of the message. Certified message delivery is used by producers to better manage communication with consumers.

Another variation of guaranteed message delivery is called store and forward. Store and forward allows a message producer to successfully send a message to an inactive MOM system. The producer transparently spools the message to a local store until the MOM system is reactivated, at which point the message is delivered to the MOM system and forwarded to any available consumers. Guaranteed message delivery without the store-and-forward option requires producers to send messages to active MOM systems, but consumers do not have to be active. Store and forward with guaranteed message delivery allows messages to be sent whether MOM systems or consumers are active or inactive.


Let's explore the JMS API and see how to write a simple JMS program that publishes messages.

Messaging Domains

When you perform messaging, you need to choose a domain. A domain is a fancy word for style of messaging. The types of domains are:
Publish/subscribe (pub/sub). Publish/subscribe is analogous to watching television. Many TV stations broadcast their signals, and many people listen to those broadcasts. Thus, with publish/subscribe, you can have many message producers talking to many message consumers. In this sense, the pub/sub domain is an implementation of a distributed event-driven processing model. Subscribers (listeners) register their interest in a particular event topic. Publishers (event sources) create messages (events) that are distributed to all of the subscribers (listeners). Producers aren't hard-coded to use specific consumers; rather, the MOM system maintains the subscriber list.

Point-to-point (PTP). Point-to-point is analogous to calling a toll-free number and leaving a voice mail. Some person will listen to your voice mail and then delete it. Thus, with point-to-point, you can have only a single consumer for each message. Multiple consumers can grab messages off the queue, but any given message is consumed exactly once. In this sense, point-to-point is a degenerate case of publish/subscribe. Multiple producers can send messages to the queue, but each message is delivered only to a single consumer. The way this works is that publishers send messages directly to the consumer or to a centralized queue. Messages are typically distributed off the queue in a first-in, first-out (FIFO) order, but this isn't assured.

The difference between publish/subscribe and point-to-point is shown in Figure 8.2....

Table of Contents

Acknowledgmentsxvi
Introductionxvii
Part 1Overview1
Chapter 1Overview3
The Motivation for Enterprise JavaBeans4
Component Architectures7
Divide and Conquer to the Extreme with Reusable Services9
Introducing Enterprise JavaBeans11
The EJB Ecosystem15
The Java 2 Platform, Enterprise Edition (J2EE)21
Summary2
Chapter 2EJB Fundamentals27
Enterprise Beans27
Distributed Objects: The Foundation for EJB30
Distributed Objects and Middleware32
What Constitutes an Enterprise Bean?36
Summary52
Chapter 3Writing Your First Bean53
How to Develop an EJB Component54
The Remote Interface55
The Local Interface56
The Home Interface57
The Local Home Interface59
The Bean Class61
The Deployment Descriptor64
The Vendor-Specific Files65
The Ejb-jar File65
Deploying the Bean66
The Optional EJB Client JAR File67
Understanding How to Call Beans68
Running the System72
Implementing Component Interfaces73
Summary75
Part 2The Triad of Beans77
Chapter 4Introduction to Session Beans79
Session Bean Lifetime79
Session Bean Subtypes80
Special Characteristics of Stateful Session Beans83
Summary102
Chapter 5Writing Session Bean Web Services103
Web Services Concepts103
Implementing a Web Service110
Implementing a Web Service Client114
Summary117
Chapter 6Introduction to Entity Beans119
Persistence Concepts119
What Is an Entity Bean?122
Features of Entity Beans125
Entity Contexts137
Summary139
Chapter 7Writing Bean-Managed Persistent Entity Beans141
Entity Bean Coding Basics141
Bean-Managed Persistence Example: A Bank Account150
Running the Client Program175
Putting It All Together: Walking through a BMP Entity Bean's Life Cycle177
Summary180
Chapter 8Writing Container-Managed Persistent Entity Beans181
Features of CMP Entity Beans181
Implementation Guidelines for Container-Managed Persistence191
Container-Managed Persistence Example: A Product Line196
Running the Client Program214
The Life Cycle of a CMP Entity Bean214
Summary216
Chapter 9Introduction to Message-Driven Beans217
Motivation to Use Message-Driven Beans217
The Java Message Service219
Integrating JMS with EJB226
Developing Message-Driven Beans231
Advanced Concepts241
JMS Message-Driven Bean Gotchas244
Summary254
Chapter 10Adding Functionality to Your Beans255
Calling Beans from Other Beans255
Resource Factories259
Environment Properties262
Understanding Handles263
Summary265
Part 3Advanced Enterprise JavaBeans Concepts267
Chapter 11EJB Best Practices269
When to Use EJB270
How to Choose a Web Application Framework to Work with EJB272
Applying Model Driven Development in EJB Projects275
Applying Extreme Programming in EJB Projects277
Testing EJB279
Implementing Client-Side Callback Functionality in EJB282
Choosing Between Servlets and Stateless Session Beans as Service Endpoints284
Considering the Use of Aspect-Oriented Programming Techniques in EJB Projects284
Reflection, Dynamic Proxy, and EJB287
Deploying EJB Applications to Various Application Servers288
Debugging EJB290
Inheritance and Code Reuse in EJB291
Writing Singletons in EJB293
When to Use XML with EJB293
When to Use Messaging Versus RMI-IIOP294
Summary297
Chapter 12Transactions299
Motivation for Transactions300
Benefits of Transactions303
Transactional Models306
Enlisting in Transactions with Enterprise JavaBeans310
Container-Managed Transactions317
Programmatic Transactions in EJB324
Transactions from Client Code330
Transactional Isolation331
Distributed Transactions340
Designing Transactional Conversations in EJB343
J2EE Transaction Service and Extended Transactions346
Summary348
Chapter 13Security349
Introduction350
Web Application Security353
Understanding EJB Security357
Secure Interoperability378
Web Services Security381
Summary389
Chapter 14EJB Timers391
Scheduling391
EJB and Scheduling392
The EJB Timer Service394
Timer Example: CleanDayLimitOrdersEJB399
Strengths and Limitations of EJB Timer Service406
Summary408
Chapter 15BMP and CMP Relationships409
The CMP and BMP Difference410
Cardinality411
Directionality428
Lazy Loading433
Aggregation Versus Composition and Cascading Deletes434
Relationships and EJB-QL436
Recursive Relationships437
Circular Relationships438
Referential Integrity439
Summary444
Chapter 16Persistence Best Practices445
Comparing Entity Beans with Other Persistence Approaches446
Choosing Between CMP and BMP450
Choosing the Right Granularity for Entity Beans453
Persistence Tips and Tricks454
Summary475
Chapter 17EJB Integration477
Why Does Integration Matter?477
EJB and Integration479
J2EE Connector Architecture480
The J2EE Connector API486
System Contracts494
Connector Example: OutboundLoanRA508
Integration Best Practice: When to Use Which Technology541
Summary543
Chapter 18EJB Performance Optimizations545
It Pays to Be Proactive!545
The Stateful Versus Stateless Debate from a Performance Point of View547
How to Guarantee a Response Time with Capacity Planning549
Use Session Facade for Better Performance550
Choosing Between Local Interfaces and Remote Interfaces552
Partitioning Your Resources553
Tuning Stateless Session Beans554
Tuning Stateful Session Beans555
Tuning Entity Beans556
Tuning Message-Driven Beans563
Tuning Java Virtual Machine563
Miscellaneous Tuning Tips565
Choosing the Right EJB Server567
Summary568
Chapter 19Clustering569
Overview of Large-Scale Systems569
Instrumenting Clustered EJBs578
Other EJB Clustering Issues589
Summary591
Chapter 20Starting Your EJB Project on the Right Foot593
Get the Business Requirements Down593
Decide Whether J2EE Is the Right Choice594
Staff Your Project598
Design Your Complete Object Model600
Implement a Single Vertical Slice601
Choose an Application Server603
Divide Your Team604
Invest in Tools606
Invest in a Standard Build Process607
Next Steps607
Summary608
Chapter 21Choosing an EJB Server609
J2EE Standard Compliance610
Pluggable JRE610
Conversion Tools610
Complex Mappings611
Third-Party JDBC Driver Support611
Lazy Loading611
Deferred Database Writes611
Pluggable Persistence Providers611
In-Memory Data Cache612
Integrated Tier Support612
Scalability612
High Availability613
Security613
IDE Integration614
UML Editor Integration615
Intelligent Load Balancing615
Stateless Transparent Fail-over615
Clustering616
Java Management Extension (JMX)616
Administrative Support616
Hot Deployment617
Instance Pooling617
Automatic EJB Generation617
Clean Shutdown617
Real-Time Deployment618
Distributed Transactions618
Superior Messaging Architecture618
Provided EJB Components619
Web Services619
Workflow619
Open Source620
Specialized Services620
Nontechnical Criteria621
Summary621
Chapter 22EJB-J2EE Integration: Building a Complete Application623
The Business Problem623
A Preview of the Final Web Site624
Scoping the Technical Requirements630
Example Code643
Summary651
Appendix ARMI-IIOP and JNDI Tutorial653
Appendix BCORBA Interoperability683
Appendix CDeployment Descriptor Reference705
Appendix DThe EJB Query Language (EJB-QL)739
Appendix EEJB Quick Reference Guide757
Index801

Preface

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

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews