EJB development resources
This topic describes resources and development tools that are commonly used in EJB development.
- EJB modules
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.
- EJB projects
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.- Enterprise beans
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
- 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
- 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
- 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.
- Deployment descriptors
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.
Parent topic
enterprise beans that conform to the distributed component architecture defined in the Sun Microsystems Enterprise JavaBeans (EJB) specification. This product supports the Enterprise JavaBeans 1.1, 2.0, and 2.1 specification levels.">EJB application development