This article provides a high-level introduction to J2EE. It is taken from chapter one of the book Beginning J2EE 1.4 From Novice to Professional, written by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004; ISBN: 1590593413).
J2EE Essentials - Enterprise JavaBeans (Page 5 of 7 )
Enterprise JavaBeans are to J2EE what Mickey Mouse is to Disney—it’s the flagship technology of the platform. When J2EE is mentioned, EJB is what immediately comes to mind. I mentioned earlier that J2EE is a whole lot more than EJB, but my intention isn’t to trivialize EJBs—the attention that the technology gets is certainly merited.
In order to better understand what EJBs are and do, it helps to start out with Java’s Remote Method Invocation (RMI). If you’re not already familiar with RMI, or if you need a quick overview or a refresher, you may want to refer to http://java.sun.com/rmi.
RMI is Java’s native means of allowing a Java object to run on one computer, and have its methods called by another object running on a separate computer across a network.
In order to create a remoted object with RMI, you’d first design an interface that extends the java.rmi.Remote interface. This interface defines the operations that you want to expose on your remoted object. The next step is to design the remoted object as a Java class that implements the interface you’ve defined. This class extends the java.rmi.server.UnicastRemoteObject class, which will provide the necessary network communications between this object and the objects that call it. Finally, you’d write an application that creates an instance of this class and registers that instance with the RMI registry. The registry is a simple lookup service that allows remote computers to find the remoted object using a name-based lookup. The same service is used by the client application, which requests a named object from the registry and casts it into the remoted interface designed in the first step.
What RMI provides is a bare-bones client-server implementation. It provides the basic stuff: a registry for lookup, the guts of network communication for invoking operations and passing parameters to and from remoted objects, and a basic mechanism for managing access to system resources as a safeguard against malicious code running on a remote computer.
RMI is lightweight, though. It’s not designed to satisfy the requirements of enterprise-class distributed applications. It lacks the essential infrastructure that enterprise-class applications rely on, such as security, transaction management, and scaleability. While it supplies base classes that provide networking, it doesn’t provide a framework for an application server that hosts your server-side business components and scales along with your application—you have to write the client and the server applications.
Enter Enterprise JavaBeans. EJBs are Java components that implement business logic. This allows the business logic of an application (or suite of applications) to be compartmentalized into EJBs and kept separate from the front-end applications that use that business logic.
The J2EE architecture includes a server that is a container for EJBs. The EJB container loads the bean as needed, invokes the exposed operations, applies security rules, and provides the transaction support for the bean. If it sounds to you like the EJB container does a lot of work, you’re right—the container provides all of the necessary plumbing and wiring needed for enterprise applications. As you’ll see in Chapter 7, building Enterprise JavaBeans follows the same basic steps as creating an RMI object, but since the EJB container provides all of the enterprise plumbing, you get to spend more time building your application and less time messing around with trying to shoehorn in services like security and transaction support.
Enterprise JavaBeans come in a few different flavors: session beans, entity beans, and message beans. Session beans, like the name implies, live only as long as the conversation or “session” between the client application and the bean lasts. The session bean’s primary reason for being is to provide application services, defined and designed by the application developer, to client applications. Depending on the design, a session bean may maintain state during the session (that is, it keeps its internal member variables’ values so it can maintain sort of a conversation with the client), or it may be “stateless,” meaning that it provides business rules through its exposed operations but doesn’t provide any sense of “state”—that responsibility is delegated to the client.
Entity beans represent business objects—such as customers, invoices, and products— in the application domain. These business objects are persisted so they can be stored and retrieved at will. The J2EE architecture provides a lot of flexibility for the persistence model that allows you to defer all of the work of storing and retrieving the bean’s state information to the container, or lets you control it all (very useful when you’re dealing with interfacing your J2EE system to a legacy application!).
The third type of EJB, the message bean, provides a component model for services that listen to Message Service messages. The J2EE platform includes a messaging queue that allows applications to post messages to a queue, as well as to “subscribe” to queues that get messages. The advantage to this particular way of doing things is that the sender and the receiver of the message really need know nothing about each other—they only need to know about the message queue itself.
One example use of a message queue is an automated stock trading system. Stock prices are sent as messages to a message queue, and things that are interested in stock prices consume those messages.
With message-driven EJBs, it is possible to create an EJB that responds to messages concerning stock prices and makes automatic trading decisions based on those messages.
You will learn a lot about the ins and outs of using session and entity beans in Chapter 7. Your J2EE applications will typically be comprised of both session and entity beans. Message beans will come later in the book—they’re not used as frequently as the other flavors in most applications, but they’re still pretty darn cool!
Extensible Markup Language (XML) is a significant cornerstone for building enterprise systems that provide interoperability and are resilient in the face of changes. There are several key technologies in J2EE that rely on XML for configuration and integration with other services.
J2EE provides a number of APIs for developers working with XML. Java API for XML Processing (JAXP) provides support for generating and parsing XML with both the Document Object Model (DOM), which is a tree-oriented model, and SAX (Simple API for XML), which is a stream-based event-driven processing model.
The Java API for XML Binding (JAXB) provides support for mapping XML to and from Java classes. It provides a compiler and a framework for performing the mapping so you don’t have to write custom code to perform those transformations.
The Java API for XML Registries (JAXR), Java API for XML Messaging (JAXM), and Java API for XML-based Remote Procedure Calls (JAX-RPC) round out the XML API provisions. These sets of APIs provide support for SOAP and web services (discussed in the following section).
This book assumes that you’ve got a basic familiarity with XML. If you need a refresher on XML, you might want to review Chapters 21 and 22 of Beginning Java 2 (Apress, ISBN 1-86100-569-5).