Initially Java was to be a language for building robust Internet applications. The tools available in the infancy of Java, however, were distinctly oriented towards building GUI applications for display in browsers. These tools were long on graphical components and short on data access and enterprise programming features. As a result, the first Java applets provided much more style than function and the notion of using Java applets on web sites came into disfavor.

Only later did versions of the JDK introduce the construct of server-side applets dubbed servlets. Still, servlets were a primitive use of Java on the server and something else was needed. This came with the introduction of Java 2 and Enterprise Java Beans (EJB). With EJB, a true three-tier application could be built with Java, complete with business objects that encapsulated database access and abstracted business rules.

Sun's Forte for Java Community Edition, which is built on the Open Source Netbeans project, aids in the development of server-side applications through servlets and Java Server Pages. This Java IDE, however, is short on enterprise features and does not provide for building an EJB. On the other hand, the new Forte for Java 3.0, Enterprise Edition (FFJEE) provides a robust environment for developing enterprise-class Java applications concentrating on the features for database access, web service creation, and EJB creation and deployment.

To test FFJEE's enterprise-class features, we decided to build an EJB that modeled information about magazine subscribers, and a test web application that used that EJB. We also used that EJB to make a web service that could be used to retrieve information about subscribers over the web. We tested FFJEE with a number of different databases including MySQL, Microsoft SQL Server, DB2, and PointBase, a pure Java database that is included with both editions of FFJ 3.0. The database that seemed to work best was DB2, followed closely by PointBase.

When using FFJEE with a database, understand that you must have a functional JDBC driver on your system for the database features to work. Since PointBase is a pure Java database, it includes a JDBC driver, as does DB2. Unfortunately, MySQL and SQL Server did not include JDBC drivers; you'll need third-party drivers to use them with FFJEE.

To create a schema we chose New/Databases/Database Schema from the context menu of a package we had previously created. This action exposed the first flaw we found in the software. When you use the context menu—especially the New menu, which is long—the menu first displays from the position where you right-clicked, downward. Then the IDE figures out that it can't fit the menu downward, so it re-displays the menu upward. It only does this after you move to a sub-menu, at which point it forgets where you were.

We had no such problems with the wizard used to create an Entity bean from a table. You can create either a Bean Managed Persistence (BMP) entity bean or a Container Managed Persistence (CMP) entity bean. If you choose to create a BMP entity bean, you are responsible for all of the database access code for your bean. You must adhere to the EJB specifications, which can be quite a task. On the other hand, if you choose to create a CMP entity bean, the EJB container handles all of the database access code. You only have to implement a minimum number of interfaces to make your bean work. In most cases, this will be the preferred method, especially if you are using an RDBMS to store your data. The only time when we can see using Bean Managed Persistence is when using an unconventional method of data storage, such as XML.

To minimize an already curdling exercise, we chose to create a CMP bean. When FFJEE queried for a database table to use as the basis for our entity bean, we chose our SUBSCRIBER table and were presented with the list of columns for our review. FFJEE automatically created the Java field names with the common method of using a lowercase character for the first character in the identifier, and uppercase characters for the start of other words within the identifier. For example, the database column named MEMBER_ID was changed to memberId. We don't have a problem with this as it is a common practice, but the Java field name was not the only thing changed.

When you create a CMP entity bean, by default, FFJEE creates SQL statements for the CREATE and DROP of the table, as well as SELECT, INSERT, UPDATE and DELETE statements that correspond to the ejbLoad, ejbCreate, ejbUpdate and ejbDelete methods of the entity bean respectively. Unfortunately, these statements use the same names (case included) as the Java field names. Also, FFJEE expects that you will create a new table based on the old table's schema to hold any data added by your application. All of this is fine unless you actually want to use the old table.

If this is the case, you must manually change the properties of your entity bean, in order not to create a new table when your application is deployed and not drop the existing table when your application is undeployed, which is all easily accomplished through a property sheet. If that were the end of it, we wouldn't have any complaints. The problem is that since FFJEE changed the column names in the property sheet to match the Java field names, you must now go back and manually edit the SQL statements to match the original table, including the case of the identifiers. A simple option to use the original table as the target of the SQL statements would make life much easier.

Once the wizard completed its magic, we were left four new entries under the package we had created to hold our entity bean. The wizard created two interfaces, one Java class, and a logical bean that wraps it all together. This logical bean is very important. It allows you to create business methods and finder methods, as well as, create methods once and have the appropriate entries made in the physical class and interfaces. In particular, we invoked the context menu for the logical bean and chose New Finder Method from the menu. We entered the method name findByCompany, and the single String parameter, “companyName”, into the dialog box. A method signature was automatically created in the home interface for our bean. The only thing left for us to do was to create a SQL SELECT statement for our new finder method.

In another case, we wanted a business method that would return a Java class that wrapped all of the bean's CMP fields for easy processing. Again, we invoked the logical bean's context menu and this time chose New Business Method from the menu. We called our business method getSubscriberDetail and had the method return an object of class SubscriberDetail, which we had created earlier. FFJEE automatically created a method signature in the remote interface of our bean and a method skeleton in the implementation of our bean. To complete the business method we just had to write the code in our bean's implementation. Being able to look at the logical bean in the IDE alleviates the need to remember what bean code has to be created when you add business, finder, or create methods. The IDE does it for you and you can concentrate on the implementation of the method.