These sections discuss design options for WebLogic Server Enterprise Java Beans (EJBs), bean behaviors to consider during the design process, and recommended design patterns.
It is assumed the reader is familiar with Java programming, EJB 2.x, and the features described in WebLogic Server Value-Added EJB Features.
After finalizing your bean design, refer to programming and other implementation topics in Implementing Enterprise Java Beans.
When you choose the bean type for a processing task, consider the different natures and capabilities of the various bean types.
Bean types vary in terms of the bean’s relationship with its client. Some bean types stick with a client throughout a series of processes, serving as a sort of general contractor—acquiring and orchestrating services for the client. There are other bean types that act like subcontractors, they deliver the same single function to multiple client-oriented general contractor beans. A client-oriented bean keeps track of client interactions and other information associated with the client process, throughout a client session—a capability referred to as maintaining state. Beans that deliver commodity services to multiple client-oriented beans do not maintain state.
The following sections describe the client interaction and state management characteristics of each bean type.
|Note:||For a basic overview of each bean type, including an example of a business process to which each bean type is well suited, see How Do Applications Use EJBs?.|
A session bean represents a single client inside the 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.
A session bean instance has a single client. Session beans are not persistent—when the client terminates, its session bean appears to terminate and is no longer associated with the client.
A session bean can be used as a facade, between Web applications and entity beans to contain complex interactions and reduce RMI calls. When a client application accesses a remote entity bean directly, each getter method is a remote call. A session facade bean can access the entity bean locally, collect the data in a structure, and return it by value. The two types of session beans, those that maintain state and those that do not, are described in the following sections.
Stateful session beans support conversational services with tightly-coupled clients. A stateful session bean accomplishes a task for a particular client. It maintains state for the duration of a client session. After session completion, state is not retained.
Stateful session beans are instantiated on a per client basis, and can multiply and consume resources rapidly.
Like a stateful session bean, a stateless session bean performs a task for a particular client. Unlike a stateful session bean, stateless session beans do not maintain client state. A stateless session bean may maintain state only for the duration of a method 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 request. When a home interface creates a stateless bean, it returns a replica-aware stub that can route to any server where the bean is deployed. Because a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean.
Because stateless session beans are never written to secondary storage, they typically offer better performance than stateful beans.
For applications that require large numbers of clients, stateless session beans offer better scalability than stateful session beans.
The system overhead of creating an instance is less for a stateless session bean than for a stateful session bean.
You can typically support more clients with a stateless session bean than a stateful session bean. A stateless session bean instance is only reserved for the duration of a single client request, while a stateful session bean is reserved for the duration of a session.
The number of stateless session bean instances required is usually roughly equivalent to the number of threads in the server execute queue—in the order of hundreds, while the number of stateful session bean instances required corresponds more closely to the number of clients of the application—which for some applications may be hundreds of thousands.
In this release of WebLogic Server, you can expose stateless session beans as Web Services through the Web service endpoint interface. For more information, see Getting Started With WebLogic Web Services Using JAX-RPC.
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.
These are the key features of entity beans:
ejb-jar.xmlfile that control how transactions are managed. You do not have to code the transaction boundaries in the bean—the container marks the boundaries for you. For information about transaction management, see .
WebLogic Server supports two types of entity beans: read-write and read-only.
Read-only beans perform better than read-write beans, because they reduce the number of times that data is read from the database.
Some applications require the use of read-write entity beans—the choice depends on frequency of updates and data consistency requirements. Table 3-1 provide key guidelines.
These sections describe approaches for choosing the entity bean implementation, based on your requirements for performance and data consistency.
Read-only entity beans are recommended whenever stale data is tolerable—they are suitable for product catalogs and the majority of content within many applications. Primary key-based reads are performed against a local entity cache that is invalided on a timer basis. Other queries are made against the database. Read-only entity beans perform three to four times faster than transactional entities.
|Note:||A client can successfully call setter methods on a read-only entity bean; however, the data will never be moved into the persistent store.|
Read-write entity beans are recommended for applications that require high data consistency, for example, customer account maintenance. All reads and writes are performed against the database.
|Note:||For entity beans that use bean-managed persistence, or EJB 1.1 entity beans that use container-managed persistence, you can reduce the number of database writes by specifying the
For read-mostly applications, characterized by frequent reads, and occasional updates (for instance, a catalog)—a combination of read-only and read-write beans that extend the read-only beans is suitable. The read-only bean provides fast, weakly consistent reads, while the read-write bean provides strongly consistent writes.
To avoid the overhead imposed by remote calls, avoid accessing remote EJB entity beans from client or servlet code. Instead, use a session bean, referred to as a facade, to contain complex interactions and reduce calls from Web applications to RMI objects. When a client application accesses a remote entity bean directly, each getter method is a remote call. A session facade bean can access the entity bean locally, collect the data in a structure, and return it by value.
Alternatively, there are no disadvantages to accessing a local entity bean instance directly from the Web tier—it is preferable to do so than to use a facade.
Avoid the use of transfer objects, also referred to as value objects or helper classes. (A transfer object is a serializable class within an EJB that groups related attributes, forming a composite value, which is used as the return type of a remote business method.)
To optimize performance, accessing local entity instances is always preferable to the use of transfer objects.
A message-driven bean (MDB) is an enterprise bean that allows J2EE applications to process messages asynchronously. An MDB acts as a JMS or JCA 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 non-J2EE applications.
These are the key features of message-driven beans:
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 re-delivered.
For information about design alternatives for message-driven beans, see MDBs and Messaging Models.
Persistence management strategy determines how an entity bean’s database access is performed.
Configure the persistence management strategy—either container-managed or bean-managed—for an entity bean in the
persistence-type element in
|Note:||You can specify the use of a third-party persistence service for entity beans that use container-managed persistence in the
A CMP bean relies upon the EJB container for all database interaction. The bean does not contain code that accesses the database. Instead, the EJB container generates the database access methods, based on information about the entity bean’s persistent fields and relationships, in
weblogic-cmp-jar.xml. For more information, see
CMP beans use EJB QL for database access. See EJB Query Language (EJB-QL) and WebLogic Server.
Container-managed persistence offers these advantages:
|Note:||If you redeploy a bean that uses features that are not supported by the target application server, changes to the bean code might be necessary.|
For more information on features supported by CMP entities, see Entity EJBs.
A bean that manages its own persistence must contain the methods that perform data access.
BMP is not encouraged—CMP offers many advantages over bean-managed persistence, as described in Use Container-Managed Persistence (CMP) for Productivity and Portability.
However, some application requirements cannot be satisfied by CMP beans. For instance, you must use BMP if:
A transaction is a unit of work that changes application state—whether on disk, in memory or in a database—that, once started, is completed entirely, or not at all.
Transactions can be demarcated—started, and ended with a commit or rollback—by the EJB container, by bean code, or by client code.
Transactions are costly application resources, especially database transactions, because they reserve a network connection for the duration of the transaction. In a multi-tiered architecture—with database, application server, and Web layers—you optimize performance by reducing the network traffic “round trip.” The best approach is to start and stop transactions at the application server level, in the EJB container.
Container-managed transactions (CMTs) are supported by all bean types: session, entity, and message-driven. They provide good performance, and simplify development because the enterprise bean code does not include statements that begin and end the transaction.
Each method in a CMT bean can be associated with a single transaction, but does not have to be. In a container-managed transaction, the EJB container manages the transaction, including start, stop, commit, and rollback. Usually, the container starts a transaction just before a bean method starts, and commits it just before the method exits.
For information about the elements related to transaction management in
weblogic-ejb-jar.xml, see Container-Managed Transactions Elements.
If an exception is thrown during a transaction, the container will automatically roll back the transaction. You can configure the EJB container to automatically retry container-managed transactions that have rolled back, provided the transactions did not roll back as the result of system exception-based errors. You can also explicitly program rollbacks in your bean. For more information see Implementing Enterprise Java Beans.
You control how the EJB container manages the transaction boundaries when delegating a method invocation to an enterprise bean's business method for different invocation scenarios, with the
trans-attribute element in
For example, if the client calling a transaction is itself running in a transaction, the
trans-attribute element for the called transaction determines whether it will run in a new transaction or within the calling transaction.
A single database transaction can span multiple beans, on multiple servers instances. For information about implementing transactions that involve more than one bean, see Programming Transactions That Are Distributed Across EJBs.
Transactions that update multiple datastores must commit or roll back as a logical unit. The two-phase commit protocol is a method of coordinating a single transaction across multiple resource managers to ensure that updates are committed in all participating databases, or are fully rolled back out of all the databases.
Two-phase commit is resource-intensive. Avoid distributing transactions across databases.
In a bean-managed transaction, the EJB code manages the transaction, including start, stop, commit, and rollback. Bean-managed transactions are supported by all session and message-driven beans; you cannot use bean-managed transactions with entity beans.
|Notes:||Bean-managed transactions cannot use container-provided transaction management features. Do not combine bean-managed and container-managed transactions in the same bean.|
These are examples of requirements that may dictate the use of bean-managed transactions:
Try to avoid this practice, because it requires detailed information about the workings of the EJB object. However, if this scenario is required, you must use bean-managed transaction coordination, and you must coordinate client calls to the respective methods.
To simplify development, and improve reliability, keep bean-managed transactions reasonably short.
For information about implementing bean-managed transactions, see Programming Bean-Managed Transactions.
Client applications are subject to interruptions or unexpected terminations. If you start and stop a transaction at the client level, you risk:
Do not manage transactions in client applications unless there are overriding reasons to do so.
A transaction’s isolation level is the degree to which it exposes updated but uncommitted data to other transactions. Allowing access to uncommitted data can improve performance, but increases the risk of incorrect data being supplied to other transactions.
Set the isolation level for bean-managed transactions in the bean’s Java code. For instructions, see Programming Bean-Managed Transactions.
Set the isolation level for container-managed transactions in the
isolation-level sub-element of the
transaction-isolation element of
weblogic-ejb-jar.xml. WebLogic Server passes this value to the underlying database. The behavior of the transaction depends both on the EJB’s isolation level setting and the concurrency control of the underlying persistent store.
For more information on setting container-managed transaction isolation levels, see Programming WebLogic JTA.
WebLogic Server offers a variety of value-added features for enterprise beans that you can configure to meet the requirements of your application. They are described in WebLogic Server Value-Added EJB Features.
Table 3-2 cross references requirement types with topics that describe design strategies and WebLogic Server features you can use to satisfy your application requirements.