Mastering Enterprise JavaBeans / Edition 3

Paperback (Print)
Buy Used
Buy Used from
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 95%)
Other sellers (Paperback)
  • All (24) from $1.99   
  • New (11) from $2.49   
  • Used (13) from $1.99   


The first two editions of Mastering Enterprise JavaBeans have become one of the two leading tutorials on EJB, with more than 75,000 copies sold. Its success was driven by the acknowledged quality of the book (just check out the reviews on and its authors. The Third Edition will continue in this tradition, covering the new EJB 2.1 specification, which was released with J2EE 1.4 in late 2003. This new edition is more than 30% revised, with 5 new chapters covering the latest features of this important release. In addition, the authors cover new ways that EJB is being used more effectively with popular open source solutions. The authors will maintain the basic organization of the previous two editions. Part One covers the fundamentals of building an EJB system. Part Two is devoted to programming with EJB. Part Three covers advanced EJB concepts and best practices, including transactions, persistence, clustering, integration, performance optimization, and choosing an EJB server. The appendixes cover EJB topics such as the Java Naming and Directory Interface (JNDI) and RMI-IIOP tutorials, CORBA interoperability, and the EJB Query Language.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
The first edition of Ed Roman's Mastering Enterprise JavaBeans earned raves from programmers worldwide for its clarity and practical approach to EJB development -- not easy to do well, nor an easy topic to cover well. But many developers have delayed purchasing the book because they knew an extensive update was on the way. Delay no more: Mastering Enterprise JavaBeans, Second Edition has arrived, and it's all you hoped it would be. EJB 2.0 made practical

First and foremost, it's been thoroughly updated to cover Enterprise JavaBeans 2.0 specification (the previous edition, while discussing EJB 1.1, was primarily focused on EJB 1.0, and a lot's changed since then -- for one thing, the 2.0 spec is triple the size of 1.0!).

Second, the book reflects more than Roman's immense experience (he runs The Middleware Company, which specializes in server-side Java training and consulting). It also reflects the knowledge of two new co-authors -- Scott Ambler, himself a highly-respected Java and object technology author, and Tyler Jewell, one of the world's leading experts in BEA WebLogic Server. Plus, this time around, the book was beta tested on the Web, where it benefited from the comments and contributions of hundreds of developers worldwide.

A technical book for technical readers, Mastering Enterprise JavaBeans, Second Edition delves exceptionally deeply into the realities of EJB development: the dos, the don'ts, the counterintuitive elements -- and the occasional big surprises.

After an exceptionally clear overview of EJB, its rationale, and where it can fit into your enterprise application development strategy, Roman & Co. walk you through creating your first bean, outlining an eight-step approach you can use in most EJB development. Even here, the book alerts you to some significant subtleties. For example, EJB defines two types of exceptions: system-level and application-level. Each is handled very differently: the authors illuminate the differences and offer specific, detailed rules of thumb for when to use each.

The book's "first bean" chapter concludes with a quick design strategy -- including a warning to avoid the beginner's temptation of implementing a component interface with your bean, and a solution that preserves compile-time checks of your method signatures even without a component interface.

The authors systematically review the development details involved in implementing EJB applications. Through detailed code examples, you'll learn how to work with session, entity, and message-driven beans, and each of their subtypes -- including stateless and stateful session beans, bean-managed entity beans that draw upon database APIs such as JDBC, and container-managed persistent entity beans, wherein the EJB container handles storage for you. Each of these chapters contain detailed charts and diagrams that summarize key explanations and implementation guidelines.

Next, you'll learn how to extend your beans' functionality by calling beans from other beans, customizing beans through environment properties, accessing resource factories such as JDBC or JMS drivers, and using the new Java Authentication and Authorization Service (JAAS) API to enforce security.

The second half of the book focuses on advanced middleware concepts and techniques that can help you dramatically improve the performance and robustness of your Web and distributed applications. For instance, using EJB, you can gain the predictability and reliability of transactions without writing code directly to a transaction API. While this higher-level programming has compelling advantages, it's still fraught with confusion; the authors do a masterful job of clearing things up.

