sdl proprietary and confidential worldserver™ ui framework overview jeremy lemaire -...

Download SDL Proprietary and Confidential WorldServer™ UI Framework Overview Jeremy Lemaire - jlemaire@sdl.comjlemaire@sdl.com

If you can't read please download the document

Upload: roland-warner

Post on 23-Dec-2015

218 views

Category:

Documents


0 download

TRANSCRIPT

  • Slide 1
  • 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.