Business Application Framework

Business Application Framework


A Java™ Framework for Multi-Tier Web-Centric Application Development



  J2EE offers several configurations that differ in the technology of components used to provide a specific implementation. These configurations are built around two main J2EE optional components, Servlets and Enterprise Java Beans™ (EJB), that run in application servers enabled with web containers and EJB containers, respectively.

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

  BAF proposed by SYCO is a methodology supported by a framework of classes and a software environment for the design and development of three-tier web-centric Java™ applications. These are J2EE applications which architecture has as central point a Java™ Servlet running in a web container, in charge of holding both presentation and business logic. The BAF framework basically supplies classes required to create and drive the application logic, to access data storages, and to prepare and generate HTML pages for user interaction.  
The three tiers of a web-centric application are the following:

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.


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.


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

  G++ for Java™ is an environment and a framework of classes for the design and development of Object Oriented applications for the Java™ language.
Specifically for Business applications it offers frameworks of classes and editors for the design of the OO model of the business object architecture with the UML notation, editors for the specification of the interactions in the form of state transition diagrams, editors for Java™ class implementations.
Interaction tree diagrams

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

An interaction tree diagram is conceptually a state transition diagram specialized to describe the interactive behavior of a session. In this diagram each elemental state is associated to a single page presented to the user, and transitions between states corresponds to events coming from user actions in the client tier (i.e. submitted requests). For convenience of implementation the whole interaction is split on three hierarchical layers:

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

  Communication with database is the lowest-level aspect of an enterprise application, and it represents a non-trivial issue in systems development. In common cases a relational database is used, and access is given to Java™ applications through a JDBC connection. But this technology doesn’t solve the “impedance mismatch” problem (see bottom note) that means it doesn’t implement a transparent mapping between objects and relational tables.

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.

From the architectural point of view, Persist offers a set of classes that represents the meta-level of data. In the meta-level resides the Data Definition Language (DDL) that allows the specification of the database schema. This level is also responsible for converting SQL types to specific database vendor types. Here is also treated the management of object identifiers and their mapping to table keys in the relational schema.

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.

  When data access supported by Persist is designed in our G++ integrated development environment, the code generation tool helps to produce the meta-level objects that can be used to automatically create the entire database schema.

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.

Please refer to for any problem regarding this page.
This page last updated on Nov 10, 2002.
Copyright © 1990-2000 SYCO S.a.s.