Mastering Enterprise JavaBeans

Mastering Enterprise JavaBeans

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

The much-anticipated second edition of one of the most influential EJB books in the industry.

Get ready to jumpstart your Enterprise JavaBeans (EJB) development! Renowned EJB authority Ed Roman and his expert team have taken the bestselling first edition of this book and updated it to cover EJB 2.0. The new edition covers the basics of EJB, plus tougher advanced

See more details below

Overview

The much-anticipated second edition of one of the most influential EJB books in the industry.

Get ready to jumpstart your Enterprise JavaBeans (EJB) development! Renowned EJB authority Ed Roman and his expert team have taken the bestselling first edition of this book and updated it to cover EJB 2.0. The new edition covers the basics of EJB, plus tougher advanced concepts , showing you both the good and bad in building real-world EJB applications. You'll learn about such exciting topics as EJB design strategies, EJB relationships, and persistence best practices. And all you need to know to get started with this book is Java! There are also tutorials on RMI-IIOP and JNDI.

With this book, you'll learn:

  • The new EJB 2.0 standard
  • How to architect EJB systems,
  • When to use messaging, when to use state, when to use container-managed persistence, and when to use entity beans
  • How to design, implement, and deploy a real-world e-commerce system that uses JSPs and servlets with EJBs
  • Advanced concepts that you can't find elsewhere, such as clustering, design strategies, and complex persistence

Read More

Editorial Reviews

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)

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)

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....

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >