An enterprise bean is a non-visual component of a distributed, transaction-oriented enterprise application. Enterprise beans are typically deployed in EJB containers and run on EJB servers. You can customize them by changing their deployment descriptors and you can assemble them with other beans to create new applications. There are three types of enterprise beans: session beans, entity beans, and message-driven beans.
Session beans: Session beans are non-persistent enterprise beans. They can be stateful or stateless. A stateful session bean acts on behalf of a single client and maintains client-specific session information (called conversational state) across multiple method calls and transactions. It exists for the duration of a single client/server session. A stateless session bean, by comparison, does not maintain any conversational state. Stateless session beans are pooled by their container to handle multiple requests from multiple clients.
Entity beans: Entity beans are enterprise beans that contain persistent data and that can be saved in various persistent data stores. Each entity bean carries its own identity. Entity beans that manage their own persistence are called bean-managed persistence (BMP) entity beans. Entity beans that delegate their persistence to their EJB container are called container-managed persistence (CMP) entity beans.
Message-driven beans: Message-driven beans are enterprise beans that receive and process JMS messages. Unlike session or entity beans, message-driven beans have no interfaces. They can be accessed only through messaging and they do not maintain any conversational state. Message-driven beans allow asynchronous communication between the queue and the listener, and provide separation between message processing and business logic.
Remote client view
The remote client view specification became available beginning with EJB 1.1. The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.
Remote interface: The remote interface specifies the remote business methods that a client can call on an enterprise bean.
Remote home interface: The remote home interface specifies the methods used by remote clients for locating, creating, and removing instances of enterprise bean classes.
Local client view
The local client view specification is available in EJB 2.0 or later. Unlike the remote client view, the local client view of a bean is location dependent. Local client view access to an enterprise bean requires both the local client and the enterprise bean that provides the local client view to be in the same JVM. The local client view therefore does not provide the location transparency provided by the remote client view. Local interfaces and local home interfaces provide support for lightweight access from enterprise bean that are local clients. Session and entity beans can be tightly couple with their clients, allowing access without the overhead typically associated with remote method calls.
Local interface: The local interface is a lightweight version of the remote interface, but for local clients. It includes business logic methods that can be called by a local client.
Local home interface: The local home interface specifies the methods used by local clients for locating, creating, and removing instances of enterprise bean classes.
Web service client view
In the EJB 2.1 specification, the EJB architecture introduced the support for Web services. A client for a session bean can be a Web service client. A Web service client can make use of the Web service client view of a stateless session bean, which has a corresponding service endpoint interface.
Service endpoint interface
The service endpoint interface for a stateless session bean exposes the functionality of the session bean as a Web service endpoint. The Web Service Description Language (WSDL) document for a Web service describes the Web service as a set of endpoints operating on messages. A WSDL document can include the service endpoint interface of a stateless session bean as one of its endpoints. An existing stateless session bean can be modified to include a Web service client view, or a service endpoint interface can be mapped from an existing WSDL to provide the correct interface.
A Web service client view is independent of location and can be accessed through remote calls.
EJB client JAR file
An EJB client JAR file is an optional JAR file that can contain the client interfaces that a client program needs to use the client views of the enterprise beans that are contained in the EJB JAR file. If you decide not to create an EJB client JAR file for an EJB module, all of the client interface classes will be in the EJB JAR file. By default, the workbench creates EJB client JAR projects for each corresponding EJB project.
An EJB container is a runtime environment that manages one or more enterprise beans. The EJB container manages the life cycles of enterprise bean objects, coordinates distributed transactions, and implements object security. Generally, each EJB container is provided by an EJB server and contains a set of enterprise beans that run on the server.
A deployment descriptor is an XML file packaged with the enterprise beans in an EJB JAR file or an EAR file. It contains metadata describing the contents and structure of the enterprise beans, and runtime transaction and security information for the EJB container.
An EJB server is a high-level process or application that provides a runtime environment to support the execution of server applications that use enterprise beans. An EJB server provides a JNDI-accessible naming service, manages and coordinates the allocation of resources to client applications, provides access to system resources, and provides a transaction service. An EJB server could be provided by, for example, a database or application server.
EJB development resources
EJB modules are displayed in the Project Explorer view of the J2EE perspective, and they correspond to EJB projects.
An EJB module is used to assemble one or more enterprise beans into a single deployable unit. An EJB module is developed in an EJB project, and it can be exported as either a standalone EJB JAR file, or it can be combined with other EJB or Web modules within an enterprise application. An EJB JAR file uses the format of a standard Java archive file. An EJB module contains the following:
One or more enterprise beans and their associated .class and .java files.
Graphics and other files depending on the need of the enterprise bean.
A deployment descriptor. The file type for the deployment descriptor is Extensible Markup Language (XML). This file declares the contents of the EJB module, defines the structure of the beans in the module, and provides a description of how the beans are to be used at run time.
a MANIFEST.MF file in the META-INF directory. The manifest file can contain a class path entry, with references to other JAR files or EJB modules in a J2EE enterprise application. It defines the module's external dependencies.
IBM extensions to the standard deployment descriptor, if the target runtime container is WebSphere Application Server.
An EJB module is installed and runs in an EJB container.
An enterprise bean is a Java component that can be combined with other resources to create distributed client/server applications.
Note: If you choose to create an EJB client JAR file for your EJB module, the client interface classes for the enterprise beans will not be included in the EJB JAR file, but are included in the EJB client JAR file.
In the workbench, you create and maintain resources for enterprise applications in projects. An EJB project is a logical module that allows you to organize your enterprise beans. In the Project Explorer view, an EJB project is shown as an EJB module.
The workbench supports EJB 1.1, EJB 2.0, and EJB 2.1 projects. The J2EE specification level of a containing EAR project must be set to J2EE 1.3 or higher for EJB 2.0 projects, and J2EE 1.4 for EJB 2.1 projects. In an EJB 1.1 project, you will only be able to create EJB 1.1 beans.
An EJB project is a specialized Java project. The source and the output files of the project are located in the ejbModule folder. As you make changes and generate deployment code, the Java classes are compiled into the ejbModule folder. You cannot use the EJB project as the source folder; doing so will cause errors.
The imported classes are located in the imported_classes folder. The folder is only created when no source exists for any .class file in an imported JAR file, and only .class files for which no source exists are added to the folder. Whenever the project is built, the classes from the imported_classes folder are copied to the ejbModule folder. If you later add source for an imported class, the .class file in the imported_classes folder will be ignored; however, you should delete the .class file when the .java file is added.
Note: If you choose to create an EJB client JAR file for your EJB module, the client interface classes for the enterprise beans will not be included in the EJB project, but in separate EJB client JAR project. EJB client JAR projects are displayed in the Project Explorer as Java projects under the Other projects node.
EJB client projects
The EJB tooling supports the creation of EJB client JAR projects for EJB modules. An EJB client JAR project contains all the interface classes that a client program needs to use the client views of the enterprise beans that are contained in the EJB project. When you create an EJB client project for an EJB project, a new Java project is created and added to your workspace. The EJB client project is added as a project utility JAR file to each module that the EJB project belongs to.
By default, when you use the wizard to create an EJB project, an EJB client JAR project is also created. However, you can clear this option in the wizard.
Tip: You can also add the EJB client project to another enterprise application that does not include the EJB project as a module. This will ensure that the EJB client JAR file is exported and packaged with the EAR file when the application is exported.
An enterprise bean is a Java component that can be combined with other resources to create distributed client/server applications.
There are three types of enterprise beans: entity beans, session beans, and message-driven beans. Typically, all types of beans are used together within an enterprise application.
Entity beans store permanent data. Entity beans with container-managed persistence (CMP) require database connections. Entity beans with bean-managed persistence manage permanent data in whichever manner is defined in the bean code. This can include writing to databases or XML files, for example.
Session beans do not require database access, though they can obtain it indirectly (as needed) by accessing entity beans. Session beans can also obtain direct access to databases (and other resources) through the use of resource references.
Message-driven beans are a special kind of enterprise bean that acts as a message consumer in the JMS messaging system. As with standard JMS message consumers, message-driven beans perform business logic based on the message contents. In several ways, the dynamic creation and allocation of message-driven bean instances mimics the behavior of stateless session enterprise beans. However, message-driven beans are different from stateless session enterprise beans (and other types of enterprise beans) in a couple of ways:
Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls.
Message-driven beans have no home or remote interface, and therefore cannot be directly accessed by internal or external clients.
Beans requiring data access use data sources, administrative resources defining pools of database connections.
A deployment descriptor contains configuration data that the runtime environment uses for an application. A deployment descriptor can include information about the following:
The structure and content (enterprise beans, for example) of the application.
References to internal and external dependencies. For example, an enterprise bean in an EJB module can require another enterprise bean that is not bundled in the same module.
References to resource factory objects, such as URLs or JDBC data sources.
Security roles that the container uses when implementing the required access control for the application.
Transactional information about how (and whether) the container is to manage transactions for the application.
Deployment descriptors are XML files packaged with the application's files in a Java archive file. An EJB deployment descriptor is called ejb-jar.xml and is located in the META-INF folder of an EJB project. A J2EE application contains one application-level deployment descriptor file, governing the application as a whole. It also contains several component-level deployment descriptors, one for each module in the application.
In addition to the standard deployment descriptor, the workbench also includes information on WebSphere Application Server bindings and extensions. The bindings and extensions documents are specific to IBM. Both binding and extension descriptors are stored in XMI files, ibm-ejb-jar-bnd.xmi and ibm-ejb-jar-ext.xmi, respectively. Binding information maps a logical name of an external dependency or resource to an actual JNDI name. For example, the container uses binding information to locate a remote bean at installation. Extensions are additions to the standard descriptors. The extensions enable older (legacy) systems to work in the WebSphere Application Server environment. They are also used to specify application behavior that is vendor-specific, undefined in a current specification, or expected to be included in a future specification.
Mapping documents (map.mapxmi)
The Mapping editor helps you to map enterprise beans to databases. The map.mapxmi file holds this mapping information.
Developing enterprise beans
Create an EJB project.
Create enterprise beans or import beans to your EJB project.
Add methods to the home and remote interfaces.
Add custom finders or add EJBQL queries where necessary.
Add and define additional CMP fields when necessary.
Define relationships between beans as needed.
Define other EJB deployment descriptor elements (i.e. references).
Map enterprise beans to relational database tables:
Generate a top-down mapping (create database tables from existing beans and map them to each other)
Generate a bottom-up mapping (create beans from a database schema and map them to each other)
Generate a meet-in-the-middle mapping (use existing beans and tables and map them to each other)
Update maps with the Mapping editor.
Create session bean facades or create EJB access beans for client applications to use.
Generate deployment code for your enterprise beans (optionally, you can generate deployment code from the command line.
Test the enterprise beans.
Export your EJB project to an EJB JAR file.
Generating a bottom-up mapping
You can use the bottom-up mapping approach to generate CMP enterprise beans and mappings from an existing database schema.
You can use the EJB mapping wizard in the EJB tools and use the following development approaches for mapping enterprise beans to database tables. If you already have entity beans in a project, the mapping gives unique names to generated beans to avoid collision of new table mappings to existing CMP entity beans. By default, relationships are generated where foreign-keys exist.
In an enterprise bean with container-managed transactions, the EJB container sets the boundaries of the transactions. You can use container-managed transactions with any type of enterprise bean: session, entity, or message-driven. Container-managed transactions simplify development because the enterprise bean code does not explicitly mark the transaction's boundaries. The code does not include statements that begin and end the transaction.
Typically, the container begins a transaction immediately before an enterprise bean method starts. It commits the transaction just before the method exits. Each method can be associated with a single transaction. Nested or multiple transactions are not allowed within a method.
Container-managed transactions do not require all methods to be associated with transactions. When deploying a bean, you specify which of the bean's methods are associated with transactions by setting the transaction attributes.
A transaction attribute controls the scope of a transaction. A transaction attribute may have one of the following values:
If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.
The Required attribute will work for most transactions. Therefore, you may want to use it as a default, at least in the early phases of development. Because transaction attributes are declarative, you can easily change them at a later time.
If the client is running within a transaction and invokes the enterprise bean's method, the container takes the following steps:
Suspends the client's transaction
Starts a new transaction
Delegates the call to the method
Resumes the client's transaction after the method completes
If the client is not associated with a transaction, the container starts a new transaction before running the method.
You should use the RequiresNew attribute when you want to ensure that the method always runs within a new transaction.
If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container throws the TransactionRequiredException.
Use the Mandatory attribute if the enterprise bean's method must use the transaction of the client.
If the client is running within a transaction and invokes the enterprise bean's method, the container suspends the client's transaction before invoking the method. After the method has completed, the container resumes the client's transaction.
If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Use the NotSupported attribute for methods that don't need transactions. Because transactions involve overhead, this attribute may improve performance.
If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Because the transactional behavior of the method may vary, you should use the Supports attribute with caution.
If the client is running within a transaction and invokes the enterprise bean's method, the container throws a RemoteException. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
You can specify the transaction attributes for the entire enterprise bean or for individual methods. If you've specified one attribute for a method and another for the bean, the attribute for the method takes precedence. When specifying attributes for individual methods, the requirements differ with the type of bean.
Session beans need the attributes defined for business methods, but do not allow them for the create methods.
Entity beans require transaction attributes for the business, create, remove, and finder methods.
Message-driven beans require transaction attributes (may use either Required or NotSupported) for the onMessage method.