02 part 1 web app

IBM Software Services for WebSphere

November 18-20, 2003 | Bangalore © 2003 IBM Corporationn

Best practices for developing J2EE applications

Part 1: Web application design considerations

Matt OberlinConsulting IT SpecialistIBM Software Services for WebSphere

02_Part_1_Web_App.PRZ 1 of 57


© 2003 IBM CorporationOctober 28-29, 2003 | Sydney

Best practices challenges, part 1

REFERENCE: ISO 9126 Software Quality Characteristics

Want to develop a web enabled application that is:functional - satisfies user requirementsreliable - performs under changing conditionsusable - enables easy access to application functionsefficient - uses system resources wiselymaintainable - can be modified easilyportable - can be moved from one environment to another




Best practices challenges, part 2

Want to support a development process that is:repeatable - has well defined stepsmeasurable - has well defined work products that resulttoolable - has well defined mapping of inputs to outputspredictable - can make reliable estimates of task timesscalable - works with varying project sizesflexible - can be varied to minimize risks

Best practices should balance both sets of requirements

REFERENCE: ISO 9000 Software Process Metrics




Process best practices

Process approaches vary in "granularity"waterfall, where one phase is completed before the nextincremental-iterative, where the project is decomposed into smaller projects, usually centered around "use cases"

Regardless of granularity, they share the same basic phases:Analysis, where requirements are gatheredDesign, where the requirements are mapped into architectural componentsImplementation, where the components are programmedTest, where the programs are verified that they meet the requirements

This presentation will cover analysis and design




Requirements analysis best practices

Models Dynamic (state, transition)

Static (entity, relation)

Business Process (contract)

Units of work(throughput)

Persistent data(number of records)

Application Flow (user role)

User initiated events(response time)

Visible data(style)

Requirements to capture in a model:business process and application flowdynamic and static aspectsfunctional and non functional

Notations to consider:textual (state tables, templates)graphical (state transition and class relationship diagrams)whatever works for you and your customer




State transition diagram best practices

State-transition diagramsshow "visible" states in lifecycle of domain concepttransitions show events, data flow, conditions and actions

State State

[guard condition]

Role Role

[post condition]

event(data flow) {action}

State

{action}

[post condition]

[trigger condition]

(data flow)(data flow)

Role

event

State

[guard]Role

event




Class relationship diagram best practices

Class relationship diagramsshow object classes, associated properties and relationshipsusually associated with a state in a dynamic model

0..nClass

attribute

Class

@key attattribute

0..n

many rel optional rel

@key rel 0..1 relationshipcontains rel

Class

@key attattribute

Class

@key attattribute




An example business process dynamic model

On line order fullfillment business process modellifecycle of an order showing interaction of various rolestransitions represent units of work (described later)

Entry FulfillmentCompleted

submit()ship (shipper)

create()

[all items shipped]

purgemodify line

item (product, quantity)

cancel()

Customer PackerMarketing

add line item (product, quantity)

[not all items shipped]pack line item

(product, quantity)

assign()




An example business process static model

Order Entry static object modelshows possible state of persistent data during order entryunits of work in dynamic model will be in terms of these

0..nLine Item

quantity

Order

@orderIDstatus

Product

@skudescription

Customer

@customerID

0..n customer

openOrder

@product 0..1




Example unit of work descriptions

Create order for the customerif customer does not exist, create itif customer already has an open order, return itotherwise, create a new order with status "Opened" set the order's customer to that given

Submit or cancel a given orderif order does not exist or is not opened, returnotherwise set status to "Submitted" or "Cancelled", respectively

Add a quantity of a line item to the customer's open orderif customer does not exist, create itif open order for customer does not exist, create oneif order line item does not exist for the product:if quantity greater than zero, create one with that quantityotherwise, increment the line item quantity by the amount specified if the resulting quantity is less than or equal to zero, delete the line item

