Transcript Refactoring the WorldServer UI Architecture and Technology

WorldServer™
UI Framework
Overview
Jeremy Lemaire - [email protected]
SDL Proprietary and Confidential
Problems to Overcome
• Must be a Java developer to do client side layout and creative design.
• Must be a creative designer to do server side work.
• There are no try-and-see (live class reloading) capabilities.
• Aging code base makes it difficult to adopt new web application
development technologies such as Ajax, HTML5, and CSS3 .
• Hinders the use of many modern software design strategies such as
Progressive Enhancement, Graceful Degradation, MVC, Cloud
Deployment, Horizontal Scaling.
Pitfalls and Tar Pits
• Idiom team moved towards a JSP-based UI by using the original Service
Desk as a test bed. They achieved a good user interface, but recorded
the following mistakes.
– Two code bases to maintain
– Service Desk UI architecture was not based on a web application
framework. It was messy and scaled poorly with increased
complexity.
– Communication between the UI layer and business logic was not
thought out.
– There were no facilities to manage JavaScript or any other web UIrelated technologies.
Proposed Architecture (SoC)
DaaS (Data as a Service)
• Leverage WorldServer’s existing Apache Tomcat implementation of Java
Servlets technology.
• Utilize standard HTTP protocol and JSON transport to access these
resources through asynchronous web calls.
• New WorldServer resources will be accessible from any authenticated
HTTP client, the most common endpoint likely being XMLHttp requests
(XHR) from a JavaScript enabled browsers or a proxied request from a
more sophisticated web framework backend.
Presentation Layer
• Updated pages and views means new development. Unfortunately there is no
magic bullet.
• But… use a Web Framework and get “free stuff”
– Separation of Concerns (SoC) via MVC or component architecture
– Templates
– Caching and Persistence
– Object-relational Mapping (ORM)
– Security
– Internationalization
– Automatic configuration
– URL Mapping
– Web Service access and deployment
– Community and professional service support
– Plugins to do much more
Which Web Framework?
Echo
Cocoon
Millstone
OXF
Struts
SOFIA
Tapestry
WebWork
RIFE
Spring MVC
Canyamo
Maverick
Jpublish
JATO
Folium
Jucas
Verge
Niggle
Bishop
Barracuda
Action Framework
Shocks
TeaServlet
wingS
Expresso
Bento
jStatemachine
jZonic
OpenEmcee
Turbine
Scope
Warfare
JWAA
Jaffa
Jacquard
Macaw
Smile
MyFaces
Chiba
JBanana
Jeenius
JWarp
Genie
Melati
Dovetail
Cameleon
JFormular
Xoplon
Japple
Helma
Dinamica
WebOnSwing
Nacho
Cassandra
Baritus
Stripes
Click
GWT
Which Web Framework?
• Most modern Web frameworks will provide a reasonable architecture.
• Most will help you
– manage session state
– support validation
– conversion of incoming request data
– provide security features,
– handle internationalization
– provide alternative configuration mechanisms.
Analogy:
Q: Which IDE do you use (Emacs, Eclipse, Vi, Visual Studio)?
A: There are lots of options. Simply choose the appropriate tool for the job.
The same rules apply when choosing a web framework.
Web Framework Evaluation Criteria
• Phase One – Narrow the Field
– Determined Popularity
• Researched the combination of page rank (obtained from
prchecker.info) and posting rate (obtained from gmane.org). This data
was used to calculate the relative popularity of this framework on the
web.
– Determined Long Term Viability
• Plotting the page rank data and looking at the slope of a graph to
determine the number of participants per day, an upward slope
indicating an increase in user adoption, a downward slope indicating a
decrease in user adoption. Frameworks with no change in user
adoption and no data were also factored in accordingly.
Phase One Results
• Popularity and Longevity (Ranked Most to Least Viable)
– Apache Wicket
– Grails
– Tapestry
– Rails
– Struts
– Stripes
– Struts2
– Spring MVC
– Seam
– Play
– Lift
Web Framework Evaluation Criteria
• Phase Two – The Test Drive
– Prototyped the top 3 frameworks found in phase one.
– In the interest of time only migrated the Home page servlet.
– Used a simple layout on the client side, providing just enough
coding and integration to get a solid feel for each framework.
• Static page transitions (navigation)
• Template tags (placeholders) to render data within a page
• Dynamically populate and refresh a simple AJAX driven
component
Web Framework Evaluation Criteria
• Evaluated Developer Comfort
– All WorldServer™ developers are
currently using the Java language.
Frameworks that are “Pure Java” were
weighted favorably.
• Evaluated Ease of Configuration
– Many WorldServer™ developers are
currently using Eclipse for their IDE.
Frameworks with Eclipse support were
weighted favorably.
• Evaluated Technical Features
– Templates
– Separation of structure/style, and
business/presentation layers.
– Live class loading
– Debugging and exception handling
capabilities
– Adaptability, modularity, and
extensibility
– Testability
• Lines of Code vs. Size of WAR (Considered
but not fully evaluated)
– To determine home much is done
automatically by the framework and
how much is required to be done by the
developer compare the WAR file size
and lines of code. This may also
identify code bloat.
Prototype Architecture
Phase Two Results – 3rd Place
Tapestry
– Java based component framework
– More specifications to maintain than other frameworks
– Steep learning curve.
– Uses Prototype JS and Zone tags. Not JS agnostic.
– Debug messages are cryptic and the stack traces resulting from
Java exceptions are buried in the controller logic.
– Bad track record with regard to backward compatibility. Tapestry 5
(the version evaluated) is supposed to change this. Confidence
level low among community.
– Widely adopted but too few contributors.
Phase Two Results – 2nd Place
Apache Wicket
– Very simple to setup . POJO’s make development very intuitive for
a Java developer.
– Lightweight
– Feature Rich. Built in components or roll your own with custom
JavaScript. Integrates well with Dojo and other JavaScript libraries.
– Fits well with our existing model, and is extensible.
– Good documentation, sparse tutorials.
– Latest (greatest?) component based model, not MVC.
– Very new. Not as well supported as others but fast adoption rate.
Phase Two Results – 1st Place
• Grails
– Plethora of plugins
– Java and JSP’s are interchangeable with
the .groovy and .gsp files and a quick
Google of a how to do a particular Java
concept with Groovy/Grails will return lots
of results. Very well supported.
– Groovy language is a pleasure for Java
developers (Pythonic)
– Integrates well with Dojo and other
JavaScript libraries. (JS agnostic)
– Learning curve steeper than Apache
Wicket but a Java developer can be
productive very quickly.
– Developers in Cluj are using Grails,
pleased with results, and they may be
working with us on this refactoring effort.
– Java based means any time you struggle
you can just fall back on the Java way of
doing things.
– The BeGlobal team evaluated Grails and
found performance issues on the order of
100ms. WS team saw conflicting results
(7ms).
– Easy to configure
– Well defined MVC design pattern fits well
with WorldServer (SoC) architecture.
Phase Three - Grails Performance
Test Setup – Grid (GORM Write) Test Case
– Populate a 43 column Dojo Grid with 5000 rows (12MB
uncompressed). Each row simulates all possible attributes
returned by the current WorldServer assignments_projects servlet.
This servlet was chosen because it has been identified as a
performance bottleneck for WorldServer customers (3-15 minute
page load).
– Unique row data is simulated on the server by getting the 32 bit
MD5 hash of the row attribute + row number. Minimizes ability to
do data compression.
– JSON data returned by the server is saved in the GORM and bound
to the grid using the Grails Dojo plugin. This data is retrieved once
when the page is refreshed.
Phase Three – Grails Performance
Test Setup – AJAX (GORM Read)Test Case
– An AJAX call is made when the refresh button is clicked. This
onclick event hits the Grails backend read closure which retrieves
the persisted JSON data from the Grails GORM layer. This JSON
data is rendered in a browser component.
Phase Three - Grails Performance
Hypothesis
• Based on other users experiences, assumptions were made that the
performance bottleneck for large datasets would be in the persistence
layer.
• Some effort was made to not use cycles serializing a bunch of data fields,
instead stored data in JSON blobs which could be read directly by
browser as JavaScript objects.
• True persistence will happen within WorldServer, as it does now.
Therefore only persist in memory within the presentation layer data
model.
• This enhancement may push bottleneck to the web service request or to
render phase of the transaction.
GORM Write Test Case Results
AJAX GORM Read Test Case Results
Grails Performance Demo
Performance Breakdown
WorldServer™ Architecture Diagram
2012 Roadmap Alignment
Meet Local
Deployment
Requirements
Meet Project
Creation
Requirements
Incremental
Migration Path
Established
SoC
X
X
X
X
• Can deploy locally as we do now insuring minimum impact
to current customers
• Meets the Q4 UX/UI enhancement requirements for the
Project Creation pages
• Incremental migration path established which allows for
rollback minimizing risk to stakeholders
• Progress towards full separation of concerns and well
defined design patterns positioning the product to be more
extensible and thus better aligned for future development
Alignment Beyond 2012
Various
Deployment
Options
Various
Client Types
Various
Scaling
Options
Distribution
of Workload
Modular
Testing
X
X
X
X
X
•
•
•
•
•
3-Tier Architecture Provides Various Deployment Options
• Less difficult to modify or replace any tier without affecting the other tiers.
• Separates the presentation tier allowing independent scaling and load balancing of
individual tiers
• Hardened security policies can be enforced within the server tiers without
hindering the clients. (Ex. Can put Tier-2 and Tier-3 behind a firewall and leave
Tier-1 in DMZ)
• Flexible, common architecture that aligns well with Cloud/SaaS solutions
supporting post-2012 initiatives.
Has a Web Service API which supports additional client types such as Native Mobile
Applications and SDL Gateway™
Less complicated build process. Do not need to link legacy WorldServer code and
libraries with new Web Framework code.
Can physically separate projects for easy distribution of workload to geographically
dispersed teams.
Aligns well across organization facilitating better knowledge share and consistent look
and feel.
Migration Phase
Migration Complete
Migration Complete
Questions?
Copyright © 2008-2012 SDL plc. All rights reserved.. All company names, brand names, trademarks,
service marks, images and logos are the property of their respective owners.
This presentation and its content are SDL confidential unless otherwise specified, and may not be
copied, used or distributed except as authorised by SDL.