Transforming Legacy Systems to J2EE Architecture

Introduction

This document is a living reference document for anyone involved in the design and architecture for organizations to transform their legacy systems to Java 2 Enterprise Edition (J2EE) based applications.

This document also discuss about the software components that have been repeatedly utilized for developing applications. These components will provide the development team with tools to speed up implementation, ensure robust applications, and offer services and flexibility that would not have otherwise been possible.

The components fall into two categories: the primary components that have been explicitly mentioned to the architects, designers and build leads; and supporting components that are used by the primary components but will likely not be invoked directly.

Background

Every organization is reviewing its current internal applications with a view to move into J2EE world. Organization believes that J2EE based applications will enable them to successfully meet the current internal customer requirements and prepare them for future requirements. Organization has existing applications based on mainframe infrastructure. These applications are a combination of CICS, DB2 and MQ Series

Imperative

Organization is maintaining applications, which are about 20-25 years old. The maintenance of these applications is costly in terms of manpower.

Keeping the above imperative in mind, we discuss the approaches that organization can take to solve the problem.

The “Build from Scratch” approach

This is the “Maximum pain, maximum gain” approach. This approach proposes to build the whole application from scratch. This approach is based on the fact that reuse of the existing application may not be the best approach especially when business requirements change rapidly. Also, due to the fact that the logic has been modified a lot of time, further maintenance of such code is very difficult for the new team. Also, this approach proposes that internal customers will have newer requirements, which can be better handled by writing from scratch.

1. Organization can reap the benefits of J2EE from day one because this is not a force fit approach.
2. Maintenance of the new code will be easy.
3. Clean separation of user interface, business logic and database as per J2EE standards.
4. No vendor lock-in for web application server.

1. End users may not be happy with total revamp of the system.
2. It can be argued that the time frame will be long for a new system. However, conversely it can also be argued that typical migration projects of this scale also take a very long time and they do not give the same performance that one is used to.

The “Migration” Approach

This approach proposes the migration of the application in stages. This approach is based on the fact that one can reuse existing IT solution that has tried and trusted application logic. The J2EE platform gives you a multi-tiered distributed application model, the ability to reuse components, a unified security model, and flexible transaction control.

• Leverage the mainframe’s quality of service attributes for Java workloads
• Maximum platform choice and flexibility
• Consolidation of existing distributed applications
• Leading edge businesses are beginning to replace legacy mainframe applications with Application Server

1. The conversion from mainframe to J2EE is not a straight forward one and requires a good application design and development.
2. While the GUI looks entirely different, the JSP/HTML based forms do not give same client functionality that end-users are used to otherwise. Therefore, it can be argued that if there is a learning curve for end-users, the solution may as well be a new one.
3. The maintenance of above approach is fraught with difficulties for the organization IT team. The team would need the knowledge of J2EE as well as proprietary mainframe.

J2EE Architecture Using Application Server - The “Migration” Approach

J2EE is a multi-tiered distributed application model means the application logic is divided into components according to function, and you can install the different application components that make up a J2EE application on the same or different servers. Where an application component is installed depends on the tier in the multi-tiered J2EE environment in which the application component belongs. The tiers are defined below and depicted in Figure below.

The J2EE application model defines the following

1. Java 2 Enterprise Platform as the defacto standard for Java applications
2. New application deployments
3. Clustered application node
4. Server consolidation
5. Web Services enabling of legacy mainframe apps
6. Legacy application re-write to Java

Web Tier

At the highest level, the Web tier does four basic things in a specific order: interprets client requests, dispatches those requests to business logic, selects the next view for display, and generates and delivers the next view. Overall structure is the most important consideration in a Web-tier design.

Any web application and the various existing Web application frameworks implement some form of "Model 2" architecture, where a Servlet manages client communication and business logic execution, and presentation resides mainly in JSP pages. This section describes some strategies for the design and implementation of enabling legacy systems to J2EE

Events

This tier is used to handle user actions as events. Each HTTP request will be sent to a Web Component, usually a Servlet. Calls to some of these Web Components can be intercepted by a Filter.

Characteristics of the HTTP Request

1. Name-Value pairs of the submitted HTML form
2. Represents an Event
3. Has mandatory Event ID name-value pair

Servlet Filters

Filters are used to perform pre and post request processing operations. Filters can be chained with each filter performing a specific task