There's an invaluable chapter on persistence best practices -- including when to use entity beans and when not to; how to choose between container-managed and bean-managed persistence; and a six-page chart outlining the most common legacy data problems you'll encounter, and what you'll need to do about them. If that's not enough for you, the next chapter brings together expert high-level EJB design strategies (stateful vs. stateless, messaging vs. RMI-IIOP, local vs. remote interfaces, guaranteeing response times, tuning performance, partitioning, reuse, the right roles for XML, and more).

The book concludes with a complete primer on managing EJB projects -- including techniques for determining when EJB is overkill. (The Gartner Group says companies overspent by $1 billion on EJB projects in 2000, when servlets and JSP would've been plenty). Nuggets like those will make you thank your lucky stars you bought this book. (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

From the Publisher
Mastering Enterprise JavaBeans, 2nd Ed. by Ed Roman and Scott Ambler includes the new EJB specification and expanded coverage on more advanced topics for developers. (Publishers Weekly)

"...the style is informal, with clear explanations…an enjoyable read and good value for money..." (Computer Bulletin, September 2002)

“…explains Enterprise Java Beans in such a great way that it is worth the price of the book by itself…excellent web site too…”(Cvu, April 2003)

Read More Show Less

Product Details

  • ISBN-13: 9780764576829
  • Publisher: Wiley
  • Publication date: 12/28/2004
  • Edition number: 3
  • Pages: 840
  • Sales rank: 1,554,449
  • Product dimensions: 7.40 (w) x 9.20 (h) x 1.73 (d)

Meet the Author

Ed Roman is an independent consultant, a leading authorityon EJB, and the author of the first two bestselling editions ofMastering Enterprise JavaBeans (Wiley).

Rima Patel Sriganesh is a member of Technical Staff inthe Technology Outreach group at Sun Microsystems, Inc., and is acoauthor of Developing Java Web Services (Wiley).

Gerald Brose is a Security Software Architect at XtradyneTechnologies. He is an expert in EJB and CORBA and the author ofJava Programming with CORBA, Third Edition (Wiley).

Read More Show Less

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's one-click order functionality, you can continue browsing the site without waiting to see if your credit card authorizes. Unless something goes wrong, 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....

Read More Show Less

Table of Contents



Part One: Overview.

Chapter 1: Overview.

Chapter 2: EJB Fundamentals.

Chapter 3: Writing Your First Bean.

Part Two: The Triad of Beans.

Chapter 4: Introduction to Session Beans.

Chapter 5: Writing Session Bean Web Services.

Chapter 6: Introduction to Entity Beans.

Chapter 7: Writing Bean-Managed Persistent Entity Beans.

Chapter 8: Writing Container-Managed Persistent EntityBeans.

Chapter 9: Introduction to Message-Driven Beans.

Chapter 10: Adding Functionality to Your Beans.

Part Three: Advanced Enterprise JavaBeans Concepts.

Chapter 11: EJB Best Practices.

Chapter 12: Transactions.

Chapter 13: Security.

Chapter 14: EJB Timers.

Chapter 15: BMP and CMP Relationships.

Chapter 16: Persistence Best Practices.

Chapter 17: EJB Integration.

Chapter 18: EJB Performance Optimizations.

Chapter 19: Clustering.

Chapter 20: Starting Your EJB Project on the Right Foot.

Chapter 21: Choosing an EJB Server.

Chapter 22: EJB-J2EE Integration: Building a CompleteApplication.

Appendix A: RMI-IIOP and JNDI Tutorial.

Appendix B: CORBA Interoperability.

Appendix C: Deployment Descriptor Reference.

Appendix D: The EJB Query Language (EJB-QL).

Appendix E: EJB Quick Reference Guide.


Read More Show Less


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 to share with others. Our goal is to increase our knowledge of EJB as a community, and together, we can do it.

Ed Roman

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)