Introduction

Background and context

Since the World Wide Web appeared in 1990, it has evolved from an application that allowed physicists in Europe and the US to exchange documents to the social and technical force that it is today.  Indeed, it is not just a huge repository of information or even the dominant application on the Internet used by billons of people.  It has become the interface to an ever expanding collection of applications and services that range from ecommerce to social networking.  Indeed, many corporations, organizations, and government agencies do much of their business through systems accessed through the Web.  To meet these needs, a new type of system has emerged -- the enterprise system. 

An enterprise system is a system that is capable of supporting a large organization; providing access to large, diverse collections of data, but in an integrated way; supporting a wide variety of applications in a secure and reliable manner; and serving large numbers of users in fast response real-time.  Large corporations have, of course, operated computer systems in support of their core businesses for many years -- think of the role of database systems.  What is different about an enterprise system is that multiple data sources and applications are integrated into a single overarching framework that is accessed largely through the Web.

The software used to build enterprise systems comes in two flavors:  Microsoft's .Net and J2EE (Java 2 Enterprise Edition).  The .Net infrastructure, of course, come from a single vendor -- Microsoft -- whereas J2EE is an architecture, implementations of which are offered by several vendors.  IBM offers its WebSphere brand of products; formerly BEA, now Oracle offers WebLogic; Apache offers Geronimo; and JBOSS is an open source application server.  In the remainder of this discussion, we will not discuss .Net software further and, instead, focus on J2EE systems, in general, and on IBM's implementation of that standard, in particular, in its WebSphere and Rational product lines.

Problems and Issues

A fundamental problem for enterprise systems is their inherent complexity and the subsequent difficulties people have in designing and building them.  To understand why these systems are so complex and so hard to build, one must understand their inherent architecture and the nature of their implementations.

J2EE systems are highly layered.  This results from a combination of the particular resources included in the J2EE specification and a set of best practices that have evolved for their use.  J2EE distributions include libraries for creating view objects (e.g., JSPs), navigation control (e.g., Struts and Faces), transactions and access control (e.g., Session EJBs), domain models (e.g., Java), and persistence (e.g., Entity EJBs and JDBC).  There is a chicken and egg relationship between resources and layered designs -- because resources, often for historical or legacy reasons, are divided into particular collections, designers tend to use them in corresponding functional layers; because designers prefer layered designs, new resources are often added as packages that support a particular functional layer.  A typical J2EE layered architecture is shown below.
 

Figure 1:  J2EE Layers

The different layers present very different programming models.  That is, the tools for a given layer and the way a developer thinks about programming that layer are quite different from those for a different layer --  for example, programming a user interface control layer is nothing like programming a Session EJB or a domain model component.  Comprehensive development environments, such as IBM's Rational Application Developer or WebLogic's Workshop Development Environment, ease the task, but these are large, complex, and expensive tools that produce voluminous output not easily understood by the programmer inexperienced in J2EE systems.

At the end of the day, although the J2EE architecture offers many advantages for building and maintaining large enterprise systems, there is danger that the architecture could sink under its own weight and complexity.  What is badly needed is a way to build basic J2EE systems more quickly and easily, and to help programmers new to this architecture ascend the steepest part of the learning curve more quickly.

The goal of our research is to enable programmers to automatically generate most of the code and deployment descriptors for simple J2EE applications.  These files are embedded within generated WebSphere Studio or Rational Application Developer project structures. Programmers can then perform a few simple "clean-up" steps and test the generated application.  They will be able to study the generated projects, files, and descriptors to help them understand how they work.  They can also alter them to experiment with the design and to see how such changes affect the generated solutions. 

We expect that expert programmers using our resources will be able to develop simple prototype application that might normally take 4 to 8 hours in, at most, a half-hour.  Novice J2EE programmers should be able to get over the worst of the learning curve in several weeks and then be able to create simple J2EE applications in a few hours.  In a university undergraduate setting, this process currently takes 4 to 5 weeks;  reducing it to 1 to 2 weeks would be a major advantage, allowing more time for design and project considerations vs. time required to learn technical details.