Eclipse as a Context and Tool for
Learning J2EE Architecture and Building Layered Applications

Submitted by

John B. Smith
Department of Computer Science
University of North Carolina
Chapel Hill, NC 27599-3175
919-962-1792  jbs@cs.unc.edu
http://www.cs.unc.edu/~jbs

Goal

To produce students who understand J2EE architecture, can design J2EE layered applications, and implement those designs using Studio, WebSphere, and DB2.  More specifically, our overall goal is to help students -- both college students as well as IT professionals new to this area -- get over the initial learning curve more quickly so that they can move on to more extensive design considerations and a more extensive understanding of J2EE technologies and tools.

Issues and Needs

Context.  We offer a three-course sequence in Web-Based systems.  The third course, numbered Comp 119, is concerned with Enterprise Systems, in general, and J2EE, in particular.  We make extensive use of Studio, WebSphere, and DB2 in that course.  A key part of this course is a student project where teams of 3 or 4 build a J2EE application of their own design.  However, it takes students so long to learn the J2EE architecture and technology they need to do reasonable designs, they don't have sufficient time to implement those designs. 

To be more specific:  currently, it takes students some 6 to 8 weeks to build and understand a simple end-to-end application.  During that time, they must learn Struts, Session and Entity EJBs, Conatinaer-Manged Transactions, Container-Managed Persistence, EJB-QL, Container-Managed Relations, DataSources, and DB2 connection and interaction.  They must also learn a number of different Studio Perspectives and Views, not to mention all of the various nooks and crannies where they must go to set parameters, define properties, etc. 

Once they have this level of understanding and technical competence, they can move on to design methods, project design, and project implementation.  But, trying to do so before they have gained this level of knowledge means that they are trying to do something they literally don't understand.  Thus, before they can design a project that will drive their learning of all this material, they must learn a large portion of it as a prerequisite -- a catch 22 situation.

The discussion above makes reference to university courses and students and the issues students face in developing J2EE understanding, knowledge, and skills.  However, these same issues confront IT professionals -- both within IBM and in the industry as a whole -- when they first begin learning J2EE.  The resources we will develop could assist them, as well, within a variety of learning contexts, including time-compressed workshops and hands-on seminars.  We will continue describing our project as it pertains to a university setting, but it should be understood to apply to a much larger range of situations where individuals are first attempting to gain a comprehensive knowledge of J2EE.

Approach

We will try to accelerate the process or gaining an overall understanding of J2EE by merging three concepts and sets of resources.

First, we will support a sequence of architectural layers that conform to familiar concepts.  Currently, layers are tied to J2EE technologies, such as Struts Actions, Session EJBs, Entity Beans, and DB Mapping.  Before one can understand the value or function a layer is providing, one must first understand the implementing technology.  On the other hand, design patterns and best practices have greatly constrained the use of particular layers for particular purposes.  Thus, for example, Session EJBs are normally kept very "thin," providing access control and transaction support.  The semantic or business logic is concentrated in a "mapping" layer between Session and Entity Beans.  Etc.  Thus, we can speak of View, Control, Access, Transaction, Business, and Persistence layers instead of View, Action, Session EJB, Mapping, and Entity EJB layers.  The latter terms and function will seem obvious to students and enable them to move on to building simple end-to-end applications much more quickly.

Second, we believe that simple end-to-end applications that rely on a DBMS for persistence are likely to be based on basic CRUDS (Create, Retrieve, Update, Delete, and Search) methods.  Thus, for example, if the design calls for registration, login, and a simple application such as an addressbook, a catalog of photographs, a record collection, etc., the system is likely to include functions for creating, retrieving, deleting, etc., various types of data stored in separate tables.  That is, CRUDS methods for different data object types.  Of course, the CRUDS method set may be extended for specific applications or to provide additional  function.  We are developing superclasses to support CRUDS methods for the interior layers of a seven-layer J2EE architecture.  Doing so is non-trivial because of different constraints that exist for the various levels -- e.g., Session EJB classes can't be abstract -- and, thus, would not be apparent to someone new to this area.  We will build code generators that will do most of the work involved in implementing simple end-to-end applications by exploiting these superclasses.

Third, we will pull the first two parts of the project together in a set of Eclipse tools/plugins to enable users to define a layered architecture using familiar concepts and then generate simple end-to-end applications that map those concepts onto J2EE components.  The tools will include wizards, dialogs, automatic code generators, and, perhaps, graphical editors.  The generated applications would be based on the CRUDS superclasses, allowing the user to select from the default supported methods (include all or only some)  as well as add additional methods that must be fleshed out by the user.  For these extensions, however, the system will provide a number of support methods that will make their implementation much easier than building them in a conventional manner.  This part of the project has obvious relation to UML concepts, and we will attempt to integrate our tools with UML tools.

With such a design and implementation in hand, students will be able to run it, experiment with it, look "under the hood" to see how a given layer is implemented in J2EE, and gain an understanding of the function and value provided by each layer.  With this experience, they will be able to move much more quickly to project design.  And they will have more time to delve into J2EE technologies and tools, such as Studio.

We will also develop on-line course materials to support learning and use, which we will make freely available.

Participants

John B. Smith,
Professor

Diane Pozefsky,
Research Professor and Scientist,
Formerly, IBM Fellow

Kyle Brown,
IBM Senior Technical Staff Member