Java Edge.2008.Web.Frameworks.Catagorized

2

Agenda

3

Agenda

• Introduction

• The evolution of WAFs

• Welcome to the jungle

• Categorizing by example

• Comparison

• The future

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

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

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

8

9

Evolution

10

Evolution :: Technology

New APIs appear because developers discover

limitations in existing languages and tools. “

”

1991 1995 1997 1998

HTML draft CGIServlet

1.0

JSP

0.98

1980

MVC (Xerox)

1994

Design

Patterns

(GoF) Ajax / Wicket

1996

Java 1.0 /

Applets

2000

Jakarta

Struts 1.0

2006

GWT

2002

Spring

Framework

1999

J2EE 1.2

SDK

2007

SOUI /

SOFEA

2001

.com

bubble

Web 1.0 Web 2.0

20052003 20041992 1993

11


1991 1995 1997 1998


1.0

JSP

0.98

1980

MVC (Xerox)

1994

Design

Patterns

(GoF) Ajax / Wicket

1996

Java 1.0 /

Applets

2000

Jakarta

Struts 1.0

2006

GWT

2002

Spring

Framework

1999

J2EE 1.2

SDK

2007

SOUI /

SOFEA

2001

.com

bubble

Web 1.0 Web 2.0

20052003 20041992 1993

• 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

12


1991 1995 1997 1998


1.0

JSP

0.98

1980

MVC (Xerox)

1994

Design

Patterns

(GoF) Ajax / Wicket

1996

Java 1.0 /

Applets

2000

Jakarta

Struts 1.0

2006

GWT

2002

Spring

Framework

1999

J2EE 1.2

SDK

2007

SOUI /

SOFEA

2001

.com

bubble

Web 1.0 Web 2.0

20052003 20041992 1993

• 1997 - Servlets

• Java's CGI abstraction

• Java code that extends functionality of a web server

• Receives a request and generates a response

13


1991 1995 1997 1998


1.0

JSP

0.98

1980

MVC (Xerox)

1994

Design

Patterns

(GoF) Ajax / Wicket

1996

Java 1.0 /

Applets

2000

Jakarta

Struts 1.0

2006

GWT

2002

Spring

Framework

1999

J2EE 1.2

SDK

2007

SOUI /

SOFEA

2001

.com

bubble

Web 1.0 Web 2.0

20052003 20041992 1993

• 1998 – JSP (JavaServer Pages)

• Embed Java code, directives & actions in markup

• Compiled & converted to a Servlet

• Extend static content with standard / custom tag libraries

14


1991 1995 1997 1998


1.0

JSP

0.98

1980

MVC (Xerox)

1994

Design

Patterns

(GoF) Ajax / Wicket

1996

Java 1.0 /

Applets

2000

Jakarta

Struts 1.0

2006

GWT

2002

Spring

Framework

1999

J2EE 1.2

SDK

2007

SOUI /

SOFEA

2001

.com

bubble

Web 1.0 Web 2.0

20052003 20041992 1993

• 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

15


Britney Spears, Circus Album Released

November 28, 2008

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

ControllerView

State

Change

State

Query

View

Selection

User

Actions

Change

Notifications

17


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

18


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

JSP

(View)

JavaBeans

(Model) DataBrowser

request

response

19


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

JSP

(View)

JavaBeans

(Model) DataBrowser

request

response

Servlet

(Controller)

create/

update

access

dispatch

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

22


web

23


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

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

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

28


Architecture

Browser

request

response

FrontServlet

forward

Request

Processor

JavaBeans

Action /

Command

execute

get

business

date

JSP

fill with

business

data

Controller

View Model

29


• 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

30


Examples:

•Spring MVC •Struts 2 •WebWork

31


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

32


SpringMVC: Architecture

Front Controller

(Dispatcher Servlet)

Handler Mapper

ControllerController

Controller

HandlerInterceptor

View

template

Browser

JavaBeansJavaBeans

JavaBeans

`

ModelView

ModelView

Controller

View Model

33


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

34


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

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

37


Architecture

<root>

<panel>

<panel>

<label/>

<textField/>

...

</panel>

<button/>

</panel>

</root>

View Technology Component Tree Markup

Submit

Username

Password

Root

Panel

Label TextField

ButtonPanel ...

38


• Advantages

• Object-oriented

• Advocates reuse

• Rich component libraries

• Familiar to desktop application developers

• Disadvantages

• Complexity

• Hard to customize components

• Scalability

39


Examples:

• Wicket • JSF • Tapestry

40


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

41

Component

Label

WebComponent MarkupContainer

Page WebMarkupContainer

WebPage Panel Link


Wicket: Architecture

awt.Component

awt.Container

JContainer

JComponent

JPanel JLabel JButton

awt.Window

awt.Frame

JFrame

Swing Wicket

42


Wicket: Architecture

Submit

Username

Password

Model

View Controller

Component

updatesconsults

rendersreceives

input

Id=submitBtn

HTML

< >

…

<input

type=”button”

wicket:id =

”submitBtn”/>

...

43


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

44


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

45

46

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

47



• 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

48


Thin client application architecture

• Server (presentation layer)

• Serves web pages (application download)

• Drives application flow

• Manages data interchange:

browser <-> business layer

• Client (browser)

• Renders and displays markup

Model

View Controller

View

Client

Server

Web

Framework

49


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

50


SOUI / SOFEA: Principles• Decouple presentation tier

• Application download

• Presentation flow

• Data interchange

• Presentation flow must be driven by client

• Client sate must be managed in client

• “Front Controller” is an anti-pattern

• Support for rich data structures

• No HTML (XML / JSON)

• No more object <-> string conversions

Model

ControllerView

Client

Server / Service

Web

Framework

51


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

52


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

53


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

54


Architecture

SOA Business

Services

REST

SOAP

Service

Interface

Download

Server

View

Model

Controller

Client

Application

Application Container

Application

Download

(AD)

Data

Interchange

(DI)

Presentation

Flow

(PF)

Intenet

55


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

56


SOUI / SOFEA: Advantages - continued

• Performance / responsiveness

• Presentation layer is moved to client

• Scalability

• Application runs in client

• Orchestration

• Integration of services from different platforms

57


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

58


Examples:

•GWT •Flex •Open Laszlo

59


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

BrowserJavaScriptJava

60


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

61


GWT: Architecture

HTTP Web Server

Browser

Front End Back End

Java Web Server

RPC

Asdf asd sdf asdf asdf

asdf dsf sdf sdf


asdf dsf sdf sdf


asdf dsf sdf sdf


asdf dsf sdf sdf


asdf dsf sdf sdf

JS

JS

Engine

{ }

Servlet

Container

JSON/XML

HTTP

View + Controller Model

SOAHTTP

<<Service>>

Servlet

<<Service>>

PHP Script

62


GWT: Advantages

• Fast and responsive

• Zero turnaround in hosted mode

• Write pure Java

• IDE & tools support

• Refactoring

• Debugging

• No markup / JavaScript mix

63


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

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

66

Comparison

So how do we choose ?

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

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

69

Comparison :: Summary

Separation of

responsibilities - + ++

Speed of

development ++ + +

Scalability + - ++

Maintainability - + -

Community

Support ++ + -

Transparency ++ + -

Security ++ + -

TargetSimple user

interaction / Fast Complex UI

Responsive UI /

Scalability

Request / Response

Frameworks

Component

Framework

SOUI / SOFEA

Framework

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

72

Thank

You !

Java Edge.2008.Web.Frameworks.Catagorized

Documents

model model

web application development

jungle web

evolution of wafs welcome

application architecture

view view pulls data

web servers

business logic view