WorldServer™

UI Framework Overview

Jeremy Lemaire [email protected]

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 Struts RIFE Jpublish Verge Action Framework Expresso OpenEmcee JWAA Smile Jeenius Dovetail Japple Nacho Click Cocoon SOFIA Spring MVC JATO Niggle Shocks Bento Turbine Jaffa MyFaces JWarp Cameleon Helma Cassandra GWT Millstone Tapestry Canyamo Folium Bishop TeaServlet jStatemachine Scope Jacquard Chiba Genie JFormular Dinamica Baritus OXF WebWork Maverick Jucas Barracuda wingS jZonic Warfare Macaw JBanana Melati Xoplon WebOnSwing Stripes

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 – 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

•

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.

– –

Debugging and exception handling capabilities Adaptability, modularity, and extensibility

–

Testability

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

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.

–

Separation of structure/style, and business/presentation layers.

–

Live class loading

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. 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).

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

X

Meet Project Creation Requirements

X

Incremental Migration Path Established

X

SoC

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

X

Various Client Types Various Scaling Options

X

Distribution of Workload Modular Testing

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.