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