Approach
Once the application has been generated, within either the RAD or WSAD environments, the user must perform several cleanup steps in order to actually run it. These steps include invoking wizards within the RAD or WSAD environments so that they perform support functions, mapping and connecting the application to the database, implementing non-CRUDS methods, and updating Struts navigation mappings. We will discuss these various operations with respect to an EJB application in more detail, below. We also provide several tasklists that guide the user through them:
When one develops an application within either the WSAD or RAD development environments, a number of wizards are provided that not only generate code for the specific task but perform necessary side-effect tasks. For example, when one creates a reference in a Session EJB project, in addition to updating local deployment and configuration files, the wizard also registers the object with the JNDI server. Whereas we could conceivably provide that function in our plugin, we elected to omit it and rely on environment wizards for such support as a more cost-effective allocation of our time and resources. We describe some of these steps and the tradeoffs we made, following.Invoking Wizards
In an Entity EJB project, one is likely to have to perform three or four steps, depending on the nature of the application. If the application includes relationships, one should edit them in the deployment descriptor wizard by simply stepping through the various pages of the wizard but changing nothing. When the "edited" relationship is saved, the wizard generates the necessary getter and setter methods in the objects to support foreign key navigation. Similarly, editing an EJB query also causes the wizard to generate access methods with which to invoke the query in the home interface objects.
In a Session EJB project, one must ensure that any downstream object, such as a Domain Model, that requires access to an Entity EJB can locate that EJB. WebSphere provides such access through a JNDI reference. Creating and registering a reference is done through the Session's Deployment Descriptor. Although the GES plugin creates an initial version of those references, they should be redefined and saved in the Session wizard in order to register them with the JNDI server.
Map EJBs to DataBase
One of the advantages of using J2EE and EJBs over Java and JDBC is the support for database interaction provided through Container-Managed Persistence. This automatically-generated support allows the J2EE container, e.g., WebSphere, to handle database queries and updates without direct programmer-generated code. This is accomplished at a deployment level and through support code generated by a wizard. The key steps are generating a mapping between EJB data objects and dbms tables and then editing the mapping to refine column names, data types, data lengths, etc. Providing this step in WSAD is straight forward and accomplished through the mapping editor. With WSAD, one can invoke the table editor to refine the generated default mapping. For tables that include a dozen or more columns, doing so is important since the default length of some fields -- especially VARCHAR fields that default to 250 -- can aggregate to more than the default cache size for the dbms, causing failure when the mapping is exported to the database.
Unfortunately, there appears to be no way to invoke the table editor in RADS; we are continuing to try to identify a way to do so, but for now this appears to be a significant stumbling block for using RADS for applications that require EJB top-down mappings.
Implement Non-CRUDS Methods
The GES superclasses provide the five CRUDS methods: add (create) retrieve, update, delete, and search. They are supported by abstract methods that individualize them for specific data objects. The classes generated by the GES plugins implement those abstract methods. For non-CRUDS methods, the plugin generates method stubs that include the signature for the method but no implementation of any function internal to the method. Since there is no way for the plugin to know about such internal function, based on the information available in the application description, the programmer must manually code this. However, we have found that in many cases this code is quite simple and/or relies on the CRUDS methods available to it within the GES superclass the generated class extends.
Update Struts Configuration
The Web portion of the application includes view, control, and model layers. Currently, GES generates implementations for these layers based on the Struts 1.1 framework. A key component of a Struts implementation is the struts-config.xml file which defines abstract names for components, maps them to their implementation classes or path references, and specifies necessary parameters. Included in this configuration are navigation links between components. For example, which action or JSP should be invoked when a login action fails? or when it succeeds? Navigation links are defined by forward elements that are part of action tags. GES generates placeholder elements for both success and failure conditions. The programmer must edit these to define that actual navigation links that the application requires as well as add any additional links that go beyond basic success or failure conditions.