SDL Proprietary and Confidential WorldServer UI Framework
Overview Jeremy Lemaire - [email protected]@sdl.com
Slide 2
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.
Slide 3
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 UI- related technologies.
Slide 4
Proposed Architecture (SoC)
Slide 5
DaaS (Data as a Service) Leverage WorldServers 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.
Slide 6
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
Slide 7
Which Web Framework? EchoCocoonMillstoneOXF
StrutsSOFIATapestryWebWork RIFESpring MVCCanyamoMaverick
JpublishJATOFoliumJucas VergeNiggleBishopBarracuda Action
FrameworkShocksTeaServletwingS ExpressoBentojStatemachinejZonic
OpenEmceeTurbineScopeWarfare JWAAJaffaJacquardMacaw
SmileMyFacesChibaJBanana JeeniusJWarpGenieMelati
DovetailCameleonJFormularXoplon JappleHelmaDinamicaWebOnSwing
NachoCassandraBaritusStripes ClickGWT
Slide 8
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.
Slide 9
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.
Slide 10
Phase One Results Popularity and Longevity (Ranked Most to
Least Viable) Apache Wicket Grails Tapestry Rails Struts Stripes
Struts 2 Spring MVC Seam Play Lift
Slide 11
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
Slide 12
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.
Slide 13
Prototype Architecture
Slide 14
Phase Two Results 3 rd 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.
Slide 15
Phase Two Results 2nd Place Apache Wicket Very simple to setup.
POJOs 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.
Slide 16
Phase Two Results 1st Place Grails Easy to configure Well
defined MVC design pattern fits well with WorldServer (SoC)
architecture. Plethora of plugins Groovy language is a pleasure for
Java developers (Pythonic) Learning curve steeper than Apache
Wicket but a Java developer can be productive very quickly. Java
based means any time you struggle you can just fall back on the
Java way of doing things. Java and JSPs 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. Integrates well with Dojo and other
JavaScript libraries. (JS agnostic) Developers in Cluj are using
Grails, pleased with results, and they may be working with us on
this refactoring effort. The BeGlobal team evaluated Grails and
found performance issues on the order of 100ms. WS team saw
conflicting results (7ms).
Slide 17
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.
Slide 18
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.
Slide 19
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.
Slide 20
GORM Write Test Case Results
Slide 21
AJAX GORM Read Test Case Results
Slide 22
Grails Performance Demo
Slide 23
Performance Breakdown
Slide 24
WorldServer Architecture Diagram
Slide 25
2012 Roadmap Alignment Meet Local Deployment Requirements Meet
Project Creation Requirements Incremental Migration Path
Established SoC XXXX 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
Slide 26
Alignment Beyond 2012 Various Deployment Options Various Client
Types Various Scaling Options Distribution of Workload Modular
Testing XXXXX 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.
Slide 27
Migration Phase
Slide 28
Migration Complete
Slide 29
Slide 30
Questions?
Slide 31
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.