![BOF-2368 Restructuring a Web Application, Using Spring and Hibernate Gustavo de Paula | [email_address] Devendra Tewari | [email_address]](https://image.slidesharecdn.com/refactoringd3-12716952561221-phpapp01/85/Restructuring-a-Web-Application-Using-Spring-and-Hibernate-1-320.jpg)
Restructuring a Web Application, Using Spring and Hibernate
- 1. BOF-2368 Restructuring a Web Application, Using Spring and Hibernate Gustavo de Paula | [email_address] Devendra Tewari | [email_address]
- 2. 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
- 3. Agenda Synchronization solution Project requirements Main problems New requirements Problems to solve VPBook 2.0 - New solution Comparison metrics Conclusion Q&A
- 4. 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
- 5. 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
- 6. VPBook 1.0
- 7. VPBook 1.0 - Synchronization solution Phone Client 1 Phone Client 2 Phone Client n Virtual Phonebook Web Server ... HTTP Requests/Responses WEB Related to mobile devices. ... Related to browsing interaction. User 1 User 2 User n Mobile Web Browsing Data Carrier Portal
- 8. 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
- 9. VPBook 1.0 – Client Navigational Model
- 10. VPBook 1.0 – Server Navigational Model
- 11. VPBook 1.0 – Server Navigational Model
- 12. VPBook 1.0 – High Level Sequence Diagram Cell Phone VPBook Sync Database Login Send Modified Contacts Identify what was changed in the server Apply Changes PhoneBook Changes Apply Changes Solve Conflicts Read Contacts Logout Commit Changes Check user
- 13. VPBook 1.0 System Architecture Sync module Contact Manager DB Interface DB Layer DB Carrier Integration BREW App Web GUI Carrier Portal
- 14. 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
- 15. Components DB Layer All implemented using JDBC A single class with 45 KLOC Several operations to sync contacts DataBase The DB used is PostgreSQL
- 16. 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
- 17. 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
- 18. VPBook 2.0
- 19. 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
- 20. 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
- 21. Spring Main Modules Spring live. Figure 1.1
- 22. 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)
- 23. 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
- 24. Spring – how we use it Spring live. Figure 1.2
- 25. VPBook 2.0 System Architecture VPBook Core Sync Client Web Client Admin Client VPBook DB Layer Struts Struts Struts Spring Hibernate
- 26. 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
- 27. 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
- 28. Comparison metrics *Not end-to-end 69% smaller 858 2477 DB access NCSS 30x faster 1 sec. 30 secs. DB Performance Full Sync (Before JDBC improvements) * 2x faster 1 sec. 2 secs. DB Performance Full Sync (After JDBC improvements) * 61% bigger 12089 7502 Full project NCSS 462% bigger 16 MB 3.463 MB Deployment Pack 250% increase 45 18 Number of UCs New solution Rate Old solution
- 29. 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