Conversion of an Existing Web application

1
Conversion of an Existing Web application
Jan. 15th A real world example in J2EEh 2nd, 2001
2
Abstract

• This presentation talks about an approach taken
  to the migration of an existing 2 tier Java web
  application to a full fledged J2EE application
  implementation.

3
Application History

• Large telecomm residential service application
• Great deal of dynamic content (signup, account
  maintenance, etc)
• Implemented specifically around 2 tier
  architecture
• Existing application communicated directly to
  database from Servlets/JSPs
• Application had been in production for 2 years at
  time of conversion
• Undergone multiple upgrades/migrations around
  current architecture

4
Reasons for migrating to 3 tier

• Application usage ballooned
• General public along with thousands of employees
• Functionality was expanding (reverse call-lookup)
• Application and infrastructure security became a
  concern
• Common enterprise infrastructure architecture
  established to help administration of applications

5
Previous Infrastructure
6
New Infrastructure
7
What we were given

• An environment
• A web and application server in a development
  environment
• WebLogic Server
• Adopted as standard application server in the
  enterprise
• A release date

8
Migration issues

• Limited time constraints to migrate
• Development, test, and production hardware was in
  place, but unused
• Great deal of SQL written within the existing
  Servlets
• No REAL object model Data returned as
  String
• Had to find way to minimize changes to
  JSPs/Servlets
• Little or no J2EE experience within rest of
  development team outside of JSP/Servlet

9
Plan of Attack Pre-Migration

• Identify functionality that logically mapped to
  J2EE components
• Find logical bounds between business and
  presentation logic
• Logically group related business functionality
  into common service
• Identified functionality for EJB services and JMS
  services
• WLS was only application server at the time that
  bundled both

10
Pre-Migration

• Mapped asynchronous functionality to JMS
  producers and consumers
• Functionality such as user navigation tracked
  through JMS to database
• Mapped data driven portions of pages to an EJB
  service to provide that data
• 1 to 1 mappings of object that provided service
  in web container to an EJB

11
Example
Maps to
12
Example Mappings

• DatabaseProxy Forwarded existing SQL statements
  through to an EJB to execute the SQL on the
  application server tier
• CallLookupService Queried external service on
  address origin of phone numbers (socket client)
• StatementService Queried internal service for
  data to display on-line bills
• ActivityService Created and inserted user
  navigation of site onto JMS queue

13
Migration Plan

• Identified the most simple and difficult
  functionality
• Encapsulated most simple functionality within an
  EJB first, in order to work through distribution
  issues
• Used lessons learned on first bean to facilitate
  migration of most complex functionality to EJBs
• Maintain exact same interface as previous
  component to reduce impact on the system
• All identified services/components mapped into
  stateless session beans

14
Migration Plan

• Create JDBC objects to perform database
  interaction within service, if needed
• Done to lessen impact of creating and
  incorporating Entity Beans
• JDBC objects could be created by developers who
  knew nothing about EJBs
• Existing JDBC easily moved to these objects
• Entity Beans could be incorporated later after
  environment stabilized

15
Component Deployment - Before
16
Component Deployment - After
17
Results

• Initial Migration was successful (first
  application in environment)
• Initial migration was very taxing on network and
  WLS
• Initial configuration
• WLS 5.1.0.8
• Heap 96 MB (initially an issue)
• JMS message persistence turned off
• Native Performance Pack
• Oracle type 4 drivers (version 1.2 against 8.1.7)

18
Results - Relevant Statistics

• Average page made 4 round trips from web
  container, to EJB container, to database Per
  client request

19
Results - Statistics cont.

• Each round trip allocated a database connection
  and half of the time a transaction
• In Load testing, WLS allocated and de-allocated
  approx. 48 database connections/sec while
  servicing 20,000 DB requests over 7mins (40
  connections in pool)
• Single web server to single app server
  environment
• 1 million hits a day averages out to 12 hits/sec

20
Post Migration Plan

• Replace old Database service with multiple
  logical services around application logic
• Ex. Removed multitude of SQL statements passed
  through DatabaseProxy EJB which executed JDBC
  directly and built AccountService around all
  functionality related to customer accounts

21
Post Migration Plan

• Designed and incorporated an object model into
  application after stabilization
• Ex.

22
Post migration - Object Model

• Decreased network traffic and load on application
  server
• Provided typical OO benefits to the application
  (reuse, logical data manipulation, etc)
• Manipulate CustomerAccount object to get Customer
  and Account related data instead of a large
  String with Customer and Account data within
  rows and columns (quasi ResultSet)

23
Post Migration Entity Bean Mapping

• Identified and laid out model of Entity beans
• Mapped many of the JDBC object used within the
  Session Beans to Entity Beans.
• Combined certain JDBC object to give more coarse
  grained Entity Bean

24
The Good, The Bad, and The Ugly

• Looking at what went well,
• did not go well,
• and what worked but was not pretty

25
The Good

• Approach to distribution. Initial approach to
  moving DB and other service access to EJBs went
  very well
• Performance and learning curve of WLS
• Approach would not have been possible without
  performance
• Reduce learning curve of developers in the new
  environment
• EJBs named similarly and performed same
  functionality as objects they replaced

26
The Bad

• Environment Management
• Had to maintain two separate environments during
  this time
• Certain new functionality was missed on
  incorporation
• Application Design Documentation
• No time/tools to formally document design with
  UML or any other means.
• Education of development team on J2EE

27
And the Ugly

• Architectural Model
• Tough on products and infrastructure

28
In the end

• The overall management goals were met
• Application performance was acceptable
• Mostly due to WLS and hardware infrastructure
• Application was able to be enhanced in phases to
  become more compliant with recommended J2EE
  application design
• Incremental incorporation of domain object model,
  Entity Beans, and thinning of presentation layer

29
Questions??