Using Forte for Java to Develop and Deploy Enterprise Beans

Print-friendly Version

This article describes the Forte for Java (FFJ), version 3.0, Enterprise Edition product (FFJEE 3.0). FFJEE, when teamed with Java 2, Enterprise Edition (J2EE)-compatible servers and containers, offers developers a powerful environment for building end-to-end Java applications. In this article, we focus on using FFJEE to develop applications using enterprise beans.

FFJEE includes wizard-driven modules for developing, deploying, and testing enterprise beans that adhere to the Enterprise JavaBeans 1.1 architecture. (Note that FFJEE will be supporting the Enterprise JavaBeans 2.0 architecture as of the next release.)

This article highlights the features of the FFJ EJB development module and describes how to effectively use these features. Before delving into details, we summarize the EJB development module's features and benefits, which are as follows:

• Provides development templates for session (both stateful and stateless) and entity beans.
• Includes both bean-managed persistence and container-managed persistence.
• Generates required interfaces and classes--home interface, remote interface, and bean implementation class.
• Coordinates and simplifies bean development through a "logical" enterprise bean.
• Provides the ability to validate the correctness of an enterprise bean against the requirements of the EJB 1.1 specification.
• Automates packaging of the enterprise bean to an EJB JAR file.
• Facilitates bean deployment by integrating application servers through a standard deployment API.
• Simplifies the testing process by using a wizard and generating a JSP test client for the bean.

The key feature of FFJEE is its focus on the enterprise bean development, deployment, and testing cycle. FFJEE takes care of much of the "housekeeping" work and other tasks that go into developing a bean, such as:

• Automatically generating the required interfaces.
• Including the required method implementations.
• Helping you set up enterprise bean fields.
• Either prompting you for or inserting all required parameters, return types, and exceptions for your methods
• Letting you compile the bean classes in one step.
• Letting you package and deploy a compiled bean to your application server in one step. At the same time, you can have FFJEE create a JSP test client for the bean. You can then invoke the test client from your browser to test the bean's functionality.

Enterprise Bean Development

An enterprise bean is a powerful component for modeling business processes and business data. An enterprise bean developer, often an individual who is expert in a particular company's business systems, is most comfortable focusing on implementing the bean's business logic. Although the EJB container and the J2EE platform handle the non-business logic aspects of enterprise computing (such as remote access, transactions, security, and so forth), developing an enterprise bean is not as simple as merely writing the business methods.

Enterprise bean development requires correctly setting up the development environment so that the bean components can be deployed on the application server. You must also write the different components that make up an enterprise bean, and these components have specific required methods depending on the type of the bean. Once you have developed a bean, you must deploy it into the operational environment. Finally, you must use a client or test application to verify the bean.

Setting Up a Development Environment

FFJEE provides tools and wizards for setting up your development environment. Working with enterprise beans implies working with databases. As such, not only must you work with a particular J2EE application server, you typically must have a database server up and running. With FFJEE, you can do this set up work from within the tool environment. FFJEE commands let you set up different database drivers and establish connections to these underlying databases. The tool helps you to configure and run your application server, run the necessary database servers, and so forth.

For example, Figure 1 shows how to use the FFJEE Explorer window to start an instance of the J2EE Reference Implementation application server. The Output window displays the server start up messages.

Figure 1: Starting a Default Application Server

If you are defining entity beans to model a pre-existing database, then FFJEE makes it easy to map the existing database tables to the new enterprise beans. Once you have started a database server and established a connection, you can use the tool to display the database tables, columns within tables, and defined views and procedures. You can also use the tool to map an entity bean and its fields to a specific database table and table columns. If you choose to use container-managed persistence, you can use the property dialog screens to map these persistent fields. Or, you can define the bean's fields manually.

When you work on a project using FFJEE, you are not restricted to developing all the project's enterprise beans from within the tool. FFJEE lets you incorporate into your project enterprise beans that you have developed elsewhere. Using the Project Manager, you can import individual existing beans or entire packages.

Writing the Enterprise Bean Components

There are very specific rules that must be followed when developing enterprise beans. Every enterprise bean, whether a session or entity bean, consists of three interfaces or classes: a home interface, a remote interface, and an implementation class. In addition, these enterprise bean interfaces and classes must include certain required methods, method names must be formed in a particular way, and methods must have specific return types, exceptions, and so forth.

FFJEE simplifies developing an enterprise bean in several ways. FFJEE provides wizards that guide you through the bean development process. These wizards not only show the current step in the development process, but they also indicate the succeeding series of steps. As you choose one option over another, the steps change accordingly.

Defining a New Enterprise Bean

Suppose you want to create several enterprise beans for an application. You might begin by creating a package for the application so that you can keep the beans together. Then, you can right-click the package name in the Explorer window and select a template for the type of component (such as JSP, servlet, AWT form, JavaBean, EJB, and so forth) you wish to place in that package. In our example, we have selected an EJB component, and then selected session bean rather than entity bean.

