SDL Proprietary and Confidential
SDL Proprietary and Confidential
WorldServer™
UI Framework
Overview
Jeremy Lemaire
-
jlemaire@sdl.com
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 UI
-
related 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
•
R
esearched 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
•
P
lotting 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
–
Struts
2
–
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
•
D
ynamically 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
–
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.
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
–
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 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. V
ery
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).
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,
i
nstead 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)
•
F
lexible
, 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
M
obile
A
pplications and SDL Gateway™
•
Less complicated build process. Do not need to link
legacy WorldServer
code
and
libraries with
new W
eb
F
ramework
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.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο