Approach
The GES system includes four types of components:
Project Manager
The Project Manager is a J2EE application, deployed in a WebSphere 5.1 platform; it was described, above, with respect to Specification and Design. To summarize briefly here, it provides three major functions. First, as the name indicates, it enables users to manage project materials. It supports multiple users, identified by logins and passwords, groups of users, and it provides access control for their project resources. Second, it provides a tool that greatly simplifies the creation, editing, and storing of application descriptions. The tool, implemented as a Java Applet and shown in Figures 2 and 3, enables users to define User Types, Data Objects including their properties and methods, Interactions between User Types and Data Objects (which users can/cannot invoke which methods on which objects), and Relationships between Data Objects. Third, it includes a different tool to help users identify requirements that determine different layered implementations. This tool is implemented as a JSP questionnaire, a portion of which is shown in Figure 4, and consists of some 20 odd non-independent questions regarding system requirements as well as additional parameters needed for DBMS access, if persistence is required. We use an heuristic to analyze these responses to make a "best guess" at an appropriate implementation. If the user does not like our inferred implementation, he or she may edit the questionnaire and "nudge" it toward a more desirable one.
Plugin Architecture
An Eclipse plugin, also written in Java, generates the implementation. We have two versions of the plugin: one for WebSphere Studio 5.1.2 and another for Rational Application Developer 7.5. They both function the same but have slightly different appearances because of the underlying version of Eclipse on which each environment is based. They take as input an application description and an implementation description, both XML files as described above. The user may also specify a project name prefix and a Java package prefix; they are appended to conventional names for the J2EE projects and the java code generated by the plugin.
The plugin is built as a conventional Eclipse plugin using a wizard as a user interface. Once user data are input -- the two XML descriptions and the two prefixes -- generation is initiated as a long-running thread. That object, in turn, calls specialized generators to build the individual J2EE projects that comprise the application. Control for generation is provided by the implementation XML file. That is, the plugin first generates all of the projects necessary for each container included in the description. For each container, it generates the project(s) required to implement the layers contained within each container. Within each of these projects, it first generates packages for the Java code and then the code, itself. Finally, it generates configuration files, deployment descriptors, and other meta files.
The application XML description file provides parameters for generating the Java code for each data object, package names that include a reference to these objects, and tags within various meta files. For example, object names, their properties and methods. To make access to these parameters easier, the application description XML is parsed and its values transferred to a bean-like model with convenient getter and setter methods. Actual code generation for individual classes and other component types (e.g., JSPs and PhP files) is done using templates, simplified by a set of superclasses. These components are described next.
GES Superclasses
A key realization that underlies our work is that much of the function for many database-oriented applications can be provided by five basic methods: adding new items to the database, retrieving a known item, updating an existing item, deleting an item, and performing a search based on column values within a given table, possibly returning multiple items. These five methods are often referred to as CRUDS methods. Within a given J2EE layer -- for example, the Session EJB layer -- the implementations of the CRUDS methods for two different data objects -- for example, a user object and a product object -- can be virtually the same except for the name of the object and, perhaps, the name of the Domain Model that will be called.
Consequently, we have developed superclasses for all of the Java classes to be generated. These superclasses include abstract methods for all data object-specific parameters and implement the CRUDS methods in general ways, calling on the abstract methods for parameters where needed. Of course, the full Java code could be generated for individual objects within layers, but the superclasses greatly simplify the templates since they need only implement the abstract methods. Some superclasses require as many as ten or twelve abstract methods, but most require only three or four. Even so, most of these methods are relatively simple to generate.
Code Generation Templates
Code generated for the various data objects within the different layers is generated using Eclipse's Java Emitter Templates (JET), part of its Eclipse Modeling Framework (EMF). Whereas both WSAD and RAD include versions of JET, the Eclipse version is simpler and adequate for our purposes. Creating a JET template for a Java file (or other file type, including JSP and PhP ) is a two-step process. First, one writes a text file into which may be embedded Java logic that will be executed when the file is saved. This executable code is set off from the basic text of the file by special tags adopted from JSP. For example, scriptlets are marked by <% . . . %> tags, and conventional expression and declaration tags are also recognized by JET. This executable code is used to generate repeated blocks of text, perform conditional logic, and insert parameters from a model. The text file is marked by a .javajet suffix. Second, when a file is saved, the embedded Java code is executed and the resulting file -- with its repeated text, inserted parameter values, etc. -- is saved to a different location. This file comprises a template as used by the plugin to generate the application code. It is a basic Java file that relies on a bean-like model for parameters. When it is executed by the plugin, it generates the Java code that is inserted into the package and project structures for the application. Of course, if the text file in the first step was JSP, executing the Java template would produce a JSP file; similarly, for PhP.