Selecting an enterprise bean component, either session or entity, brings up a template wizard that takes you through the steps for creating that particular component. Figure 2 shows the wizard screens for creating a stateful session bean.

Figure 2: Developing a Session Bean

The wizard for entity beans lets you specify whether the bean uses container- or bean-managed persistence. Once you designate the bean's persistence management, the wizard prompts you for further information appropriate to the persistence management. When you select bean-managed persistence, you will be writing the bean's persistence yourself. As such, the only additional step is to specify the names for the bean implementation class and interfaces.

If you select container-managed persistence for an entity bean, the wizard walks you through the additional steps for defining and mapping the persistent fields. If the entity bean is modeling a table in an existing database, you can select the table and map the bean's persistent fields to the table columns. (This is shown in Figure 3.) You also have the option of manually specifying the bean's persistent fields, or you can select an existing bean or its primary key Java class.

Figure 3: Defining an Entity Bean With Container-Managed Persistence

Implementing the Bean

Once you have defined the bean type, the tool generates the required home and remote interfaces and the bean's implementation class. The interfaces and classes include all required methods, such as ejbLoad , ejbStore , ejbActivate , ejbPassivate , context-related methods, and create , find, and remove methods. You focus on implementing the business logic for the bean.

To further facilitate the bean development process, FFJEE provides a logical enterprise bean. The logical enterprise bean (identified by a bean icon in the Explorer window) provides a complete, coordinated view of the bean with all its interfaces, fields, methods, and so forth. Because the interfaces and bean implementation are closely tied to each other, it's important that a method declared in one place is properly declared in another. For example, when you expose a create method in a session bean's home interface, you must have a corresponding ejbCreate method in the implementation class. A business method exposed in the bean's remote interface must be implemented correctly in the bean class.

The logical enterprise bean view ensures that FFJEE automatically keeps all of the related bean components synchronized. You also have the flexibility to work directly with individual components, such as the implementation class or the remote interface, or through the logical view. Either way, the tool ensures everything is coordinated. For example, the tool ensures that a new method defined through either the bean's logical view or its remote interface will also appear correctly in the bean's class. However, because you may want to have a method in the bean class that is not exposed through the bean's remote interface, adding the method directly to the bean's implementation class does not automatically add it to the remote interface.

Figure 4 shows the logical enterprise bean, along with the home and remote interfaces and bean class, for a Product entity bean. The file system Explorer window expands the logical Product entity bean, Product.entejb. From the logical bean, you can access the bean class and its two interfaces. You can also view its create, find, and business methods, plus its container-managed persistent (CMP) fields. In addition, right-clicking the logical bean name, as shown in the diagram, brings up a menu of the available operations. You can do such things as view the deployment descriptor, validate and compile all the classes and interfaces of the bean, create new methods (including create, find, and business methods), generate an EJB module, and create a test application.

Right-clicking on a component within the logical bean displays only the subset of operations applicable to that particular component. For example, right-clicking the home interface within the logical bean view gives you the option to add new create and find methods. Similarly, right-clicking the remote interface within the logical bean view brings up a menu from which you can create new business methods.

You can also work directly on the bean interfaces and bean class from outside the logical bean view. FFJEE is context sensitive. When you right-click on the Product.java remote interface or ProductHome.java home interface, for example, FFJEE displays a set of operations specific for that class or interface. You might want to work directly with an interface or bean class when you need to subclass it, map the class to a database table, or compile just that one class or interface.

Figure 4: Using a Logical Enterprise Bean

When you define a new method or field for a bean, dialog screens guide you through the process. You are prompted to enter the method or field name, the type of the field, the method's return type, any method parameters and their types, and additional exceptions to the EJB-required exceptions, which the tool has already added. The tool places the correctly formed method signatures in the bean class and remote or home interface, as appropriate. Figure 5 shows the dialog screen for creating a new business method.

Figure 5: Creating a Business Method

When you are ready to write the implementation of a method, open the bean's implementation class in the FFJEE Source Editor window, find the method declaration, and type in the code. Note that FFJEE displays reserved Java words in blue. Later, when you compile the bean, any compilation errors will be highlighted in red.

You can also specify references for a bean, such as EJB references, environment entries, resource factory references, and security role references. You set up these environment entries and references from bean's References tab within the Property Editor. You can add, edit and remove references and environment entries from this window. See Figure 6.

Figure 6: Setting References and Environment Entries

Validating and Compiling an Enterprise Bean

FFJEE includes a Validate EJB option in addition to the option to compile all EJB classes. Validation is similar to compilation. When you validate your enterprise bean, FFJEE checks that the bean classes correctly follow the J2EE specification. Errors are highlighted and you must correct them in the source code.

While you can individually compile or validate the bean components, FFJEE lets you use the logical bean view and validate or compile all bean components with one command. The Explorer window indicates the beans that need to be compiled and those that have successfully compiled. The Explorer window marks a bean's interface or class with a set of dots to indicate it needs to be compiled. For example, in Figure 7, both Product and MySession beans' classes, remote interfaces, and home interfaces all need to be compiled. (Note that these marks do not appear next to the logical beans.) On the other hand, the CustomerTbl bean has no such marks, indicating it has been successfully compiled.