Modify a given line item quantity (must be greater than or equal to 0)if customer does not exist, create itif open order for customer does not exist, create oneif order line item does not exist for the product, create one with the quantity otherwise, set the quantity to that specified




An example application flow dynamic model

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order} {cancel order}

{modify item(product, quantity)}

add to order {add item

(product, quantity)}

Confirm Open

(order)

(order)

(order)

(order)

Customer's application flow dynamic modelhigh level requirements captured in a STD of a customertransitions may trigger events on the underlying BPM

ok




An example application flow static model

0..n 0..n

Line Item

productIDdescriptionquantity

Order

orderIDstatus

Product

productIDdescription

Order Details

customerIDorderIDstatus

Order Status

customerID

Product Catalog

0..nAction Result

message

Confirm Action

orderIDaction

Customer Home

products items orders

Customer application flow static modelone "entry point" object per stateattributes and relationships show dynamic content




Architecture best practices

Once the requirements are gathered, the next step is to identify a candidate architecture

describe physical and logical "tiers" where application components will be hosteddrives the programming model used in detailed design

We will examine the pros/cons of four approaches:web enabled client-serverdistributed object basedweb services basedweb enabled distributed object based

All four will likely be used in a large application




Three-tier web based application architecture

Pros:browsers are everywhereclient tier needs install nothing specific (maintenance)middle tier has direct access to back end data (performance)

Cons:cost of remote connection to middle tier (performance)must install enterprise clients on middle tier (maintenance)business logic executes in middle tier (security)

Best application: web enabling the front end of a business process (the "edge")

Web Application ServerBrowser Enterprise Logic

& Data Server

???0..n 0..n

Line ItemproductIDdescriptionquantity

Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home


Application flow static model

0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1

Business process static model



create()

[all items shipped]

purgemodify line


cancel()

Customer ShippingMarketing



(product, quantity)

Business process dynamic model

Application flow dynamic model

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok

{add item(product, quantity)}

[qty = 0][qty < 0]

HTTP




Distributed object based application architectureClient Application Enterprise Logic

& Data ServerDistributed

Object Server

IIOP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]

Pros:really snappy user interface (performance)client does not need enterprise accessbusiness logic separated from client (security, maintenance)can load balance business logic (scalability)

Cons:must install application on client (maintenance)extra pathlength to access enterprise (performance)ORBs are not yet ubiquitous (maintenance)

Best application:intranet applications needing high function a GUI




Client Application Enterprise Logic & Data Server

Web Services Server

HTTP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]

Pros (same as distributed objects except):language and platform neutrality (flexibility)no ORB required on client (maintenance)other protocols supported, like JMS/MQ

Cons (same as distributed objects except):SOAP/HTTP does not have all the features of IIOP (reliability)XML takes extra time to transfer/process (performance)transactions not supported across calls yet

Best application:extranet/internet applications needing high function GUIs or EDI

Web Services based application architecture




Web enabled distributed object application architectureWeb Application

ServerBrowser Enterprise Logic & Data Server

Distributed Object Server

IIOP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]

Pros:client tier needs install nothing specific (maintenance)middle tier does not need enterprise clients (maintenance)business logic separated from application server (security)can load balance application & object servers (scalability)

Cons:remote method pathlength (performance)

Best application:web enabling any phase of a business process

HTTP




Programming model best practices

Aspects of the programming model for a given tier to consider:components that you develop hosted on that tiermechanisms used to flow control between componentssources used to flow data between components

Component Control Flow Data Source

Browser HTML, XML, Framesets, Applets

HTTP requests, JavaScript, Java

URL Query String, POST Data, Cookies

Application Server

Servlets, JSPs, View Beans, Tags

sendRedirect(), forward(), include()

Request, Session, Servlet Context

Distributed Object Server

Session EJB, Entity EJB, Key/Data Beans RMI/IIOP JNDI, JDBC, others

Enterprise Server

