February 2007 Discussion Introduction This document is a living ...

spinabundantInternet and Web Development

Jul 30, 2012 (4 years and 10 months ago)

170 views




February 2007


Discussion


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, des
igners 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. Organizati
on 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.

Advantages

1.

Organization can reap the benefits of J2EE from day one because this is not a force fit
approach.

2.

Maintenanc
e 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.

Disadvantages

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

T
his 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 mo
del, the ability to reuse
components, a unified security model, and flexible transaction control.

Advantages



Leverage the mainframe’s quality of service attributes for Java workloads



Maximum platform choice and flexibility



Consolidation of existing distr
ibuted applications



Leading edge businesses are beginning to replace legacy mainframe applications with
Application Server

Disadvantages

1.

The conversion from mainframe to J2EE is not a straight forward one and requires a
good application design and develop
ment.

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 n
ew 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
ap
plication 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 Tie
r

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 c
onsideration 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 ma
inly 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 perfor
m 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.

Delegat
e 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 p
arameter 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 us
ed 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
forward
ing 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 Hel
per 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 p
rovides 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 proce
ss 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 acces
s 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 paym
ents

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
failurerecovery
\
ONLINE

2.

INTERNAL
filing failure, first time errors


failurerecovery
\
INTERNAL
\
<USERID>
\
errors

3.

INTERNAL filing failure, errors when resubmitted


failurerecovery
\
INTERNAL
\
<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
-
r
ecovering, 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 l
arge batch jobs or loads with a very large
number of concurrent users.

The introduction of an EAI Tier helps in that:

o

It centralizes control and provides a common integration platform

o

It makes necessary functionality widely available to all clients

o

It allo
ws to implement functionality that otherwise would be very difficult to
provide (e.g., transactions)

o

It is a first step towards dealing with some forms of application heterogeneity
and integration.

ID Generator

Any migration application is a phase
-
wise re
placement 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 centra
l 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 valid
ations, 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 da
tabase 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 on
line 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 Objec
t 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 i
ntegrate 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

Anand Balasubramanian has specialized in architecting and managing software
projects for
numerous customers in the state and federal governments as well as commercial sectors for
the last nine years. He has architected & published an XML API guide, to extend the J2EE
application to IVR, Pocket PC and WEB. He was the first to archi
tect and implement the
J2EE solution using the published XML to allow retail shops to use Windows Wireless
Pocket PC devices over http to perform retail transactions using IBM WebSphere in the Year
2001. His current contribution is towards the success and
progress of a concern called PCC
Technology Group, LLC where his role as a project manager is indispensable.

You can email Anand at
anand.bala@pcctg.com

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 publi
shed several technical papers in
oracle magazine and BEA dev2dev magazine.

You can email Raghu at
raghuram.chandrasekaran@pcctg.com