Business Application Framework

Presentation

Web-centric applications refer to a specific configuration representative of middle-size applications where the web container hosts both presentation and business logic, and no EJB container is used. This kind of structure is widely spread, because it results adequate when EJB component-based solutions introduces unnecessary overhead in development and runtime.

In this document we describe BAF and “G++ for Java™”, the Java™ framework and tool of SYCO for developing multi-tier web-centric Java™ applications. This infrastructure offers an architectural reference model, that allows concentrating design and programming efforts in the development of the specific system’s business logic, and supplies tools that help developers in system modelling, and in Java™ code and JSP scripts generation.

Main support is given for user management, session handling, and request-response cycles. It is also offered special attention to database access through a middleware that acts as a bridge between object-oriented programs and relational databases, hiding to the programmer major concerns about data storage.

Why a framework?

Object Oriented frame-works allow the reuse of design and code devel-oped for approaching certain common problems in systems development. The benefit is increased with the availability of in-tegrated tools, for sup-porting automated code generation from frame-work’s base classes and components.
As consequence of the use of frameworks, projects experience important reductions in their complexity, requiring less time and fewer resources at development and maintenance stages, in the software life cycle.

Genaral architecture

Client tier

The framework adopts web-based interfaces, which are commonly used in enterprise applications because of the simplified client application deployment, and the possibility of giving universal system access through its URL. These interfaces are HTML pages with Javascript code, and optionally enhanced with HTML components (HTC) in order to simplify the development. Pages usually contain common controls for data input and output, and buttons to submit events to the middle-tier. Event communication between client and middle tiers is performed sending a set of predefined parameters over a standard HTTP 1.1 channel.

Middle-tier

In the middle tier resides the core of the proposed architecture. This tier is, in turn, logically subdivided in three layers: interaction, business and data access (see figure).

Interaction layer

The Interaction layer is located on top of the middle tier. This layer is responsible for processing user requests received through the web server interface, and for preparing the system’s response. This layer has -as controlling component- the BAF’s Application Servlet, which is a concrete extension of the javax.servlet.http.HttpServlet class. The web container invokes the adequate Application Servlet’s method (doGet or doPost) each time an HTTP request is received from the client. The parameters contained in the request allow the Application Servlet to determine the corresponding Behaviour Object responsible to deal with it, and to restore the state of the operation performed by the client. Then, the Application Servlet instantiates the corresponding Behaviour object and uses it to process the request. At the end of the transaction, the Application Servlet prepares and executes the Java Server Page (JSP) that the Behaviour Object identifies as the following page to show to the client.

Some of the specific functions built in the Application Servlet regards user authentication and session management. In particular, the session management adopted offers an automated support for moving through the different pages that compose an application. The implemented mechanism includes control of the stack of the calling pages. It allows the creation of a navigation structure that emulates traditional systems organized around hierarchical menus. It also provides a flexible mechanism to suspend and resume working sessions, independently from the location of the machine where the session is restored, or where runs the instance of Application Servlet called to deal with the session. This becomes particularly useful when replication of web-containers and Application Servlet is used for the load balancing of the system, because a suspended session can be restored in a transparent way on whatever enabled server.

Because of the Application Servlet is the core component, it is also responsible for initializing and destroying classes pertaining to the data services layer, and in particular, those that holds connection to the database.

Business logic layer

The Business logic layer includes a set of Behavior Objects that encapsulate the transaction logic, and a set of Business Objects representing the data model. Behavior Objects do not contain data, but only the state of the session, and offer a unique method to be invoked by the Application Servlet when it processes a client request. The method implements a finite state machine that controls the entire life cycle of a set of Business Objects (creating, accessing, and deleting them). This procedure, based on the current state of the session, and the type of request received, selects the next JSP and prepares the data to show to the client.

Business objects pertain to the system domain model. They are usually represented in class diagrams from earlier analysis steps, in contrast with Behavior objects that result from the successive session design steps. Behavior Objects and Business Objects are application specific classes that the developer must create extending the corresponding base classes offered by the framework.

Because the internal state of Business objects should be in most cases persistent, they are directly supported by the data access layer.

Data access layer

The Data access layer is responsible for preserving the state of Business Objects in a relational database system. Our Persist Framework that implements an object-oriented interface to a relational database supports this mapping. Data objects –which are Java™ objects derived from this framework- are the required instances that the Business objects access to perform their activity. The data access layer also supplies database access to the Application servlets in order to save the session state.

Data-tier

The data tier usually corresponds to a relational database management system that is, in most cases, shared with other enterprise existing applications. Communication between the middle tier and the data tier occurs over a standard JDBC bridge.

The G++ Tool

Interaction tree diagrams

An innovative tool for web-centric development is represented by “interaction tree diagrams” conceived to support modelling of the Behavior objects.

1. The Project layer – representing the whole session and collecting all the Java™ Behaviour classes of the application;
2. The Context layer – representing one Behaviour class with its methods;
3. The Task layer – one method specification of a Behaviour class in terms of an elemental state transition diagram an elemental pages.

In the development phase, the tool supports automatic code generation of:

•  Java™ classes of the Behavior Objects
•  JSP fragments, to be later edited and completed with standard HTML or text editors
  

The "Persist" framework

Our Persist framework is the instrument that we propose for accessing relational from any type of Java™ program, in other words, its use is not restricted to BAF applications. With Persist the programmer can work in a high level of abstraction, accessing relational databases under an object-oriented perspective.

What is the “impedance mismatch” problem?

It is a common term used to indicate that objects -in Object Oriented applications- cannot be directly mapped into relations of a relational database. One of the basic “incompatibilities” regards the different way in which both approaches treat identities, identifiers and links between their entities.

Built under the meta-level, Persist offers the set of classes in which the Data Manipulation Language (DML) resides, allowing accessing and updating the database in an objectified way. So that the application can manage tables, as they were object collections, records as concrete objects, and fields as their attributes. This allows the programmer to build simple database queries (select, update, delete), as well, sophisticated ones (i.e. selections with nested join of tables). The DML implemented in Persist supports transaction management guaranteeing data integrity in complex update operations.