April 13, 2011, 5:41 p.m.
posted by franni
Creating a Session Bean
Now that you have seen how to create an EJB project as well as how to set up dependencies from an EJB project to other modules and utility JARs within the enterprise application, you are ready to create an enterprise bean. Creating an enterprise bean within WSAD is accomplished by using the enterprise bean creation wizard. You will use this wizard to add an enterprise bean entry to the ejb-jar.xml deployment descriptor. It also has the capability of generating, if necessary, the JavaBean classes and interfaces required to support the enterprise bean. We will start by providing details of how to create both stateless and stateful session beans. Later chapters will provide additional details for creating entity beans and MDBs.
Start by creating an EJB project named UtilitiesGroup which belongs to a new EAR project named UtilityEAR. We will use this EAR and EJB project for the rest of this example. Once you have done so, you are ready to create a session bean that will be used to create random integer values. This could be a useful class if you do not have a natural key value for your object model. For example, a person will have a Social Security number as a natural key value but a LineItem may not have a natural key value. In this case, any unique value would be adequate. Note that this is a simple example of a session bean and you would probably not use this example as a way to produce unique IDs because random integers are not guaranteed to be unique.
A much better option for automatic ID generation will be described in Chapter 23 when container-managed entity beans are described.
1 Using the EJB Creation Wizard
Like many other actions within WSAD, opening the EJB creation wizard can be accomplished many ways. The most basic way to open the wizard is to select New > EJB > Enterprise Bean from the File menu bar. This path is available anywhere within WSAD. When working in the J2EE perspective, which is the desired perspective to operate within when working with enterprise applications and EJBs, there are many methods to open this wizard. For example, it can be opened using the context menu on an EJB module selection in J2EE Hierarchy view. Refer to the online documentation for other shortcuts to opening the EJB creation wizard.
Select File > New > EJB > Enterprise Bean from the menu bar to open the Enterprise bean creation wizard. Figure shows the first page of this wizard where it is necessary to select an EJB project in which you would like to create the new enterprise bean. For this example, we will select the UtilitiesGroup EJB project from the combo box. This page will not appear for all open actions because the selected project may already be known and cannot change.
The second page of the EJB creation wizard, shown in Figure, contains choices for the basic settings of the new enterprise bean. Near the top of the page is a series of four radio buttons for each type of enterprise bean. In this example, we are creating a session bean. The name of the session bean that we are going to create is RandomIDGenerator and it is entered in the Bean name text field. The Source folder, which defaults to ejbModule, is a folder within the EJB project in which the newly created bean is placed. You may select another existing source folder or enter a new folder name and it will be created for you. You may wish to select a different source folder other than ejbModule since this is the location used when generating deploy code. Choosing another source folder will allow you to keep your bean classes and deploy code completely separated. We will enter source so that we can demonstrate the difference from using the default. The default package will be the package name used for the bean class and interface names that are set on the next page of the wizard.
The third page of the EJB creation wizard, shown in Figure, is used to set deployment descriptor details for the session bean. The first section of the page is where you specify whether or not the session bean is stateful or stateless. With a stateful session bean, conversational state must be retained across methods and transactions. This is accomplished within the EJB container by serializing each method call to ensure that the state is preserved between method invocations. A stateless session bean does not contain any conversational state between method calls. Therefore, any session bean instance may be used by the container since state is not preserved.
The next section is used to specify the transaction type which can be either container or bean. This setting determines whether the session bean will have container-managed or bean-managed transaction demarcation. When the transaction type is set to Container, the transaction demarcation is controlled by the container and is governed by transaction settings on the methods of the session bean client interfaces. With a transaction type of Bean, the session bean is required to create, commit, and rollback the user transactions itself and no transaction attributes should be set for the client interface methods. See Chapter 28 for more details on transactions.
The next field is the bean supertype. This combo box will contain the names of other session beans already created in the EJB project. You can select one of these bean names to define an EJB inheritance hierarchy. You will learn more about EJB inheritance in Chapter 25. The bean class text field is the name of the new session bean's EJB class. The default EJB class name is the bean name and the default package name from the previous page. You may change the name or you may browse for another existing Java bean class or just an existing package name. If you select an existing bean class, the text in the field will change to blue if Java source code is detected and red if only a Java binary file exists for the class name.
Note: A bean class will only be generated upon finish if the selected Java class name does not already exist because it is possible to create a session bean definition from a set of existing bean classes.
The EJB binding name is the JNDI name that will be bound to the session bean within WebSphere. In this example, the default JNDI name is set to ejb/com/wsbook/casestudy/ejb/utilities/RandomIDGeneratorHome which is derived from the fully qualified name of the default home interface name. This JNDI name is specified at bean creation time since it is required for testing purposes.
The last section of this wizard page is for the client views. You can choose to create a local and/or remote client view by selecting the Local client view and Remote client view check boxes respectively. Using a remote client view indicates that a remote client interface and a remote home interface will be created for use by remote clients. Remote clients use RMI for accessing the enterprise bean. Using a local client view indicates that a local client interface and a local home interface will be created for use by local clients (i.e., clients on the same JVM). Local method invocation does not require RMI. Refer to Chapter 22 for more detail about EJB clients and Chapter 30 for deciding when is the best time to use local client interfaces.
For session beans, the Remote client view check box is selected by default but you may decide to create a local client view or both. Just like the bean class, the remote home interface and remote interface default values are set using the bean name and default package name from the first page. The name of the remote home interface adds Home to the end of the default Bean class name (e.g., com.wsbook.casestudy.ejb.utilities.RandomIDGeneratorHome). Also, like the bean class name, you can change the default name and choose an existing class name. Again, the Java interface will only be generated if an existing Java interface name is not selected.
The last page of the EJB creation wizard gives you some control over the generated bean class and client interfaces that will be generated. The EJB Java Class Details page, shown in Figure, has three sections for affecting the generated classes and interfaces. The Bean superclass field allows you to specify another Java class for the new bean class to extend. This is normal Java inheritance and not EJB inheritance. If a bean supertype is specified from the previous page, this field will have the fully qualified name of the supertype bean's bean class and it will be disabled. It is disabled since you are unable to change the superclass if an EJB supertype is specified. This field will also be disabled if you have selected an existing bean class on the previous page.
The second section is a list of Java interfaces that the new remote interface should extend. This section will be disabled if you have not selected to generate a remote interface or you have selected an existing remote interface. The last section is very similar to the second section except that it allows you to specify other Java interfaces that the local interface should extend. This section will be disabled if you have not selected to generate a local interface or you have selected an existing local interface.
After you press the Finish button, three new Java classes will be generated under the Source folder.
A new enterprise bean entry will be entered into the deployment descriptor for the new RandomIDGenerator session bean.
<session id="RandomIDGenerator"> <ejb-name>RandomIDGenerator</ejb-name> <home>com.wsbook.casestudy.ejb.utilities.RandomIDGeneratorHome</home> <remote>com.wsbook.casestudy.ejb.utilities.RandomIDGenerator</remote> <ejb-class>com.wsbook.casestudy.ejb.utilities.RandomIDGeneratorBean </ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session>