Enterprise beans are the J2EE components that implement Enterprise JavaBeans (EJB) technology. Enterprise beans run in the EJB container, a runtime environment within the J2EE server (see Figure 1-5). Although transparent to the application developer, the EJB container provides system-level services such as transactions to its enterprise beans. These services enable you to quickly build and deploy enterprise beans, which form the core of transactional J2EE applications.
What Is an Enterprise Bean?
Written in the Java programming language, an enterprise bean is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfills the purpose of the application. In an inventory control application, for example, the enterprise beans might implement the business logic in methods called checkInventoryLevel and orderProduct. By invoking these methods, remote clients can access the inventory services provided by the application.
Benefits of Enterprise Beans
For several reasons, enterprise beans simplify the development of large, distributed applications. First, because the EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container--not the bean developer--is responsible for system-level services such as transaction management and security authorization.
Second, because the beans--and not the clients--contain the application's business logic, the client developer can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, the clients are thinner, a benefit that is particularly important for clients that run on small devices.
Third, because enterprise beans are portable components, the application assembler can build new applications from existing beans. These applications can run on any compliant J2EE server.
When to Use Enterprise Beans
You should consider using enterprise beans if your application has any of the following requirements:
The application must be scalable. To accommodate a growing number of users, you may need to distribute an application's components across multiple machines. Not only can the enterprise beans of an application run on different machines, but their location will remain transparent to the clients.
Transactions are required to ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.
The application will have a variety of clients. With just a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.
Types of Enterprise Beans
Table 3-1 summarizes the three different types of enterprise beans. The following sections discuss each type in more detail.
Table 3-1 Summary of Enterprise Bean Types
Enterprise Bean Type
Purpose
Session
Performs a task for a client
Entity
Represents a business entity object that exists in persistent storage
Message-Driven
Acts as a listener for the Java Message Service API, processing messages asynchronously
What Is a Session Bean? A session bean represents a single client inside the J2EE server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.
As its name suggests, a session bean is similar to an interactive session. A session bean is not shared--it may have just one client, in the same way that an interactive session may have just one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client.
For code samples, see Chapter 4[/url].
State Management Modes There are two types of session beans: stateful and stateless.
Stateful Session Beans The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts ("talks") with its bean, this state is often called the conversational state.
The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends there is no need to retain the state.
Stateless Session Beans A stateless session bean does not maintain a conversational state for a particular client. When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.
Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
At times, the EJB container may write a stateful session bean to secondary storage. However, stateless session beans are never written to secondary storage. Therefore, stateless beans may offer better performance than stateful beans.
When to Use Session Beans In general, you should use a session bean if the following circumstances hold:
At any given time, only one client has access to the bean instance.
The state of the bean is not persistent, existing only for a short period of time (perhaps a few hours).
Stateful session beans are appropriate if any of the following conditions are true:
The bean's state represents the interaction between the bean and a specific client.
The bean needs to hold information about the client across method invocations.
The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
Behind the scenes, the bean manages the work flow of several enterprise beans. For an example, see the AccountControllerEJB session bean in Chapter [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/Ebank.html#87559]18.[/url]
To improve performance, you might choose a stateless session bean if it has any of these traits:
The bean's state has no data for a specific client.
In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an e-mail that confirms an online order.
The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month.
What Is an Entity Bean? An entity bean represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products. In the J2EE SDK, the persistent storage mechanism is a relational database. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table. For code examples of entity beans, please refer to chapters [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/BMP.html#80663]5 and 6[/url].
What Makes Entity Beans Different from Session Beans? Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, have primary keys, and may participate in relationships with other entity beans.
Persistence Because the state of an entity bean is saved in a storage mechanism, it is persistent. Persistence means that the entity bean's state exists beyond the lifetime of the application or the J2EE server process. If you've worked with databases, you're familiar with persistent data. The data in a database is persistent because it still exists even after you shut down the database server or the applications it services.
There are two types of persistence for entity beans: bean-managed and container-managed. With bean-managed persistence, the entity bean code that you write contains the calls that access the database. If your bean has container-managed persistence, the EJB container automatically generates the necessary database access calls. The code that you write for the entity bean does not include these calls. For additional information, see the section [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/EJBConcepts4.html#62950]Container-Managed Persistence.
Shared Access Entity beans may be shared by multiple clients. Because the clients might want to change the same data, it's important that entity beans work within transactions. Typically, the EJB container provides transaction management. In this case, you specify the transaction attributes in the bean's deployment descriptor. You do not have to code the transaction boundaries in the bean--the container marks the boundaries for you. See Chapter 14[/url] for more information.
Primary Key Each entity bean has a unique object identifier. A customer entity bean, for example, might be identified by a customer number. The unique identifier, or primary key, enables the client to locate a particular entity bean. For more information see the section [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/BMP5.html#63579]Primary Keys for Bean-Managed Persistence.
Relationships Like a table in a relational database, an entity bean may be related to other entity beans. For example, in a college enrollment application, StudentEJB and CourseEJB would be related because students enroll in classes.
You implement relationships differently for entity beans with bean-managed persistence and those with container-managed persistence. With bean-managed persistence, the code that you write implements the relationships. But with container-managed persistence, the EJB container takes care of the relationships for you. For this reason, relationships in entity beans with container-managed persistence are often referred to as container-managed relationships.
Container-Managed Persistence The term container-managed persistence means that the EJB container handles all database access required by the entity bean. The bean's code contains no database access (SQL) calls. As a result, the bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility, even if you redeploy the same entity bean on different J2EE servers that use different databases, you won't need to modify or recompile the bean's code. In short, your entity beans are more portable.
In order to generate the data access calls, the container needs information that you provide in the entity bean's abstract schema.
Abstract Schema Part of an entity bean's deployment descriptor, the abstract schema defines the bean's persistent fields and relationships. The term abstract distinguishes this schema from the physical schema of the underlying data store. In a relational database, for example, the physical schema is made up of structures such as tables and columns.
You specify the name of an abstract schema in the deployment descriptor. This name is referenced by queries written in the Enterprise JavaBeans Query Language ("EJB QL"). For an entity bean with container-managed persistence, you must define an EJB QL query for every finder method (except findByPrimaryKey). The EJB QL query determines the query that is executed by the EJB container when the finder method is invoked. To learn more about EJB QL, see Chapter 8[/url].
You'll probably find it helpful to sketch the abstract schema before writing any code. [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/EJBConcepts4.html#79633]Figure 3-1 represents a simple abstract schema that describes the relationships between three entity beans. These relationships are discussed further in the sections that follow.
Figure 3-1 A High-Level View of an Abstract Schema
Persistent Fields The persistent fields of an entity bean are stored in the underlying data store. Collectively, these fields constitute the state of the bean. At runtime, the EJB container automatically synchronizes this state with the database. During deployment, the container typically maps the entity bean to a database table and maps the persistent fields to the table's columns.
A CustomerEJB entity bean, for example, might have persistent fields such as firstName, lastName, phone, and emailAddress. In container-managed persistence, these fields are virtual. You declare them in the abstract schema, but you do not code them as instance variables in the entity bean class. Instead, the persistent fields are identified in the code by access methods (getters and setters).
Relationship Fields A relationship field is like a foreign key in a database table--it identifies a related bean. Like a persistent field, a relationship field is virtual and is defined in the enterprise bean class with access methods. But unlike a persistent field, a relationship field does not represent the bean's state. Relationship fields are discussed further in Direction in Container-Managed Relationships.
Multiplicity in Container-Managed Relationships There are four types of multiplicities:
One-to-one: Each entity bean instance is related to a single instance of another entity bean. For example, to model a physical warehouse in which each storage bin contains a single widget, StorageBinEJB and WidgetEJB would have a one-to-one relationship.
One-to-many: An entity bean instance may be related to multiple instances of the other entity bean. A sales order, for example, can have multiple line items. In the order application, OrderEJB would have a one-to-many relationship with LineItemEJB.
Many-to-one: Multiple instances of an entity bean may be related to a single instance of the other entity bean. This multiplicity is the opposite of a one-to-many relationship. In the example mentioned in the previous item, from the perspective of LineItemEJB the relationship to OrderEJB is many-to-one.
Many-to-many: The entity bean instances may be related to multiple instances of each other. For example, in college each course has many students, and every student may take several courses. Therefore, in an enrollment application, CourseEJB and StudentEJB would have a many-to-many relationship.
Direction in Container-Managed Relationships The direction of a relationship may be either bidirectional or unidirectional. In a bidirectional relationship, each entity bean has a relationship field that refers to the other bean. Through the relationship field, an entity bean's code can access its related object. If an entity bean has a relative field, then we often say that it "knows" about its related object. For example, if OrderEJB knows what LineItemEJB instances it has and if LineItemEJB knows what OrderEJB it belongs to, then they have a bidirectional relationship.
In a unidirectional relationship, only one entity bean has a relationship field that refers to the other. For example, LineItemEJB would have a relationship field that identifies ProductEJB, but ProductEJB would not have a relationship field for LineItemEJB. In other words, LineItemEJB knows about ProductEJB, but ProductEJB doesn't know which LineItemEJB instances refer to it.
EJB QL queries often navigate across relationships. The direction of a relationship determines whether a query can navigate from one bean to another. For example, a query can navigate from LineItemEJB to ProductEJB, but cannot navigate in the opposite direction. For OrderEJB and LineItemEJB, a query could navigate in both directions, since these two beans have a bidirectional relationship.
When to Use Entity Beans You should probably use an entity bean under the following conditions:
The bean represents a business entity, not a procedure. For example, CreditCardEJB would be an entity bean, but CreditCardVerifierEJB would be a session bean.
The bean's state must be persistent. If the bean instance terminates or if the J2EE server is shut down, the bean's state still exists in persistent storage (a database).
What Is a Message-Driven Bean?
Note: This section contains text from The Java Message Service Tutorial. Because message-driven beans rely on Java Message Service (JMS) technology, to fully understand how these beans work you should consult the tutorial at this URL:http://java.sun.com/products/jms/tutorial/index.html
A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component--an application client, another enterprise bean, or a Web component--or by a JMS application or system that does not use J2EE technology.
Message-driven beans currently process only JMS messages, but in the future they may be used to process other kinds of messages.
For a code sample, see Chapter 7[/url].
What Makes Message-Driven Beans Different from Session and Entity Beans? The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. Interfaces are described in the section [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/EJBConcepts6.html#62983]Defining Client Access with Interfaces. Unlike a session or entity bean, a message-driven bean has only a bean class.
In several respects, a message-driven bean resembles a stateless session bean.
A message-driven bean's instances retain no data or conversational state for a specific client. All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently. A single message-driven bean can process messages from multiple clients. The instance variables of the message-driven bean instance can contain some state across the handling of client messages--for example, a JMS API connection, an open database connection, or an object reference to an enterprise bean object.
When a message arrives, the container calls the message-driven bean's onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application's business logic. The onMessage method may call helper methods, or it may invoke a session or entity bean to process the information in the message or to store it in a database.
A message may be delivered to a message-driven bean within a transaction context, so that all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered. For more information, see Chapter 7[/url].
When to Use Message-Driven Beans Session beans and entity beans allow you to send JMS messages and to receive them synchronously, but not asynchronously. To avoid tying up server resources, you may prefer not to use blocking synchronous receives in a server-side component. To receive messages asynchronously, use a message-driven bean.
The Contents of an Enterprise Bean To develop an enterprise bean, you must provide the following files:
Deployment descriptor: An XML file that specifies information about the bean such as its persistence type and transaction attributes. The deploytool utility creates the deployment descriptor when you step through the New Enterprise Bean wizard.
Enterprise bean class: Implements the methods defined in the following interfaces.
Interfaces: The remote and home interfaces are required for remote access. For local access, the local and local home interfaces are required. See the section [url=http://dev.csdn.net/mk:@MSITStore:E:毕业设计论文j2ee-tutorials.chm::/j2ee-tutorials/j2ee_tutorial/doc/EJBConcepts6.html#62983]Defining Client Access with Interfaces. (Please note that these interfaces are not used by message-driven beans.)
Helper classes: Other classes needed by the enterprise bean class, such as exception and utility classes.
You package the files in the preceding list into an EJB JAR file, the module that stores the enterprise bean. An EJB JAR file is portable and may be used for different applications. To assemble a J2EE application, you package one or more modules--such as EJB JAR files--into an EAR file, the archive file that holds the application. When you deploy the EAR file that contains the bean's EJB JAR file, you also deploy the enterprise bean onto the J2EE server.
Naming Conventions for Enterprise Beans Because enterprise beans are composed of multiple parts, it's useful to follow a naming convention for your applications. Table 3-2 summarizes the conventions for the example beans of this tutorial.
Table 3-2 Naming Conventions for Enterprise Beans
Item
Syntax
Example
Enterprise bean name (DD)
<name>EJB
AccountEJB
EJB JAR display name (DD)
<name>JAR
AccountJAR
Enterprise bean class
<name>Bean
AccountBean
Home interface
<name>Home
AccountHome
Remote interface
<name>
Account
Local home interface
Local<name>Home
LocalAccountHome
Local interface
Local<name>
LocalAccount
Abstract schema (DD)
<name>
Account
DD means that the item is an element in the bean's deployment descriptor.
About this documentThis document is built from the HTML documentations available at java.sun.com. It is regularly updated, when new versions of original documentations become available. To download updates and many other WinHelp and HTMLHelp Java documentations for free, visit Franck Allimant's web site:
http://www.confluent.fr/javadoc/indexe.html (in English)
http://www.confluent.fr/javadoc (in French)
