Developing Enterprise JavaBeans

Creating Enterprise JavaBeans without appropriate tools is a complex process and involves repetitive process of writing the bean skeleton code, the business logic, defining relationships, creating interfaces and the specific XML packaging and deployment descriptors. Studio provides a Bean Wizard that eliminates all system-level coding and abstracts the bean creation process to specifying the bean type and writing the business logic.

This chapter describes the basic approach to writing EJBs in Studio that keeps them in a "ready-to-deploy" state. The Bean Wizard generates source code (.java files) for Enterprise JavaBeans in such a way that it can be included in an assembled application without requiring further source adaptations or recompilation.

Enterprise JavaBean as components

An EJB component is a type of Java class that implements business logic. The Enterprise JavaBean 2.0 specification defines the following type of beans, all of which can be created using the Bean Wizard.

Stateless Session Beans

Stateful Session Beans

Entity Beans with 1.1 Container Managed Persistence

Entity Beans with 2.0 Container Managed Persistence

Entity Beans with Bean Managed Persistence

Message Driven Beans

Studio provides EJB modules and Java Modules, where beans are stored. Supported by Express Development, the EJB modules are kept in a ready-to-deploy state in Studio. There are two types of EJB Modules:

How are Beans Organized in the Desk

Once the code is generated in Studio using the Bean Wizard, the following elements are displayed under the module in their respective bean package hierarchy:

Bean Class

Local or/and Remote Interfaces and

Bean Properties node

The business methods are always written in the bean class in the Editor. Interfaces are automatically generated and compiled each time a bean is generated, business methods added and the code compiled.

Bean Properties node encapsulates the application logic of the bean and describes the enterprise bean and its run-time attributes. There can be more than one Bean Properties node for a single bean class. This is because the Bean Properties node is created for each EJB name of the bean.

The EJB name is used to specify an enterprise bean's name. It must be unique to the module or JAR.

Bean Properties

The Bean Properties panel is available by right clicking on the specific Bean Properties node in the Desk > Open. Double clicking on the specific Bean Properties node also opens the Bean Properties Panel. The user is allowed to set properties here, which get added along with the bean whenever the bean is added to a JAR.

Changes made to the Bean Properties panel never affects the source code of the bean. Changes in the code such as removal of get/set methods corresponding to CMFs and CMRs are identified when the bean code is compiled. After the bean is compiled, the changes are reflected in the Bean Properties panel, and it shows the latest CMFs and CMRs.

In the Bean Properties dialog box that comes up, the respective bean properties are displayed on the left side tree. The following are the attributes of the bean that can be set here:

EJB References

Resource References

Resource Environment References (for CMP 2.0 beans and MDBs)

Transaction Attributes

Environment Entries

CMP Fields (for CMP Beans)

CMR Data (for CMP 2.0 Beans)

OR Mapping and Map Finder Queries (for CMP Beans)

Bean Properties panel does not display the following panels - Method Permissions, Security Roles and Security References.

There are a few properties that can be set only through the Bean Properties panel. They are:

CMR Data The relationship properties of CMP 2.0 beans can be set only through the Bean Properties panel. The CMR Data panel comprises details about the relationships of the CMP 2.0 beans. The multiplicity and navigability (direction) of the beans can be changed in this panel. Note that changing relation type does not affect the code. The EJB name, the CMR Name and the CMR Field Type under the Role Source 2 can also be changed in this panel.

OR Mapping In this panel, only the existing tables can be used to map Container Managed Fields to the appropriate DB Attributes. This node is not present in the Packaging tool as it requires input containing deploy time information only.

A few other properties that can be set are the values of the bean's display name, the bean class, remote class, home class, local home class, local class, primary key, APS Name, and JNDI name in the main panel of the bean.

Java Archive and Bean Properties

Changes made to the bean in the Bean Properties dialog box do not get reflected in the Java archive if the bean concerned has already been added to the JAR. To achieve this, remove and re-add the bean to the JAR. Similarly changes made in the JAR also do not affect the bean's properties globally.

Setting Deployment Information

The Bean Properties dialog box also allows the user to fill in Deployment time information. The information that can be supplied in the Bean properties that pertain to Deployment is:

EJB References mapping

Resource References mapping

This allows the user to specify the JNDI name of his EJB Reference and the Resource Reference while creating his bean and allows this information to be carried forward to the Deployment time.

Creating Bean Properties

When the user imports the sources for a bean class into a Desk, no Bean Properties node gets created on the Desk corresponding to the imported bean class.

To create the Bean Properties for the Bean Class, right click on the specific Bean class file > Create Bean Properties. This brings up the Create Bean Properties panel, where the EJB name of the bean has to be entered. Select the type of bean. Checking the option Open in Bean Properties creates the Bean Properties on the Desk, and opens the Bean Properties panel. Creating Bean Properties in this way, creates the properties with partial information.

Cloning Beans

The feature Cloning Beans is used to create beans from existing beans, with a different EJB name. Having different EJB names gives the new bean a different identity.

Cloning a bean typically consists of creating a copy of its bean properties with the new ejb-name, and copying all its Java files if required. The resulting bean does not retain the finder query mapping (EJB 1.1) and its OR-Mapping, and the user has to provide new values if the destination module is same as the source module. These information are retained if the destination module is different from the source module.

Source files are not copied if the new bean is in the same module as the source bean. In this case only a new bean properties node gets added to the desk.

Advantages of Cloning

Cloning can be used for beans with multiple identities but sharing the same properties.

An Address bean that encapsulates a real world Address, can be used in different scenarios like Shipping Address, Billing Address. Each of these addresses can be seen as individual beans having the same basic properties of Address but having different packaging and deployment properties. In such a case, cloning Address Bean results in Shipping Address and Billing Address.

Cloning can also be used to re-use the source code of a bean in a different location, and re-create the bean quickly in another module with all its source-code.

Cloning Procedure

To clone a bean, right click on the Bean Properties file on the Desk and select Clone Bean. This brings up the Clone panel, where the following information is to be entered to create the new bean.

Destination Module Select from the list of EJB Modules where the new bean is to be created. The list of modules is filtered to prevent beans from being cloned into folders that cannot accept them. Restrictions include-

Beans from an EJB 2.0 Module into an EJB 1.1 Module

Beans into any module other than an EJB Module

If the destination module is the same as the source module, the source files are not copied, else the source files are copied (if available).

If the two modules point to the same source root, the bean is not physically copied in the Source Root, as the file already exists in that location, but only shown in the new module. Changes made to the bean or/and its interfaces in one module here, are reflected in the bean or/and its interfaces in the other module.

If the two modules point to different source roots, the bean is shown in the two modules and also physically copied in the Source Root. In this case, changes made to the bean or/and interfaces in one module are not reflected in the bean or/and its interfaces in the other module.

Enter EJBNames and JNDI Names for Cloned Beans This section displays the bean to be cloned, and allows the user to change the new bean's EJB name and JNDI Name. Cloning a CMP 2.0 bean having relationships with other beans require all the beans to be cloned, along with the source bean. In cases where the beans have relationships, all the beans in the CMR Graph are shown. Providing new EJB names ensure that the source and target CMR graphs are complete and in a "ready-to-deploy" state.

The first column in the table is non-editable and represents the ejb-name of the source bean. The second column displays the new EJB names that are to be edited. Not doing this does not perform the clone operation. The third column provides a way to change the JNDI name of the target bean.

Overwrite Existing Files Check this option if the existing source files are to be overwritten while cloning. This option is available only for source files. Target Bean Properties are always written in the file system irrespective of their existence in the destination module.

Status Box This section displays the status of the cloning operation as it proceeds.