This was a reengineering project for one of the largest credit bureaus in the USA.

Client Profile

The Client is a division of one of the leading credit bureaus in the USA and has served the needs of the real estate industry for over 100 years. They have evolved as the premier provider of information and service by supplying highest quality products through long-term strategic relationships with their customers.

They have approximately 40,000 customers and are located all over the US and Canada. These customers process approximately 30,000 orders per day. The Client operates from 11 office locations where over 400 users access the system. These users enter new orders as well as offer customer service on the processed reports.

Business objectives

The challenge centred around the need to 'Web enable' their existing Informix 4GL based system, which is supporting today over 300 concurrent users from (12 offices located all over USA) at any given time. The objective: to build the application on "anywhere, anytime" philosophy. This called for increased flexibility and ease of use for their office employees. The other goals were to integrate the application with a proprietary workflow solution.

The Informix 4GL applications have been running for years and have served its purpose. To retain the robustness & solidarity, the client opted to keep the backend applications untouched, & externalising the 'User Interface'. The major concern was to solve the 'Reverse Maintenance' problem, created on account of presence of two different GUI's - Informix 4GL and Web.

In short: A solution, which is easy to use, efficient, and cost-effective.

Scope of work

We played a key role from the beginning in deciding the 'Architecture' of the total solution. Having laid down a broad solution strategy, a set of tools were identified. A 'proof-of-concept' pilot was done to nail down various concerns and issues in developing and deploying the solution.

The tools and technologies used are as follows:

Front End: Browser based with HTML, JavaScript combination
Middle Tier: iPlanet V4.1 as Web Server running on Sun Solaris, WebSphere Version 4.0 as Application Server running business components developed in Java.
Messaging layer: The application interfaces with the Informix backend application using MQ Series messaging architecture.
Database Layer: Oracle 9i as the database server.
Back End: The backend is Informix ESQL/C system running on AIX RS 6000 Servers with Informix as the Database.

Approach

The application uses layered service based N-Tier architecture.

Tiers are defined as the deployable entities that make up the physical system. The system is partitioned into five logical tiers namely, Client, Presentation, Business, Infrastructure, and Resource.

The Client tier provides the user interface. The Presentation tier renders the data for the user interface. The Business tier provides the application services needed to carry out the processes and logic of the system. The Infrastructure tier provides access to technical services needed by the system. The Resource tier provides data manipulation techniques, and mechanisms. Similar to layers, a tier provides a separation of concern between each piece of the system. This allows, for example, different user interfaces to exist without having to change business logic or program code. Further, each logical tier may be deployed physically to multiple boxes to provide load balancing, fault-tolerance and fail-over without affecting the structure of the overall system.

A service encapsulates a business or infrastructure need. This encapsulation is expressed as a well-defined set of API's that form a contract for other components in the system to access. Within J2EE, services are typically expressed as session bean facades. By defining services, the following benefits can be derived:

• Coherent API set
• Decouples the component usage from the implementation details
• Reliable implementation of key infrastructure pieces
• Services can be easily moved around in the deployment environment to meet performance, load and fault-tolerance needs.

The sequence diagram of the system

Architecture Diagram