Structure of the generated application

Contents

Overall structure
Model classes
Value class
Descriptor class
Update class
Server subsystem
Entity layer
Session facade layer
Web client
Use case model layer
HTML View layer
Framework classes

This section describes the structure of the J2EE application which Gen2J generates. It also describes the framework and utility classes provided with Gen2J which are used in the generated application.

This section assumes a reasonable knowledge of Java™ and J2EE™.

Overall structure

The generated application has two subsystems, each of which has two main layers:

The generated application also contains a package of model classes used to pass data betwen layers. Some standard framework classes classes provided with Gen2J are included with each application.

Model classes

These classes are used to transfer details of the core business objects between the entity, session facade and use case model layers. For each core business object and auxiliary business object class in the UML input model, Gen2J generates:

Value class

This is an immutable, serializable class which contains the details of a business object. It is used to transfer the details of the business object from the server subsystem to its clients. A value object may contain other value objects or descriptor objects.

Descriptor class

This is an immutable, serializable class which contains only the data items needed to describe or identify a business object, for example a Customer's name and account number. It is used within value objects to identify another referenced object. For example a value object for an Order might contain a descriptor object for the Customer to which the Order belongs.

Update class

This is a serializable class which contains the details of changes required to the details of a business object. It is used to transfer the changes from clients back to the server subsystem.

Server subsystem

The server subsystem is the part of the application where the core business objects and their associated application logic reside. It is implemented using EJBs, and it needs to be backed by a relational database to store the business object data.

This part of the application would be shared by any new client subsystems which were added to the web client currently generated. All clients access this subsystem through the Session facade layer. Clients do not have direct access to the Entity layer.

Entity layer

The core business object and auxiliary business object classes each have an Entity EJB. EJB 2.0 relationships are specified to reflect those in the input model. The EJBs use serverEJB specification 2.0 Container Managed Persistence (CMP). The EJB deployment descriptor generated by Gen2J specifies all the CMP attributes of each EJB, but the mapping to relational database tables is left up to the application server and the deployer. The Sun J2SDKEE 1.3 reference implementation will generate a default database and mapping if required.

Session facade layer

This layer is the interface to the application seen by all clients. It acts as a wrapper around the Entity layer, and forms the outer boundary of the server application, hiding the Entity EJBs. No remote references to other EJBs are passed in or out of session facade class methods. The input and return parameters are either primitive types, or model classes representing the data within an Entity EJB, or classes designed specifically to act as parameters to session facade methods.

A separate session facade class, represented by a stateful Session EJB, is generated for each Actor in the input model. Each Actor's session facade contains only the functionality which should be accessible by that Actor. Each user session in a client application is allocated its own session facade object.

Web client

Use case model layer

Each object "seen" by a human user of a client application is represented by a Use Case Model (UCM) class. The UCM classes are used by the HTML View layer, but the same classes could also be used by any other view layer created in the future. This layer "factors out" all the functionality common to most human-oriented client applications, so that the view layers can be as "thin" as possible. The UCM layer hides the Session facade layer from the view layers. Each view objects displays exactly one UCM object, although it may contain sub-views to display UCMs contained within the outer UCM. The UCM classes present a set of properties which is intended to be exactly what the views need to display.

The UCM layer as a whole performs has many of the responsibilities of the Controller in the Model-View-Controller pattern formed between the server subsystem ( as model) and the view layer. The view layer still has responsibility for transferring requests and data to the UCM objects. The view layer also decides which views to display at any particular time - the UCM layer is only concerned with providing the data needed by the views, and NOT with controlling or sequencing the views displayed.

There is a common base class, UseCaseController, for all the controller classes. Use Case Controllers (UCCs) have the following generic responsibilities:

  • Holding data entered by the user

  • Performing limited local validation

  • Accepting commands from the user to perform an action connected with a step in the use case

  • Making calls to the server when necessary, using the entered user data

  • Holding data returned by the server

  • Knowing the view which should be displayed at the current point in the use case

  • Making data available to the view when it needs it

HTML View layer

This layer generates HTML pages which provide views of the Use case model layer objects. Other view layers would be possible, perhaps to provide XML output in a different web client, or to provide a Swing GUI in a standalone client. Different kinds of view layer would have different mechanisms for transferring requests to the controller and displaying the views.

Views

The layer has a JSP corresponding to each Use case model (UCM) class which contains fields, buttons and links to display the properties and actions of the UCM. The JSPs use tag libraries from the Apache Struts web application framework. As UCM objects can contain other UCMs, so the JSPs may include other JSPs. This is done using the Gen2J Object Tag.

Processing actions

All HTTP requests made from the views by HTML links or form actions are handled by the Struts ActionServlet. There are three Struts Action classes in the Gen2J framework, LogonAction, LinkAction and FormAction to which these requests are passed on. These classes pass the request to the UCM object to which the view relates, and then pass an ActionForward for the correct JSP view for the next UCM back to Struts. The Struts framework then forwards the HTTP request to that JSP.

Framework classes

The framework classes include

  • utility classes for use with EJBs, such as a home interface cache

  • base classes and interfaces for the generated classes in the Use case model layer

  • Struts Action classes for handling HTTP requests from web views

Please refer to the Gen2J API documentation for more information.