UI Framework Overview

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.