Figure 7: Beans Marked for Compilation

Packaging and Deployment

Once you compile the enterprise bean classes, you package them into the required JAR file, creating an EJB module, and then deploy the bean to your J2EE application server. With FFJEE, not only is the packaging and deployment process reduced to a single step, but at the same time you can direct FFJEE to create a test application--a JSP client--that you can invoke from a browser to test the bean.

Before you actually package an enterprise bean and create an EJB module, you need to manually resolve any EJB references that may have been specified by the bean developer. The test client application is unable to automatically handle packaging EJBs that contain EJB references. You resolve EJB references from the Properties editor for the particular EJB module.

During the assembly process, you can use operations on the EJB module to override references and environment entries specified by the bean developer. You can also manually edit the deployment descriptor for an EJB module. If you override an entry or reference, the new value applies only to this module reference to the enterprise bean. It does not affect the original value set for the enterprise bean. If the same enterprise bean is included in another EJB module, that second EJB module references the bean's original environment entries and reference values and can override them with its own values. See Figure 8.

Figure 8: Overriding an EJB Reference

The EJB module helps to package an enterprise bean by performing the transitive closure on the set of referenced Java classes. The transitive closure computes all class references for a class that can be identified at compilation. By doing this, the EJB module relieves the burden on the assembler for maintaining all referenced classes. Instead, the assembler has only to maintain the dynamically referenced classes.

Once you've resolved a bean's EJB references, you can complete its packaging and deployment by right clicking the logical bean and selecting the option to create an EJB test application. You are prompted to indicate the application server on which to deploy the application. See Figure 9. If you prefer, you can break this process into several steps. You can use the New EJB Module option to package the bean classes into an EJB module. Later, you can invoke operations on the module to deploy it and the create a test application for it.

Figure 9: Creating and Deploying a Test Application

For the deployment feature to work, you must have selected a default server from the FFJEE Server Registry, which shows all available servers on your system. You must also have created an instance of the server and started the server process.

Although the deployment process in general is the same regardless of the J2EE application server, each application server has its own approach to deployment. At this time, the J2EE platform is in the midst of defining a standard server deployment API. This API will increase the portability of beans to J2EE application servers, because it will provide a standard way to deploy any enterprise bean to any J2EE-compliant application server.

In anticipation of this server API becoming a platform standard, FFJEE provides a server API into which application servers can plug. The server API, by encompassing the entire deployment process, standardizes the deployment process from FFJEE. Application server vendors can provide their own plugin to this API. Each plugin will have different capabilities, depending on the particular application server. The plugins operate between the FFJEE development environment and each of the supported J2EE servers. They implement the server API and integrate each server's deployment process with that of FFJEE. See Figure 10.

Figure 10: Application Server Deployment Plugins

When you are ready to deploy your enterprise bean, because you have already indicated the application server you are using, FFJEE has plugged in the appropriate API for your server. As a result, FFJEE knows how to deploy your bean to that server. To you, the deployment process is simple and straightforward, regardless of the server you use. FFJEE knows the deployment differences from one server to another and it automatically handles these differences.

Testing a Bean

When you have deployed a bean successfully, you'll notice that FFJEE has created an EJB and a Web module for the bean, plus a test application for the bean. The EJB module contains the compiled enterprise bean class. The Web module contains the JSP pages for the test client. To test the bean, you invoke the bean's test application in a browser.

For example, while deploying the MySession session bean, FFJEE creates the EJB module MySession_EJBModule, the Web module MySession_WebModule, and the test application MySession_TestApp. See Figure 11.

Figure 11: Generating a Test Application

In a browser window, enter the URL to the test application, as follows:

http://<machine>:8000/<test application>

For example, to run MySession_TestApp on the machine vaio:

http://vaio:8000/MySession_TestApp

The browser view allows you to access instances of the home and remote interfaces, starting with the bean's home interface. You can invoke methods on the interfaces, such as a create method to create an instance of the remote interface. The view lets you enter any required parameters for methods and displays the method return values. It also keeps a list of objects created during your test session. For example, the browser displays the following testing page for MySession_TestApp. (See Figure 12.)

Figure 12: Testing an Application

Conclusion

This article has demonstrated how FFJEE facilitates the cycle of enterprise bean development, deployment, and testing. FFJEE creates an environment in which it easy for you to focus on writing an enterprise bean's business logic, the real task for a bean developer. This is because FFJEE automatically takes care of many of the enterprise bean development tasks, such as keeping the home and remote interfaces synchronized with the bean implementation class, generating the required methods, ensuring correct method return types, and so forth.

Once you've developed an enterprise bean, FFJEE makes it a one-step process to compile the classes and interfaces that make up the bean. It also a one-step process to package and deploy the bean to your J2EE-compliant application server. In the same step, you can have FFJEE create a JSP test client, which you can then invoke through a browser to test the bean's logic.