Operations

1. IP Validation
2. User Authentication
3. Session Validity
4. Control Component Availability

Servlets

Servlets act as the central controllers in the MVC design. The Servlet wraps the request in a special wrapper to shield the next layer of components from HTTP specific details.

Operations

1. Create common session variables if required
2. Wrap the HTTP request into a special wrapper
3. Delegate the request to Navigation Controller passing the special wrapper
4. Store the response from Navigation Controller in Request object
5. Forward the request to JSP page

Navigation Controllers

Each Navigation Controller is used by one Servlet and its function is to route all the requests for its Servlet to appropriate event handlers

Operations

1. Load all Event Handler classes at load time
2. Maintain a map of Event IDs and Event Handlers Classes
3. Look up Event Handler for incoming Event ID
4. Delegate the event handling to Event Handler
5. Return the Event Handler Response to calling Servlet

Event Handlers

Event handlers are the work horses of this Architecture and they do most of the event processing

Operations

1. Create and populate Event Info Bean from Request
2. Validate user entered data in Event Info bean, if required.
3. Handle the event by performing all the processing
4. Talk to Business Tier for business logic, if required
5. Create the view object for next display or delegate it to Helper
6. Return Event Handler Response to the calling Controller

Event Info beans

Event Info beans encapsulate request parameters in an event specific way. For each incoming parameter of interest, getters and setters are provided.

Characteristics

1. Java Bean encapsulating Name-Value pairs from the parameter special wrapper
2. Provides object representation of incoming data
3. Acts as an Input object for multiple Event Handler Helpers by implementing their respective Input interfaces

Event Handler Helper Input

Event Handler Helper Input interfaces are used by the Helpers (which create view objects on behalf of Event Handlers) to specify the parameters needed to successfully generate a view object

Characteristics

1. It is a java interface
2. Enforces the input required by the Helper to create a view object – usually, the Event Info object for the Event Handler (that delegates the creation of view object to the Helper) implements this interface and gets passed in to the Helper, thus providing the Helper with the information it needs

Event Handler Helper

Event Handler Helper are used to create the view object (to render JSP page) using the information provided in the Helper Input interface

View Objects

View Objects, contain the entire data that will be displayed and the path of the response (e.g., JSP) page that makes use of this view object to render display

Characteristics

1. Created by either Event Handler or Event Handler Helper
2. It’s a Java Bean used by JSP pages to generate HTML
3. It is a composite object made of other Java Beans returned by the Business Tier (see Business Tier Architecture for objects returned during business method calls)
4. Each View Object is used by one JSP page (1 to 1). Each View Object has the path of its corresponding JSP page, which is used by Servlet to render response (by forwarding the request)

Since each interaction between the components has a different purpose, the result of the requested operations are encapsulated in different types of response objects as Process Event Response, Event Handler Response and Event Handler Helper Response

Characteristics

1. Created by Navigation Controller, Event Handler and Event Handler Helper
2. Contains some common attributes like View Object, Errors, etc
3. Used as return values during communication between components

Business Tier

Business Tier provides a range of different services for the application to smoothly perform the business tasks.

Session Facade

Session Façades are the entry points to the business tier. Different facades exist for different modules, but have a common behavior

Characteristics

1. Gateway for requests coming to the Business Tier
2. Implement as Stateless Session Bean
3. Invokes Data Access Objects methods to form the response.
4. Delegates to Async Process Requestor for asynchronous processing submission
5. Delegate filing process to Filing Manager
6. Talks to Failure Recovery System to report and process asynchronous processing failures
7. Returns the result in a Status object

DAO

All the database access is done by the DAO’s. They host the SQL statements that are used to query, insert, update and delete from database

Operations

1. Knows the exact structure of the database – encapsulates the database structure (tables names, column names etc)
2. Forms SQL Statements to query/update database based on the requests
3. Uses DB Manager to access database

Async Process Requestor

For time consuming processes that can take place in the background, like some database updates, asynchronous processing is used. Async Process Requestor encapsulates the process of submitting requests for asynchronous processing

Operations

1. Creates a Request Object that wraps the data to be sent along with other optional information
2. Sends the Request Object to a Message to MQ

Message Driven Beans

MDB’s are used to receive asynchronous messages originally submitted by other business-tier components. The MDB’s in turn call other components to process the message

Payment Manager