BMP Entity EJB, SessionSynch EJB

beforeXXX(), afterXXX(), ejbXXX() JNDI, JDBC, others




Web page design considerations

In this section we will discuss techniques useful when designing web pages,independently of whether HttpServlets (or JSPs) are used to generate the dynamic content

HTTP



Object Server

IIOP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]




Think about what would happen if each transition were to result in a request to the web server...

The network traffic problem, part 1

problem 3: what about invalid quantities?

problem 1: this confirmation would cause extraneous call to web server

problem 2: this confirmation would

likely require rerendering details

problem 4: what if there were lists or cascading menus?

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok




Full use of Java Script

Consider JavaScript to handle transitions (and associated states) on the browser, such as confirmations, validations, lists and menus

tradeoff: makes pages more complex, less portable

advantage 1: confirmation causes

no request

advantage 2: validating quantity causes no request

question: should we check for the quantity being less than available inventory?

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok




Syntactic validation using Java Script

Validations should be limited to checking the format of values (syntactic validation), and possibly ranges (if understood)

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok

status: we have minimized the number of

requests to the server

check for non zero integer is ok

check for integer > 0 is

ok

these validations should have been explicitly shown on the diagramwarning: validations still

need to occur on server side!




The web page granularity problem

Now think about what would happen if each state were to be represented by a web page...

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok

either: each page is relatively small, but navigation would

require heavy use of the "back" button...

or: each page would require redundant data

and navigations




Using framesets and named windows

Consider using framesets or named windows to consolidate related states into a single page

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok

Navigation area

Main area

Action result area




Framesets and Named Windows: another view

One possible frameset view of the application flowNavigation

AreaMain Area

Action Result Area

displays Product Catalog, Order Status or Order Details,

depending on selection

adding to order, editing quantity, cancelling or

submitting targets result area

simply the Customer

Home 'navigation bar' where selections target main

area

issues: more complex, less portable, harder to print and

bookmark

advantage 1: smaller requests invoked in parallel

to load page

advantage 2: only affected areas of the page are

re-rendered




Other web page design approaches

Java applets:can offload almost all application flow control to the browser, resulting in snappy response time (once loaded)however, applets are basically Java client applications (which will be discussed later)can only access the server from which they were downloadedonly useful for standalone applications that require no back end access (e.g. loan amortization calculator) or extranet/intranet applications with limited numbers of clients

XML enabled browsers: enables application server to send back data only (XML document)browser uses XSL to render tags into HTML that gets displayedmakes it easier to design for multiple device typesnot yet ubiquitous, so the web server should be able to handle rendering HTML prior to reply (more on this later)




1. Break a given web page into multiple components corresponding to the application flow states

2. Use JavaScript to handle confirmations, syntactic validations and list/menu processing to minimize HTTP requests

3. Avoid semantic validations that require knowledge of the business logic

4. Consider Framesets/Named windows to consolidate related information, minimize re-rendering and allow for smaller, parallel requests

5. Consider XML enabled browsers to minimize replies, offload some of the processing off of the web application server, and support other device types

6. Treat Applet controlled states like monolithic or client-server applications, most useful in standalone or intranet scenarios

Summary for Web page design




Basic HttpServlet design

In this section we will discuss techniques useful for designing HttpServlets to handle dynamic content, independently of whether distributed objects are used or not

HTTP



Object Server

IIOP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]




Think about what would happen if we only created a single HttpServlet to control the entire application...

The servlet granularity problem

problem 1: only one programmer could

work at a time

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok

problem 2: the code would be rather

complex to handle all the states and

transitions

problem 3: can't use servlet level security, monitoring...




HttpServlets end-to-end flow

Using an HttpServlet to control the processing associated with a state in the application flow

HTTP POSTOrderStatusServlet?action=add&cust=1111 service(req, res)

req.getParameter("cust")"1111"

{add order for Customer 1111}

