BOF-2368Restructuring a Web Application, Using Spring and Hibernate

Gustavo de Paula | gep@cesar.org.br

Devendra Tewari | dkt@cesar.org.br

Motivation

• C.E.S.A.R was hired to build a phonebook synchronization for a CDMA carrier in Brazil (July 2004) – VPBook1.0

• The client side should be developed in BREW• Initially target two different handset models

– Motorola V710 and Motorola C357

• Very tight schedule– From carrier requirements to deployment in 2 months!

• After first release, there were new requirements• We developed a VPBook 2.0 solution

Agenda

• Synchronization solution– Project requirements– Main problems

• New requirements• Problems to solve• VPBook 2.0 - New solution• Comparison metrics• Conclusion• Q&A

About C.E.S.A.R

• Recife Center for Advanced Studies and Systems• Most important innovation company in Brazil• 600 employees• Main clients are telecom companies (carriers and

handset manufactures)– Samsung– LG– Motorola– TIM– Bell South– Vivo

About the Speaker

• Speaker in conferences in Brazil, US and Europe• 8 years of experience in Software development• 6 years of experience in Mobile Application

Development• Holds and M.Sc. in Computer Science

VPBook 1.0

VPBook 1.0 - Synchronization solution

PhoneClient1

PhoneClient2

PhoneClientn

Virtual PhonebookWeb Server

...

HTTP Requests/Responses

WEB

Related to mobile devices.

...

Related to browsing interaction.

User1

User2

Usern

Mobile Web

Browsing

Data

Carrier Portal

VPBook 1.0 – Server Requirements

• Two actors: cell phone client and the web user• From the cell phone the user can:

– Synchronize its phonebook

• From the web the user can:– Insert contacts– Delete contacts– Edit contacts– Restore contacts from recycled bin– Change his password– Import other user’s phonebook

• Two way synchronization

VPBook 1.0 – Client Navigational Model

VPBook 1.0 – Server Navigational Model

VPBook 1.0 – Server Navigational Model

VPBook 1.0 – High Level Sequence Diagram

Cell PhoneCell Phone VPBookVPBook SyncSyncDatabaseDatabase

LoginLogin

Send Modified ContactsSend Modified Contacts

Identify what was Identify what was changed in the serverchanged in the server

Apply ChangesApply ChangesPhoneBook ChangesPhoneBook Changes

Apply ChangesApply Changes

Solve ConflictsSolve Conflicts

Read ContactsRead Contacts

LogoutLogout Commit ChangesCommit Changes

Check userCheck user

VPBook 1.0 System Architecture

Sync moduleContact Manager

DB Interface

DB Layer

DB

Carrier Integration

BREW App Web GUI

Carrier Portal

Components

• Carrier Integration– The user can login in the carrier portal– If the user has the phonebook synchronization service a link

is presented to him– When the user click that link it will call this component with

the user’s MIN

• Sync module– Servlets that receive requests from the BREW Application

(Login, logout, sync, etc.)’

• Contact Manager– Has all the services to manage the contacts from the Web

(insert, delete, edit). The Web GUI is implemented using Struts

Components

• DB Layer– All implemented using JDBC– A single class with 45 KLOC– Several operations to sync contacts

• DataBase– The DB used is PostgreSQL

Main Issues in the VPBook 1.0 System Architecture

• Performance– JBDC solution was not good– JBDC was not optimized in the first releases

• Synchronization rollback– Several problems to handle transactions– Some handset loose connection while synchronizing

(session handling control implemented in the application)

• New handsets support– The solution was not scalable to new handsets– Each new handset has a different phonebook format– The web GUI does not adapt to each handset

Main Issues in the VPBook 1.0 System Architecture

• The system facade was not well defined. – Bussiness logic both in the contact manager and in the

sync module and in DB Layer

• Hard to include new functions– Due to the tight schedule, the solution focus the two initial

handsets and the initial requirements– It was hard to adapt the solution to new requirements

VPBook 2.0

New requirements

• New carriers support• New handsets support

– BREW and J2ME

• Generic Solution– Sync client (not associate with an specific carrier)– Web client (not associate with an specific carrier)

• Include the concept of handset profile• Adapt Web GUI according to the handset profile• Transfer phonebook from different profiles• Include Administration Support• Solve performance problems

Solution – Spring

• Based in IoC pattern• Code uses the interfaces• All implementation classes

defined in XMLs

Spring is a layered J2EE application framework based on code published in Expert One-on-One J2EE Design and Development by Rod Johnson

Spring Main Modules

Spring live. Figure 1.1

Spring Main Modules

• Spring Core– Has all basic services. Implements the IoC and manage the

javabeans lifecycles

• Spring Web– Web oriented integration (multipart support, web context

and servlet listeners)

• Spring AOP (Aspect Oriented Programming)– AOP Alliance compliant implementation.

• Spring ORM (Object/Relationship Mapping)– Integration layers to ORM APIS (such as hibernate and JDO)

Spring Main Modules

• Spring DAO– JDBC Abstraction layer and transaction management

• Spring Context– Provides a way to access the beans in a framework-like

manner

• Spring MVC– Full MVC framework implementation for web applications

Spring – how we use it

Spring live. Figure 1.2

VPBook 2.0 System Architecture

VPBook Core

Sync Client Web Client

Admin Client

VPBook DB Layer

Struts

Struts

Struts

Spring

Hibernate

VPBook 2.0 System Architecture

• Use struts in the sync part instead of servlets• Use Tomcat session manager

– Handles login / sync / logout process

• Has a well defined facade with all the services that the clients will use

• Each carrier can define its own web client• Spring is used to

– Declarative transactions– Dependencies bindings between the components– Persistence support with hibernate

• All DB layer is implemented in Hibernate

VPBook 2.0 System Architecture Advantages

• Well Defined facade– Simpler sync client and web client

• Struts in the Sync Client– Simply server side

• Use of Spring– Simply the transaction control. Original version control the

transaction in the code– Made it possible to plug different implementations

according to the carrier

• Hibernate– Simplify the database implementation– Significant performance improvements

Comparison metrics

Old solution

New solution

Rate

Number of UCs 18 45 250% increase

Full project NCSS 7502 12089 61% bigger

Deployment Pack 3.463 MB 16 MB 462% bigger

DB access NCSS 2477 858 69% smaller

DB Performance Full Sync (Before JDBC improvements) *

30 secs. 1 sec. 30x faster

DB Performance Full Sync (After JDBC improvements) *

2 secs. 1 sec. 2x faster

*Not end-to-end

Conclusion

• Don’t implement a project like this is two months • Spring helped in

– Use of a well defined facade– Remove dependencies between the layers– Declarative transactions

• Hibernate helped in– Relational database independence – Lazy loading