Java Edge.2008.Web.Frameworks.Catagorized
- 2. Agenda 2
- 3. Agenda • Introduction • The evolution of WAFs • Welcome to the jungle • Categorizing by example • Comparison • The future 3
- 4. 4
- 5. Introduction # define “Ask nine developers for a definition of components, and you will get eighteen opinions” Java Frameworks and Components-Accelerate Your Web Application Development 5
- 6. Introduction What is WAF? • A reusable, skeletal, semi-complete modular platform that can be specialized to produce custom web applications • A set of supporting libraries, scripting languages, services and interfaces that provide a skeletal structure for an application • Makes application development easier, faster by supplying pre-built parts 6
- 7. Introduction Why use WAFs? • Focus on solving business problems • Code higher levels of abstractions • Reduce time, effort & resources • Avoid reinventing the wheel • Reduce Technology churn & risk • Avoid lock-in to on proprietary dead end architecture • OSS is based on commonly accepted standards • WAFs are tested and continuously refined • Base on commonly accepted standards • Easily deployed within existing enterprise infrastructures 7
- 8. 8
- 9. Evolution 9
- 10. Evolution :: Technology “ New APIs appear because developers discover limitations in existing languages and tools. ” MVC (Xerox) HTML d 1980 1991 10
- 11. Evolution :: Technology • 1995 – CGI (Common Gateway Interface) • Standard for interfacing external applications with web servers • Provides a dynamic web page that reflects user inputs • Starts a separate process for each request • Resource intensive, does not scale well MVC (Xerox) HTML d 1980 1991 11
- 12. Evolution :: Technology • 1997 - Servlets • Java's CGI abstraction • Java code that extends functionality of a web server • Receives a request and generates a response MVC (Xerox) HTML d 1980 1991 12
- 13. Evolution :: Technology • 1998 – JSP (JavaServer Pages) • Embed Java code, directives & actions in markup • Compiled & converted to a Servlet • Extend static content with standard / custom tag libraries MVC (Xerox) HTML d 1980 1991 13
- 14. Evolution :: Technology • 2005 – Ajax (asynchronous JavaScript and XML) • Web development techniques (XHR, DOM, JS, JSON) • Used for creating interactive web applications / RIA • Communicates with a server in the background • Does not interfere with the current state of the page MVC (Xerox) HTML d 1980 1991 14
- 15. Evolution :: Technology Britney Spears, Circus Album Released November 28, 2008 15
- 16. Evolution :: Architecture MVC (Model View Controller) • First described by Xerox (1980) • A design pattern for separating concerns • Model – data, business logic • View – UI, data representation • Controller – mediates between model and view • Changes in view / model don’t effect each other • Separation of development roles Model State State Query Change Change Notifications View Selection View Controller User Actions 16
- 17. Evolution :: Architecture MVC in WAF • Controller • Processes request • Handles navigation logic • Interacts with the business logic • Populates the model • Model • Contains the data needed to render view • View • Pulls data from model • Renders the response 17
- 18. Evolution :: Architecture MVC Model 1 • Request and response are handled by same component • JSP is Controller + View • The good • Simple to implement • Development-deployment cycles are short • The bad • Hard to maintain / test / reuse - mish-mash of markup and code • Hard to manage work flow request JSP JavaBeans Browser Data (View) (Model) response 18
- 19. Evolution :: Architecture MVC Model 2 • A Servlet functions as a controller • Processes requests • Initiates business operations • Handles control flow • Decoupling of application flow from presentation • Better separation of responsibilities (developer / designer) • No business logic in view • Not dependent on JSP request create/ Servlet update (Controller) dispatch JavaBeans Browser Data (Model) JSP (View) access response 19
- 20. 20
- 21. Welcome to the jungle Overview • A plethora of Java web frameworks has evolved • Each has its special design concept, advantage and disadvantage • It often takes months to learn a new framework • It becomes increasingly difficult to choose the right framework to use 21
- 22. Welcome to the jungle web 22
- 23. Welcome to the jungle Why so many? • No standards for application architecture* • Only standards for low level abstractions (Servlet, JSP) • J2EE blue prints suggestion (2002) • OSS attempted to fill in the gap • No coordination / knowledge sharing • No framework is perfect for all scenarios • Every framework has pros & cons • Technology Trends / Tipping point • Personal Taste / “Feel” • Developers have different preferences * JSF (2004) was a first attempt for standardization 23
- 24. 24
- 25. Let’s categorize 1. Request / Response Oriented • What is your request / response? 2. Components Oriented • Write like desktop deliver over web 3. SOUI / SOFEA • New trend in town: “fat client” meets SOA 25
- 26. 26
- 27. Request / Response frameworks Key characteristics • Similar to CGI specification • Low level of abstractions • Controllers and actions handle requests directly • Requests are stateless • Server side sessions -> statefullness • Logic is mapped to URLs • Actions are mapped to pages • URLs determines page flow • Common Design Patterns • Front Controller, Command 27
- 28. Request / Response frameworks Architecture Controller execute request Request FrontServlet Processor Action / Command forward Browser fill with get business response business data date JSP JavaBeans View Model 28
- 29. Request / Response frameworks • Advantages • Simple - low entry barrier • Fast learning curve • High popularity • Easy visualization of markup • Disadvantages • Limited UI controls • Hard to maintain work flow • Low level abstraction • Low reusability • Procedural 29
- 30. Request / Response frameworks Examples: •Spring MVC •Struts 2 •WebWork 30
- 31. Request / Response frameworks Example: Spring MVC • Overview • Integrates with the Spring container • Not a full-stack web framework • Based on a Servlet “Front Controller” • Specific controllers are invoked to handle request • Promotes a clean separation of responsibilities (MVC) • Low abstraction interfaces are coupled to the Servlet API 31
- 32. Request / Response frameworks SpringMVC: Architecture Handler Mapper HandlerInterceptor Controller ` Controller Controller Front Controller Browser Controller (Dispatcher Servlet) ModelView ModelView JavaBeans View JavaBeans JavaBeans template View Model 32
- 33. Request / Response frameworks SpringMVC: Advantages • Highly flexible • Many parts of the framework are pluggable • No restriction to use framework functionality • Strong REST foundations • URLs are mapped to controllers • Wide choice of view technologies • JSP / FreeMarker / Velocity • Easy testing • DI of mock classes • Lightweight environment • Build enterprise-ready applications using POJOs 33
- 34. Request / Response frameworks SpringMVC: Disadvantages • Comes with very little out of the box • No Ajax support • Too flexible - confusing • Same task can be accomplished in different ways • Configuration • A lot of XML files • Dependency on Spring framework • Developers must understand Spring concepts 34
- 35. 35
- 36. Component frameworks Key characteristics • Abstraction • Hides the internals of the request handling • Encapsulation • Components handle their state and behaviour • Components are responsible to render themselves • Component tree (composition) • Event driven • User actions translated into messages • Messages are dispatched to the components • Similar to desktop GUI toolkits • Common Design Patterns • Composition, observer, factory, dependency injection 36
- 37. Component frameworks Architecture View Technology Component Tree Markup Root <root> <panel> Panel <panel> <label/> Username <textField/> Password ... </panel> Panel ... Button Submit <button/> </panel> </root> Label TextField 37
- 38. Component frameworks • Advantages • Object-oriented • Advocates reuse • Rich component libraries • Familiar to desktop application developers • Disadvantages • Complexity • Hard to customize components • Scalability 38
- 39. Component frameworks Examples: • Wicket • JSF • Tapestry 39
- 40. Component frameworks Example: Apache Wicket • Overview • Open source, contributed to Apache in 2007 • Swing like coding • Components are: • created in java • composed into a component tree • rendered into HTML markup • Java widgets are bound to markup using “wicket id’s” • Reuse HTML like Java 40
- 41. Component frameworks Wicket: Architecture awt.Component Component Swing Wicket awt.Container WebComponent MarkupContainer awt.Window JContainer Label Page WebMarkupContainer awt.Frame JComponent WebPage Panel Link JFrame JPanel JLabel JButton 41
- 42. Component frameworks Wicket: Architecture HTML <> … Username <input Password type=”button” wicket:id = Submit ”submitBtn”/> ... receives renders input Component Id=submitBtn View Controller consults updates Model 42
- 43. Component frameworks Wicket: Advantages • Fast learning curve • Simplicity / familiarity with Swing & OOP • Clean templates • Code centric – develop in Java • Harness OOP power • IDE & tools support / refactoring • Rich component library • Component composition and reuse • Self contained • Custom components made easy 43
- 44. Component frameworks Wicket: Disadvantages • Maintainability • Java <--> HTML sync. • HTML is scattered across pages • Complex internals • API is big • No structured “best practices” • No client side validations • Not suitable for dynamic pages • No central flow management 44
- 45. 45
- 46. SOUI / SOFEA frameworks SOUI / SOFEA frameworks • SOUI – Service Oriented User Interface • “MVC is dead”, 2007, Nolan Wright and Jeff Haynie • Appcelerator • SOFEA – Service Oriented Front End Architecture • “Life above the Service Tier “, 2007, Prasad, Rajat Taneja and Vikrant Todankar • Thin Server Architecture Working Group 46
- 47. SOUI / SOFEA frameworks SOUI / SOFEA frameworks • Overview • An architectural style for designing the presentation tier • Presentation tier is moved from server to client • MVC is implemented in client • Backend is SOA architecture 47
- 48. SOUI / SOFEA frameworks Thin client application architecture • Server (presentation layer) • Serves web pages (application download) • Drives application flow • Manages data interchange: Client browser <-> business layer View • Client (browser) • Renders and displays markup Web Framework View Controller Model Server 48
- 49. SOUI / SOFEA frameworks Thin client application flaws • Data interchange is not structured • String name / value pairs • No types / no data constraints • Tight coupling of presentation flow & data interchange • Presentation flow is driven by request (GET / POST) • Every request forces a presentation flow • “Back button“ problem • Not real MVC • Controller does not notify view of changes in model • Limited interaction • Peer-to-peer not supported 49
- 50. SOUI / SOFEA frameworks SOUI / SOFEA: Principles Web Client • Decouple presentation tier Framework • Application download View Controller • Presentation flow • Data interchange • Presentation flow must be driven by client Server / Service • Client sate must be managed in client Model • “Front Controller” is an anti-pattern • Support for rich data structures • No HTML (XML / JSON) • No more object <-> string conversions 50
- 51. SOUI / SOFEA frameworks SOUI / SOFEA: Principles - continued • MVC in presentation tier • Controller manages: client state, flow, data interchange • Eliminate server side driven presentation • Separate client and server concerns • Client is responsible for the view • Server is responsible for services 51
- 52. SOUI / SOFEA frameworks SOUI / SOFEA: Motivation • Separation of responsibilities • Server-side developer can focus on business logic • Less complex applications • Client is developed separately • Improved protocol • REST / SOAP to interface with SOA • Maximize decoupling • Client is independent of models & implementation technologies 52
- 53. SOUI / SOFEA frameworks SOUI / SOFEA: Model • Download server (web server) • Enables application download • Application container • Application is downloaded and runs in client container • Browser / JVM / Flash runtime • Service Interface • Web services • Data interchange • XML/JSON enforce data structures, types & constraints • Simple message-based contract 53
- 54. SOUI / SOFEA frameworks Architecture Presentation Flow Application (PF) Download Download Application Container (AD) Server Model Controller SOA Business Services View REST Intenet Client Application Data SOAP Interchange (DI) Service Interface 54
- 55. SOUI / SOFEA frameworks SOUI / SOFEA: Advantages • Cleaner architectural model • Decoupling of presentation flow and data interchange • Strict separation of development roles • Language-agnostic • Services can now be written in any programming language • Decoupling of the client and server • Linked by a lightweight message contract • Easier testing • Create client-only prototypes • Use local mockups of services 55
- 56. SOUI / SOFEA frameworks SOUI / SOFEA: Advantages - continued • Performance / responsiveness • Presentation layer is moved to client • Scalability • Application runs in client • Orchestration • Integration of services from different platforms 56
- 57. SOUI / SOFEA frameworks SOUI / SOFEA: Disadvantages • Security • Security attacks on client (code hacking, access to OS) • State is saved in the client / client validations • Control • Less control on execution • Vertical Aspects • No centralized interception point (logging, auditing) • Responsiveness • Application download can take time • Complexity • More technology / layers 57
- 58. SOUI / SOFEA frameworks Examples: •GWT •Flex •Open Laszlo 58
- 59. SOUI / SOFEA frameworks Example: GWT (Google Web Toolkit) • Overview • Developing and debugging Ajax applications in Java • Compiler translates Java into Javascript, CSS & HTML • Programmatic layouting • Announced at JavaOne, 2006 • OSS, Appache License ver 2.0 Java JavaScript Browser 59
- 60. SOUI / SOFEA frameworks GWT: Features • Runs in two modes • Hosted mode – run Java bytecode in JVM / client side debugging • Web mode – application is deployed as JS + HTML to browser • Cross browser compatibility • Highly optimized output • Good web support • Browser history management • Powerful DOM access • Bookmarks • Rich components 60
- 61. SOUI / SOFEA frameworks GWT: Architecture Front End Back End HTTP Browser Java Web Server SOA JS Servlet Engine Container RPC JS <<Service>> asdf dsf sdf sdf {} Asdf asd sdf asdf asdf Asdf asd sdf asdf asdf asdf dsf sdf sdf Servlet Asdf asd sdf asdf asdf asdf dsf sdf sdf Asdf asd sdf asdf asdf asdf dsf sdf sdf Asdf asd sdf asdf asdf asdf dsf sdf sdf JSON/XML <<Service>> HTTP PHP Script HTTP Web Server View + Controller Model 61
- 62. SOUI / SOFEA frameworks GWT: Advantages • Fast and responsive • Zero turnaround in hosted mode • Write pure Java • IDE & tools support • Refactoring • Debugging • No markup / JavaScript mix 62
- 63. SOUI / SOFEA frameworks GWT: Disadvantages • Developer / Designer overlap • Designer cannot use design tools • Markup is hard to tweak / CSS hooks • Runs as JavaScript in browser • No concurrency • Limited reflection • Form processing • No data binding • No built in form validation • Missing best practices • Architectural decisions are left to the developer • Limited search engine optimization 63
- 64. 64
- 65. Comparison Which is best? • Choose the right type of framework for the job • There is always one tool that is a better fit • No one framework provides a solution for all issues • Identify and priorities the requirements 65
- 66. Comparison So how do we choose ? 66
- 67. Comparison Evaluation criteria • Speed of development • Learning curve, complexity • Scalability • Lifetime and maintainability • Documentation • Source, Guides, JavaDoc, Books • Tool support • IDE’s, plug-ins • Popularity • Work force, developer community, places in use • Technical support • Standard compliance 67
- 68. Comparison Evaluation criteria - continued • Separation of responsibilities • Business logic / markup • Power / Ease of use • Design of markup, tags, templating • Flexibility • Change view technology • Change default behaviour • Transparent Infrastructure • What goes on under the hood • Can you get out of the framework? • Extensibility 68
- 69. Comparison :: Summary Request / Response Component SOUI / SOFEA Frameworks Framework Framework Separation of responsibilities - + ++ Speed of development ++ + + Scalability + - ++ Maintainability - + - Community Support ++ + - Transparency ++ + - Security ++ + - Simple user Responsive UI / Target interaction / Fast Complex UI Scalability 69
- 70. 70
- 71. The Future • Are we on the right track? • Is diet going out of fashion? • Survival of the fittest • Software evolution • Frameworks evolve, rather than being explicitly developed • Best of breed • Consolidation? (Struts + WebWorks) • New technologies • E.g. JavaFX, Comet / AJAX push 71
- 72. Thank You ! 72