res.getPrintWriter().println("...")

[res = "..."]

[loc = OrderStatusServlet?

customer=1111]


action=add&cust=1111]

"HTML for Order Details 1000"

Web Application

Server

Order StatusServlet

ClientWeb

Browser

{repeat}

req.getParameter("action")"add"

problem: what happens if the user hits reload, resize, print, ... ?




The reload problem

Inadvertant re-execution of an HttpServlet due to browser events like reload, resize, back, forward, print

Web Application

Server

Order Status Servlet

ClientWeb

Browser

service(req, res)


HTTP GETOrderStatusServlet?action=add&cust=1111

{add order for customer 1111 and

generate HTML}

{reload}

using POST for update actions helps, but user can

still invoke a reload

service(req, res){add order for

customer 1111 and generate HTML}


customer=1111]


action=add&cust=1111]


HTTP GETOrderStatusServlet?action=add&cust=1111

problem: data integrity errors!




HttpResponse sendRedirect() end-to-end flow

Use sendRedirect() to flow control from a source state to a target state when there are update side effects

HTTP POSTOrderStatusServlet?action=add&cust=1111 service(req, res)

{add new order for customer 1111}


customer=1111]

[loc = Order DetailsServlet?

order=1000]

HTTP REDIRECTOrderDetailsServlet?order=1000

Web Application

Server


ClientWeb

Browser

service(req, res)


HTTP GETOrderDetailsServlet?order=1000

{get details for order 1000 and generate HTML}

{browser intercepts}

Order Details Servlet

{reload}

advantage 1: solves reload problem

advantage 2: all the logic associated with a state is in the associated HttpServlet

problem: logic handling updates is intermixed with that for reads in service()




HttpServlet doGet() and doPost() end-to-end flow

Use doGet() to handle display for a dynamic state and doPost() to handle update transitions

doPost(req, res)

HTTP POSTOrderStatusServlet?action=add&cust=1111


customer=1111]

Web Application

Server


ClientWeb

Browser

doGet(req, res)






[loc = Order DetailsServlet?

order=1000]


{get details for order 1000 and generate HTML}

{reload}

advantage: doPost() and doGet() can be developed

and tested separately

problem 2: can't use WYSIWYG editor to help generate HTML

problem 1: cannot independently develop or modify logic and layout




Java Server Pages end-to-end flow

Using Java Server Pages to separate the layout from the data access logic for a state with dynamic content

doGet(req, res){get details for order 1000}

[namei= value

i]

Web Application

Server


{repeat for each order detail variable}

Order Details

JSP

getServletContext(). getRequestDispatcher( "...OrderDetails.jsp" ).forward(req, res)

<%=(<type>)req.getAttribute("namei")%>

valuei {repeat}