Payment Manager encapsulates the online processing of payments using credit cards. Third Party Payflow system is used to securely process payments

Operations

1. Processes credit card payments in real time
2. Communicates with Third Party Payflow system for payment processing
3. Accepts Payment Object as input
4. Updates Payment Object with the result of payment processing

Failure Recovery Service

Failure Recovery Service is used to store failed requests as objects, display the status to user, resubmit the request and finally notify to vendor

Operations

1. Use File System Object Persister to store failed requests as object in the file system
2. Returns a list of errors and unrecoverable errors for each user
3. Notifies unrecoverable errors to Vendor when user selects the option in the screen

File System Object Persister

To address any failures in asynchronous processing, the Failure recovery system is used. File System Object Persister is part of it

Operations

1. Saves filing objects passed by Filing Manager when Async processing fails under failurerecoveryONLINE
2. INTERNAL filing failure, first time errors – failurerecoveryINTERNAL<USERID>errors
3. INTERNAL filing failure, errors when resubmitted – failurerecoveryINTERNAL<USERID>unrecoverableerrors

EAI Tier

In most practical settings, the EAI tier design happens mostly with the help of legacy systems, existing infrastructure and reuse of existing systems.

Mainframes are used today because of

• Reliability, serviceability and fault tolerance (availability) – the hardware in a mainframe has built in self-checking and self-recovering, and can seamlessly recover from errors
• Scalability – mainframes have an architecture that is highly optimized with dedicated processors for OS tasks and a very high I/O bandwidth. It is difficult to beat a mainframe in terms of performance for large batch jobs or loads with a very large number of concurrent users.

The introduction of an EAI Tier helps in that:

• It centralizes control and provides a common integration platform
• It makes necessary functionality widely available to all clients
• It allows to implement functionality that otherwise would be very difficult to provide (e.g., transactions)
• It is a first step towards dealing with some forms of application heterogeneity and integration.

ID Generator

Any migration application is a phase-wise replacement of an existing system; the most commonly used is the id generation process of the COBOL/CICS programs to generate ids for tables that are common to multiple processes

Operations

1. ID Generator: Used by Filing Manager and DAO’s to generate unique ids
2. Communicate with a special interfacing CICS program via MQ
3. The CICS program in turn invokes the unique id generating programs
4. Can be used to generate work order numbers, filing numbers, etc.

Business Processing – A Case Study

Filing is the central business concept for state government offices. A Filing Manager encapsulates the processing of these filings

Operations

1. Encapsulates the filing process in the application
2. Accepts Filing object as input
3. Synchronous operations: Performs business rule validations, payment processing, essential database updates and submits request for asynchronous processing of filing process
4. Asynchronous operations: Invoked to process asynchronous operation by MDB’s, the Filing Managers perform the required processing and database updates

Because of the differences in the online and in-house processes, different Filing Managers are used to process online and in-house filings.

• INTERNAL Filing Manager is used for in-house filing
• ONLINE Filing Manager is used for processing online filings – by external users

Usage Scenario – Process Model

1. Select Business screen needs to be displayed as a result of search by Business ID or Name from three different screens.
2. The logic of assembling View Object (used to render JSP page) for Select Business screen can be separated out in a Event Handler Helper

Usage Scenario – Component Interaction

1. Filing Inquiry Search Event Handler, Add Business Search Event Handler and Business Inquiry Search Event Handler, each can delegate View Object creation for Select Business screen to Select Business Event Handler Helper

Usage Scenario – Sequence Diagram

Conclusion

As this article demonstrates, the support for resource injection such as Servlets, Servlet filters, event handlers and tag library tag handlers in the web tier makes accessing resources from web applications significantly easier.

The architecture offers plenty of valuable new features and solutions to many long-standing problems. The development team can easily transform and integrate the existing legacy systems with the Java, J2EE, and EJB-based applications using the application architecture and the integration strategy described above.

Author’s Bio

You can email Anand at [email protected]

Raghuram Bharatwaj Chandrasekaran is a senior architect at PCC Technology Group, LLC. Along with the completion of various certifications with Microsoft, Sun & BEA, Raghu has consulted at a technical level on customer projects involving J2EE, IBM WebSphere, BEA WebLogic and performance management. Raghu has published several technical papers in oracle magazine and BEA dev2dev magazine.

You can email Raghu at [email protected]