During the summer of 2005, I was awarded an IBM Faculty Award to explore development of a set of Eclipse-based tools and other resources to make it easier to learn J2EE and to develop end-to-end J2EE applications. Although the project was based on prior work, research began in earnest, with IBM support, Fall, 2005. This report summarizes progress to date and gives a brief outline of anticipated future work. Those participating in the research, in addition to myself, include Diane Pozefsky (UNC Research Professor and Scientist and former IBM Fellow), Kyle Brown (Distinguished Engineer, IBM), Udi Unithan and Dan Watson (UNC undergraduate students), Chen Wang (UNC graduate student). We have recently been joined by John Medicke (IBM Executive IT Architect).
The problem we are addressing is the difficulty both technical professionals new to the area as well as students have understanding the J2EE programming model and acquiring the necessary knowledge and skills to design and implement J2EE layered systems. To be more specific, a J2EE end-to-end system will include some seven layers, from user interface view objects to a persistent store, such as a DB2 database. The programming model is different for each of these levels -- e.g., designing and building components in a Struts control layer is very different from designing and building an entity EJB component. Each requires not just different Java packages, but also different Studio tools and a different way of thinking about the function of that component.
Our goal is to ease both the learning curve and the actual development of basic applications by doing three things:
The overall structure of our project is shown in the figure, above. Parts will be referenced in the discussion that follow.
We have developed a set of Java superclasses, which we refer to as Generalized Enterprise System (GES) classes and shown above, that provide the basic function for the following objects or layers:
We have not developed support for the EJB Container Entity EJB layer. Instead, we rely on the tools included in Rational/WebSphere Studio since they include necessary DBMS mapping support that would make little sense for us to duplicate.
We based our work on the recognition that a large amount of the function provided within each layer of a J2EE application is concerned with supporting five basic operations: creating new data in the database, retrieving an existing data object, updating an existing data object, deleting an existing data object, or searching for multiple data objects that conform to some search expression. Some applications will not require all five methods, in which case the application subclasses can ignore those methods. Some applications will require additional methods, in which case the application subclasses can add those methods, drawing on support provided by the simple abstract methods included in the superclasses that all subclasses implement.
We have working versions of all 8 sets of superclasses. In some cases, a small amount of hand coding is required -- for example, to map from one data type to another; consequently, we are continuing work on these cases to reduce hand coding using techniques such as Java Reflection.
We have developed a set of Eclipse tools and wizards that build on our superclass work to generate Java code for the 8 layers or support objects listed above. The tools include EMF models and JETEmitter templates, shown next to the GES classes in the above diagram. The models specify the parameters for which values are required to generate the code for a component or layer, such as the name for the class, the DataBeans used, DBMS parameters, etc. The JETEmitter templates include code for the subclass implementations, but with those parameter identified in the models replaced by "getter" method calls to the model. When the two are combined, actual Java code for a given application can be generated.
The wizards we have built, also shown above, control the code generation process. They enable an application designer/builder to identify a specific component or layer and fill in the necessary values for the relevant model. When the data are submitted, the wizard oversees the actual generation of the code for that component or layer, inserting values from the model into the appropriate template, and depositing the generated code within a Java package. Subsequently, the designer/builder may copy that code into a Rational/.WebSphere Studio project for further development.
We have working models and templates as well as an overall control wizard and individual wizards for the 8 components or layers, listed above. Work continues on the wizards to make them easier to use and on the generated code to reduce subsequent hand coding required for portions of some generated classes (e.g., mappers from FormBeans to DataBeans. We are also exploring exporting them as plugins so that they might be used in a Studio context as well as in Eclipse.
The issue we are addressing here is the "artificial" nature of the J2EE layered architecture. The various layers that now makeup J2EE seem to have evolved more from legacy systems than from a coherent, intentional view of what is needed for large scale enterprise systems. Our goal was to replace these arbitrary layers with ones that more closely match system requirements, such as view, navigation, access control, transactions, domain model, persistent storage, etc. Once a designer/builder produces a description of a system within this framework, an automated tool will determine a plausible layered design and then generate the code for the various layers included in the design.
A key point in our current thinking is that not every Web-based system requires all of the layers of the J2EE architecture. For example, a system that requires dynamic page content but only static navigation might well be implemented with a two-layer design (view and persistence) based on an HTTP container, PHP, and a database such as DB2 or MySQL. However, an application that requires dynamic navigation and the more extensive programming capabilities of Java might be implemented with a four-layer design (view, control, model, and persistence) based on a Web container, Struts, and DB2, accessed through JDBC. An application that requires scalability or more sophisticated features -- such as transactions, relationships, and/or messaging -- might be implemented in a full J2EE infrastructure based on both Web and EJB containers (e.g., WebSphere) and include six or more layers (view, control, session ejb, domain model, entity ejb, and DBMS persistence). Once an appropriate layered design is determined (i.e., 2-, 4-, or 6-lyaers), a system generation tool will call on the individual code generators described above to generate the code for each layer in the design, thereby generating virtually the whole system.
This portion of our work is depicted in the bottom half of the figure, above. We have developed a tool that identifies application requirements in terms of a set of user types, a set of data objects including both properties and methods, a set of interactions that specifies which methods may be invoked by which user type, and a set of relationships between data types. The tool produces an XML document that specifies these requirements. We are currently attempting to infer most of the values required to populate the models for the code generators from this specification; the tool will be modified to elicit any additional information needed by the models. We are currently working on a second tool, in collaboration with Kyle Brown and John Medicke from IBM-RTP, to identify implementation requirements. This tool will be based on a similar but more extensive IBM tool used for system configuration. The XML document produced by this tool will be used to infer a layered design appropriate for the application. The system generator will then use these two XML documents to call the various individual code generators for the respective layers to generate a near-complete end-to-end system.
We have working code for the superclasses that underlie our code generation work. Future work will make incremental extensions and refinements to these classes. We have working code for the models, templates, and wizards that generate code. We will make incremental extensions and refinements to these tools, focusing especially on eliminating as much as possible current (small) hand-coded segments required for some generated classes. We will also refactor these resources to make them more modular and, thereby, better suited for automated use within the system generator as well as manual use within Eclipse. We will also do several small pilot studies to assess their usability for designers/builders new to J2EE systems. The bulk of our future work will be focused on the system generation parts of our project. We will pay especial attention to the implementation inference tool, and we are contemplating porting our application inference tool from JavaScript to Java.
All IBM resources have been expended or committed. The pace and scope of future work will, of course, depend on available resources.