<HTML>...[res = "HTML for Order

Details 1000"]

req.setAttribute("namei", value

i)

problem 1: name/type convention

advantage1: can develop & maintain in parallel

problem 2: multiple sets/gets

problem 3: must use expressions and cast result

advantage 3: can use a WYSIWYG editor for HTML

advantage 2: can use an IDE

for logic




Data Structure (View) Java Beans end-to-end flow

Using a data structure Java Bean to maintain the values displayed by the JSP for a given state

req.setAttribute( "OrderDetails",

OrderDetailsData)[OrderDetails =

OrderDetailsData]

Web Application

Server

Order DetailsServlet

Order Details

JSP

getServletContext().getRequestDispatcher( "...OrderDetails.jsp").forward(req, res)

<jsp:usebean name=OrderDetails type=OrderDetailsData>OrderDetailsData

<HTML>... <jsp:beanproperty bean=OrderDetails property=pi>

...

Order DetailsData

new(v1, ..., v

n)

[p1=v

1, ..., p

n=v

n]

{repeat}[res = "<HTML>... v

i ..."]

{get details for order 1000}doGet(req, res)

OrderDetailsData

vigetP

i()

advantage 2: no Java required

except for loops

advantage1: only one set/get with

well defined name/type

advantage 3: tools in both

IDE and page editors

use Java Beans




The contract problem

Think about how to tell where JSPs and view beans would be useful

can't really tell from this dynamic model

OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok





Confirm Open

(order)

(order)

(order)

(order)

ok




Data Structure Java Beans (View Beans)

The static model for each application flow state determines whether a JSP and data structure Java Bean would be useful

0..n 0..n

Line Item

productIDdescriptionquantity

Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

Customer Home

action

handled in JavaScript

little or no dynamic content




How do you eliminate Java in JSPs?

...<JSP:USEBEAN ID="OrderStatus" CLASS="com.onlinemall.data.OrderStatusData" SCOPE="request"/>...<SW296:INDEXEDBEANPROPERTY BEAN="OrderStatus" PROPERTY="orders" VAR="order" TYPE="com.onlinemall.data.OrderData">

...<JSP:GETPROPERTY NAME="order" PROPERTY="orderID"/>...<JSP:GETPROPERTY NAME="order" PROPERTY="status"/>...</SW296:INDEXEDBEANPROPERTY>

...<JSP:USEBEAN ID="OrderStatus" CLASS="com.onlinemall.data.OrderStatusData" SCOPE="request"/>...<% int orderID = 0; String status = null; com.onlinemall.data.OrderData d[] = OrderStatus.orders; for (int i=0 ; i < d.length; i++) { orderID = d[i].orderID; status = d[i].status;%>...<%=orderID%>...<%=status"%>...<% } %>

Consider custom tags for loops and object navigation instead of Java scriptlets




1. HTTPServlets control states and associated transitionsdoGet() gathers data to display doPost() handles updates and flows to next stateuse sendRedirect after updates to avoid reload problem

2. JSPs generate the view associated with stateView beans encapsulate data needed by JSPCustom tags eliminate Java in JSPs

Basic HttpServlet design summary




Advanced HttpServlet design considerations

In this section we will discuss advanced techniques useful for designing HttpServlets to make them even easier to develop and maintain, and we will address some performance issues

HTTP



Object Server

IIOP ???0..n 0..n


Order

orderIDstatus

Product


Order Details


Order Status

customerID

Product Catalog

0..n

Product Catalog

Action Result

message

Confirm Action

orderIDaction

Customer Home



0..nLine Item

quantity

Order

orderIDstatus

Product

skudescription

Customer

customerID

0..n customer

openOrder

product 0..1




create()

[all items shipped]

purgemodify line


cancel()




(product, quantity)



OrderDetails

ConfirmSubmit

submit

ok

cancel

OrderStatus

ConfirmCancel

open

Customer Home

Product Catalog

Action Result

{create order}

edit line item

ok

{submit order}

{cancel order}


add to order

Confirm Open

(order)

ok


[qty = 0][qty < 0]




The "page composition" problem

Think about how you would deal with the situation where framesets or named windows cannot be used on the client

adding an item to the order redisplays

catalog page

Customer Home

Product Catalog

Action Result

Customer Home

Order Status

Action Result

Customer Home

Order Details

Action Result

selecting or adding an order displays details

modifying an item, or submit/cancel redisplays order

want to reuse code to render

"substates" of a given page




RequestDispatcher include() end-to-end flow

Use the include() function to compose pages from HttpServlets representing the application flow states

ClientWeb

Browser

Web Application

Server

Product Catalog Servlet

include("CustomerHome.jsp",

req, res)

Customer HomeJSP

{repeat include for other "substates", like Results and Product Catalog JSP}

doGet(req, res){generate

navigation area}"HTML fragment for navigation area"

[res = "HTML fragment for navigation area"]

"HTML for composed Product Catalog page"

doGet(req, res){get products from

access bean}

HTTP GETProductCatalogServlet?start=101

advantage 2: can be reused in multiple pages

advantage 1: easy to bookmark, print ...

tradeoff 1: static states must be JSPs

problem: maintaining common look and feel across pages

tradeoff 3: ugly URLs on location line

tradeoff 2: must re-render whole page

for every call




The "common look & feel" problem

Think about how unmaintainable the application would be if we modeled and coded behaviors common to every state?

Source State

some event

TargetState

{some action}

Errors

[errors]

[no errors]

[not authenticated]

[authenticated]

Login

login{authenticate uid

& password}

[ok] [retry]

may want different layouts depending on

user's national language, or support

different browser types

may want different behaviors for

GET/POST events

pages may share

components

Locked

[locked]




HttpServlet inheritance end-to-end flow

Use inheritance and factor common behaviors into an extensible HttpServlet class hierarchy

{check authorization: if not, forward to Login JSP}

Web Application

Server

Product Catalog Servlet

ClientWeb

Browser

"HTML for Product Catalog starting at

item 101"

OnlineBuying Servlet

HTTP GET ProductCatalogServlet?start=101 doGet(req, res)

include( "ProductCatalog", req, res)

doGetOnlineBuying(req, res)

{append directory of user's preferred language to

name and forward}

{catch errors: if any, forward to Error JSP;

otherwise compose page}

advantage 2: subclass methods focus on

gathering data, handling updates

advantage 1: naming convention makes it

easy to extend hierarchy

advantage 3: inherited

convenience methods make developing & maintaining even easier

advantage 4: can declare final & abstract

for enforcement

advantage 5: can develop look and feel separately

could modify include to

generate XML instead

problem: minimizing back

end accesses




The network traffic problem, part 2

Consider caching the data structure Java Bean for a state in HttpSession to eliminate extraneous back end accesses

Web Application

Server

ClientWeb

Browser


{repeat}

HTTP GETOrderDetailsServlet?... doGet(req, res)

req.getSession(false).getValue("OrderDetails")null

{getOrderDetails()}req.getSession(true).putValue("OrderDetails", OrderDetailsBean)

[session = <"OrderDetails", OrderDetailsBean>]

OrderDetailsBean

doGet(req, res)req.getSession(false).getValue("OrderDetails")

HTTP GET ...{...}

{OrderDetailsJSP}"HTML for Order Details"

{OrderDetailsJSP}"HTML for Order Details"

advantage 2: session shared across

contexts

advantage 1: handles timeout

problem: cache consistency!




The "cache consistency" problem

Application events can cause session state to be out of synch with respect to the enterprise data source


customer=1111]HTTP POSTOrderStatusServlet?action=add&cust=1111 doPost(req, res)



Web Application

Server


ClientWeb

Browser



[session = <"OrderStatus", OrderStatusBean 1111>,

<"OrderDetails", OrderDetailsBean 1000>]

doGet(req, res)



req.getSession(false). getValue("OrderDetails")

OrderDetailsBean 1000{OrderDetailsJSP}

problem 2: OrderStatusBean

is out of date

problem 1: OrderDetailBean does not

match order desired

GET alternatives: must check keys or cache multiple copies

POST alternatives: must remove or reread

problem 3: what happens in a clustered

configuration?




The "cluster consistency" problem

Application events in a clustered environment can cause the session state on different nodes to get out of synch

Web Application

Server 1

Web Application

Server 2

ClientWeb

Browser

cluster alternatives: turn on affinity, or share persistent sessions

problem: cache is out of synch

symptom: subsequent displays routed to different nodes are inconsistent



{read details, set session and generate HTML}[session = <"OrderDetails", OrderDetailsData>]

HTTP POSTOrderDetailsServlet?action=buy&order=1000&product=101&qty=1

{update order}

HTTP REDIRECT OrderDetailsServlet?order=1000[session = ???]

{browser intercepts}HTTP GETOrderDetailsServlet?order=1000

{get session and generate HTML}"HTML for Order Details 1000"




Client-server affinity end-to-end flow

Use client-server affinity to insure cache consistency where performance considerations are highest priority

Web Application

Server 1

Web Application

Server 2

Client 1Web

Browser

advantage: sessions can be stored in memory for fastest access

problem 1: clients sharing an ISP often appear like the "same"

client, reducing load balancing effectiveness



{read details, set session and generate HTML}[session = <"OrderDetails", OrderDetailsData>]

HTTP POSTOrderDetailsServlet?action=buy&order=1000&product=101&qty=1

{update order}HTTP REDIRECT OrderDetailsServlet?

order=1000[session = ???]

{browser intercepts}HTTP GETOrderDetailsServlet?order=1000

{get session and generate HTML}"HTML for Order Details 1000"

problem 2: does not support failure bypass




Shared persistent session state end-to-end flow

Persist sessions in a shared database when load balancing and failover requirements have highest priority

Web Application

Server 1

Web Application Server 2

ClientWeb

Browser



[session = <"OrderDetails",

OrderDetailsData>]HTTP POSTOrderDetailsServlet?action=buy&order=1000&product=101&qty=1

HTTP REDIRECT OrderDetailsServlet?order=1000


[session = ]


Shared Session

Database

get sessionnull

set session = <"OrderDetails", OrderDetailsData>

remove session


get sessionnull

advantage 1: cache is always synchronized across nodes

advantage 2: full failover support is

enabled

tradeoff: cache consistency complexity and you end up reading database anyway

problem: what about data shared across users?




ServletContext end-to-end flow

Consider caching data common to all users in Servlet Context to minimize enterprise access and session size

problem 2: have to check for null and load everywhere

Web Application

Server

ClientWeb

Browser

Product Catalog ServletHTTP GET

ProductCatalogServlet?start=101 doGet(req, res)getServletContext().getAttribute("ProductCatalog")

null{getProductCatalog()}

getServletContext().setAttribute("ProductCatalog", ProductCatalogData)[context = <"ProductCatalog", ProductCatalogData>]

{ProductCatalogJSP}"HTML for Products 1851..."

{...}{ProductCatalogJSP}"HTML for Products 101..."

doGet(req, res)HTTP GET... start=1851getServletContext().getAttribute("ProductCatalog")

productCatalogData

advantage: handles failure

problem 1: servlet context is not sharable in a cluster!




HttpServlet init() end-to-end flow

Use the HttpServlet init() method to preload stable readonly data into ServletContext cache and servlet instance variables

Web Application

Server

ClientWeb

Browser

Product Catalog ServletHTTP GET

ProductCatalogServlet?start=101

{only first call invokes init}init()

getServletContext().getAttribute("ProductCatalog")null

{getProductCatalog()}getServletContext().setAttribute("ProductCatalog", ProductCatalogData)

[context = <"ProductCatalog", ProductCatalogData>]

doGet(req, res){ProductCatalogJSP}"HTML for Product Catalog"

{...}

advantage 3: doGet & doPost is guaranteed to

have cache loaded

advantage 2: other HttpServlet instances

(same or different classes) will find data

problem: caching logic (either in session or context) adds a lot of complexity to web application flow

advantage 1: data stability eliminates

need for affinity




1. Design JSPs so that they can be composed with include2. Capture common look-and-feel in inherited HttpServlets rather

than "gateway" servlets3. Let superclass servlet decide whether to call JSP or generate

XML for return to XSLT enabled browsers4. HttpSession should only maintain easily recomputable values

to avoid timeout problem5. Check keys & remove session to avoid cache consistency

problems6. Use client-server affinity or persistent sessions to avoid

cluster consistency problem7. ServletContext should only cache stable readonly data8. init method on HttpServlet can be used to load cache

Advanced HttpServlet design summary


02 part 1 web app

Documents