White Paper:

1) Architecture Objectives: The primary objective of this architecture is to meet the following requirements (SLAs).

Scalability and High Availability

Modularity and Maintainability

Extensibility

Portability of technologies in each tier

Portability of databases

Portability of Application Servers

Rapid Application Development

2) Architecture Explanation This architecture is based on Java/JEE technologies with the following stack of

technologies/frameworks. But the frameworks in each tier of the architecture can be replaced with

other compliant/similar frameworks without affecting the other tiers.

JSF 2.x with RichFaces 4.x (including AJAX) for Presentation Tier

EJB 3.x for Business Tier

JPA 2.x with any ORM for Persistence Layer

JCA/JMS for Integration with External Systems(This is for future expansion when required to

connect with other external systems)

The following diagram illustrates various tiers used in the application architecture.

Figure1: Architecture Diagram

The application developed as per the above architecture is as per the JEE standards. So, it can be

deployed in all JEE compliant application servers which support clustering and load balancing.

These tiers make the application modular, extensible and maintainable along with the ability to be

deployed in clustered and load balanced environments.

Presentation Tier: All the presentation logic is encapsulated in this tier. This allows the business tier to remain unaffected to the changes in the presentation tier. This also gives the freedom in using

the technology of our choice for the presentation without affecting the business tier. And also,

separating the presentation from business gives the ability to support multiple client types; ex. Mobile

Clients, Desktop Clients and Web Service clients. The above architecture allows usage of any of the (and

any other applicable framework) frameworks to be used for the Presentation Tier.

Pure JSPs with/without Servlets

Pure Servlets with/without JSPs

Struts (This is what we have used in the CPSIA project)

JSF (This will be used in the Material Traceability Project)

Flex, etc.

Business Tier: The application/business functionality is implemented in this tier. The separation of business logic from presentation logic allows the business tier to be used/accessed by multiple types of

clients (Ex. Web, Mobile, Desktop, and Web Services). The architecture above allows usage of the

following technologies for implementing the business tier.

POJOs (This is what we have used in the CPSIA project)

RMI

EJB (This will be used in the Material Traceability Project)

Spring

Web Services

Integration Tier: This is the layer where the application interacts with external systems such as RDBMS, ERP, etc.

Mechanisms used to integrate with RDBMs are separated from mechanisms used to interact with ERP

systems such as SAP or Mainframes, etc.

To make it uniform to access any database, we have a choice of the following technologies.

JDBC (This is what we have used in the CPSIA project)

JPA with Hibernate (This will be used in the Material Traceability Project)

To make it uniform to access any other external systems (other than the RDBMS) such as ERP (ex, SAP or

Mainframes), the above architecture allows using JCA.

JMS allows asynchronous integration with various Messaging Middleware Systems.

3) Deployment Architecture: Following is the deployment architecture used in the application.

Figure2: Deployment Architecture.

The proposed deployment architecture makes use of clustering and load balancing techniques. The load

balancer distributes the concurrent client requests across various nodes in the Web Cluster. This is a

technique used to handle concurrent user requests. The clustering of nodes (Web Server and

Application) guarantees the high availability as if one node goes down, the load balancer stops sending

the requests to the dead node and will send the requests any other available node. As a result, we are

avoiding single point of failure situations.

Session Replication: The above architecture encourages applications to be developed for allowing the Session Replication. As a result, if a node goes down while in the middle of a request processing, the

load balancer can forward the request to another available node in the cluster. If session replication is

enabled, the new node can handle the request without even knowing there is a dead node in the

cluster.

Caching is one of the important aspects of this architecture which contributes towards good performance. Caching is one of the techniques by which we reduce the round trips to servers or

enterprise resources such as Databases or external systems. This reduced server round trips are one of

the several techniques to keep the response times under the desired minimum.

Cloud Based Deployment: applications designed and developed for JEE compliant servers can be easily deployed in closed based environments. This allows us to control the costs on hardware by

managing the hardware affectively between peak and off peak hours.

Separate Web Server and Application Servers: There are definitely benefits by separating the web and application layers. If the Web layer and Business Layers are deployed on different physical

machines, it allows the Web Servers not to worry about the traffic from Desktop and Mobile clients to

the Business Tier.

4) Benefits of Architecture: In this section we describe how the architecture proposed above meets the objects set.

Scalability and High Availability: Since this architecture is based on JEE standards, any application built using this architecture can be deployed in a clustered and load balanced environment

which can addresses the concerns around scalability and high availability. The increasing number of

concurrent users can be easily accommodated with the clustering and high availability is guaranteed

with the fault tolerant load balancing mechanism.

Modularity: Since the architecture is using the layered concept, it is highly modular and maintainable.

Extensibility: Using this architecture, we can support multiple types of clients. Currently, the architecture above is for a web based client. We can easily extent it for mobile based clients and

desktop based clients as well. The only difference to the architecture (in case if we have to support

Desktop and Mobile Clients), there will be separate Presentation Tier for each of those client types.

Portability of technologies in each tier: The architecture is designed such a way that each tier can use a technology of choice. The following shows the choice of various technologies/frameworks

for each of the tiers.

Presentation Tier Business Tier Integration Tier

Plain JSP & Servlets POJOs JDBC

Struts RMI JPA with

JSF Spring Hibernate/iBatis/Eclipse Link

Flex EJB JMS

and any other possible Web Services JCA

Portability of Databases: Any application developed using the above architecture when JPA is used as the Persistence Layer technology specification, it enjoys the portability across multiple database

engines without modifying any code. The usage of SQL Dialects along with the JPQL (Java Persistence

Query Language) makes it possible to swap databases without changing any code.

Portability of Application Servers: This architecture is based on JEE standards and no application server specific APIs are used. So, it is guaranteed to work on any JEE compliant application

server without making any source code changes.

Rapid Application Development: The various frameworks used in the architecture above are allowing faster development by eliminating the need for writing the boiler plate code repetitively. For

example, the usage of annotations in all the three tiers (Presentation, Business and Persistence) reduces

the amount of coding the developers have to write. It is providing the developer with a way to avoid

time spending in metadata configurations. With this architectural framework, it takes less than 10

minutes to implement a typical Create/Maintain use case with lots of functionality other than just

saving and retrieving the data to and from a data base.

5) Acronyms Used

Acronyms Used

AJAX Asynchronous JavaScript And XML

API Application Programming Interface

EJB Enterprise JavaBeans

ERP Enterprise Resource Planning

JCA Java Connector Architecture

JEE Java Enterprise Edition

JMS Java Messaging Service

JPA Java Persistence API

JSF JavaServer Faces

JSP JavaServer Pages

ORM Object Relational Mapping

POJO Plain Old Java Object

RDBMS Relational Database Management System

RMI Remote Method Invocation

SAP Systems, Applications and Products

SLA Service Level Agreement

XML Extensible Markup Language