Enterprise JavaBeans (EJB) are Java components that implement business logic. The container interposes system services for the EJBs, so that the developer does not have to worry about implementing such things as database access, transaction support, security, caching, and concurrency. This functionality is the responsibility of the EJB container.
An enterprise bean consists of interfaces and classes. Clients access enterprise bean methods through the home and remote interfaces of the bean. The home interface provides methods for creating, removing, and locating the enterprise bean, and the remote interface provides the business methods. At deployment time, the container creates classes from these interfaces that it uses to provide access to clients seeking to create, remove, locate, and call business methods on the enterprise bean.
The types of enterprise beans are session beans, entity beans, and message driven beans.
Session Beans
A session bean represents a transient conversation with a client and might execute database reads and writes. A session bean might invoke JDBC calls, or it might use an entity bean to make the call. In this case, the session bean is a client to the entity bean. The fields of a session bean contain the state of the conversation and are transient. If the server or client crashes, the session bean is lost. Session beans can be stateful or stateless.
■ Stateless Session Beans: Stateless session beans do not have any state information for a specific client. They typically provide server-side behavior that does not maintain any particular state. Stateless session beans require fewer system resources. A business object that provides a generic service is a good candidate for a stateless session bean.
■ Stateful Session Beans: A stateful session bean contains conversational state on behalf of the client. Therefore, there is one stateful session bean instance for each client. The conversational state is the instance field values of the session
Overview of J2EE APIs and OC4J Support
bean, plus all objects reachable from the session bean's fields. Stateful session beans do not represent data in a persistent data store, but they can access and update data on behalf of the client.
Entity Beans
An entity bean is a business entity that represents data in a database, and the
methods to act on that data. Entity beans are transactional and long-lived: as long as the data remains in the database, the entity bean exists. Entity beans can support either Container-Managed or Bean-Managed Persistence.
■ Container Managed Persistence (CMP): With CMP, an application developer does not need to programmatically map the entity bean to the persistent store, because the EJB container transparently maps and manages the interaction with the persistent store. As a result, an entity bean using CMP does not require the developer to use JDBC 2.0 APIs for database access. Thus, CMP is simpler and easier to use; however, it limits the application developer’s control of the interaction between the application and the database.
■ Bean Managed Persistence (BMP): In contrast, BMP is used by developers who want to control the way an enterprise bean stores and reads state from the persistent store. BMP is more complex than CMP, because the application developer implements the persistence methods. It uses the JDBC 2.0 API code to handle loading and storing data and maintaining consistency between the runtime and persistent database storage. You should use BMP when you want control over how the persistent data is stored and when the data is backed up to the persistence store. In addition, a BMP bean is easier to deploy as it does not require any Object-Relational (O-R) mapping in the deployment descriptor.
Message-Driven Beans
OC4J supports Message-Driven Beans (MDB) that are a part of the EJB 2.0 specification. An MDB models a long-running process, invoked asynchronously.
The client posts a message to a JMS queue or topic. The message is captured by the EJB container and routed to the intended MDB. At this point, the MDB can execute the request or forward the request to another EJB.
OC4J EJB Support
OC4J provides an EJB container that provides the following:
■ Support for EJB 1.1 and 2.0: The OC4J EJB Container provides full support for session beans, entity beans, and message-driven beans. In addition, it supports
Overview of J2EE APIs and OC4J Support
Bean Managed Persistence (BMP), Container Managed Persistence (CMP), and O-R mapping.
■ Container Managed Persistence (CMP) and Bean Managed Persistence (BMP) Implementations: OC4J provides CMP and BMP for entity beans supporting object-relational mapping (O-R). OC4J supports one-to-one and one-to-many object-relational mappings. OC4J contains the following features:
■ Simple O-R Mapping: A facility to automatically map fields of an entity bean to a corresponding database table. Additionally, users can specify O-R mappings between EJBs. These mappings are only for simple, primitive, and serializable objects.
■ Complex O-R Mappings: A common problem is the difficulty of mapping anything, except for a simple bean with simple fields, to a database table without writing custom code to do the mapping. OC4J includes an O-R mapping system that allows complex object models to be mapped to database tables. It allows practical object models to use CMP. Specifically, it allows the following types of fields to be mapped within entity beans:
* simple objects and primitives—INT or CHAR
* objects—compound objects
* serializable objects—compound objects that can be serialized and stored in BLOBs and CLOBs
* entity references—references to another entity bean
* collections
Further, it provides an isolation layer that captures the SQL that is
automatically code-generated, allowing the CMP facilities to target Oracle and non-Oracle databases.
■ Toplink certification for CMP O-R mapping.
■ Dynamic EJB Stub Generation: An application developer does not need to pre-compile EJB stubs usingejbc,rmic, or other such facilities into the client application. Rather, the OC4J EJB container generates EJB stubs on demand as it needs them. This makes application and system maintenance significantly simpler than competitor products.
■ Full EAR File-Based Deployment: OC4J provides tools to do the following:
– Deploy the EAR file, using a deployment tool, to one or more OC4J instances. This tool supports cluster deployment.
Overview of J2EE APIs and OC4J Support
■ Simplified and Automatic Deployment of EJB Applications: In J2EE applications, there are two kinds of deployment descriptors, or module-configuration files: the generic J2EE deployment files that all application servers support and vendor-specific ones.
OC4J supports Application Server-specific deployment information in the following ways:
■ Auto-Deployment: The Oracle-specific deployment information is automatically generated when the EAR file is deployed on the server.
■ Simplified Configuration Customizing: Any Oracle-specific configuration information can be customized by manually editing a set of XML
configuration files, which capture Application Server-specific deployment and configuration information. These include settings for auto-create and auto-delete tables for CMP, security role mappings, JNDI namespace access, session persistence and time-out settings, transaction-retry settings, CMP and O-R mappings, buffering, character sets, locales, virtual directories, cluster configuration, session-tracking, and development and debugging mode settings.
■ Hot Deployment: When an application developer changes an EJB module that has already been deployed, the developer does not need to redeploy the EJB or restart the server. The user edits theserver.xml configuration file. Afterward, the server reads the file and automatically picks up the changes.
See the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer’s Guide and Reference for more information on using and configuring EJBs in OC4J.