IBM Software Services for WebSphere
Part 1: Web application design considerations Matt Oberlin Consulting IT Specialist IBM Software Services for WebSphere Best practices for developing J2EE applications
November 18-20, 2003 | Bangalore
02_Part_1_Web_App.PRZ
© 2003 IBM Corporationn
1 of 57
IBM Software Services for WebSphere
Best practices challenges, part 1 Want to develop a web enabled application that is:
functional - satisfies user requirements reliable - performs under changing conditions usable - enables easy access to application functions efficient - uses system resources wisely maintainable - can be modified easily portable - can be moved from one environment to another
REFERENCE: ISO 9126 Software Quality Characteristics
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
2 of 57
IBM Software Services for WebSphere
Best practices challenges, part 2 Want to support a development process that is:
repeatable - has well defined steps measurable - has well defined work products that result toolable - has well defined mapping of inputs to outputs predictable - can make reliable estimates of task times scalable - works with varying project sizes flexible - can be varied to minimize risks
Best practices should balance both sets of requirements REFERENCE: ISO 9000 Software Process Metrics
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
3 of 57
IBM Software Services for WebSphere
Process best practices Process approaches vary in "granularity" waterfall, where one phase is completed before the next incremental-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 gathered Design, where the requirements are mapped into architectural components Implementation, where the components are programmed Test, where the programs are verified that they meet the requirements
This presentation will cover analysis and design
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
4 of 57
IBM Software Services for WebSphere
Requirements analysis best practices Requirements to capture in a model:
business process and application flow dynamic and static aspects functional and non functional 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)
Notations to consider:
textual (state tables, templates) graphical (state transition and class relationship diagrams) whatever works for you and your customer October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
5 of 57
IBM Software Services for WebSphere
State transition diagram best practices State-transition diagrams
show "visible" states in lifecycle of domain concept transitions show events, data flow, conditions and actions Role
Role State
[guard event condition] (data flow) {action} [trigger condition]
(data flow)
{action}
[post condition]
State event [guard]
[post condition] (data flow)
Role
Role State State
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
event
© 2003 IBM Corporation
6 of 57
IBM Software Services for WebSphere
Class relationship diagram best practices Class relationship diagrams
show object classes, associated properties and relationships usually associated with a state in a dynamic model Class
Class
@key att attribute
@key att attribute optional rel
many rel @key rel
Class attribute
contains rel 0..n
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
0..n
0..1
relationship
Class @key att attribute
© 2003 IBM Corporation
7 of 57
IBM Software Services for WebSphere
An example business process dynamic model On line order fullfillment business process model lifecycle of an order showing interaction of various roles transitions represent units of work (described later)
create()
add line item (product, quantity) Customer
Entry modify line item (product, quantity)
submit() cancel()
assign()
Packer
Marketing ship (shipper) [all items Fulfillment shipped] Completed purge [not all items pack line item shipped]
(product, quantity)
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
8 of 57
IBM Software Services for WebSphere
An example business process static model Order Entry static object model shows possible state of persistent data during order entry units of work in dynamic model will be in terms of these Product
Customer
@sku description
@customerID
openOrder @product
Line Item quantity
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
0..n
0..1 customer
Order 0..n
@orderID status
© 2003 IBM Corporation
9 of 57
IBM Software Services for WebSphere
Example unit of work descriptions Create order for the customer
if customer does not exist, create it if customer already has an open order, return it otherwise, create a new order with status "Opened" set the order's customer to that given
Submit or cancel a given order
if order does not exist or is not opened, return otherwise set status to "Submitted" or "Cancelled", respectively
Add a quantity of a line item to the customer's open order
if customer does not exist, create it if open order for customer does not exist, create one if order line item does not exist for the product: if quantity greater than zero, create one with that quantity otherwise, 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 it if open order for customer does not exist, create one if order line item does not exist for the product, create one with the quantity otherwise, set the quantity to that specified October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
10 of 57
IBM Software Services for WebSphere
An example application flow dynamic model Customer's application flow dynamic model high level requirements captured in a STD of a customer transitions may trigger events on the underlying BPM Customer Home
Order Status open
(order)
Product Catalog add to order {add item (product, quantity)}
cancel (order) Confirm Cancel
Order Details
Action Result
02_Part_1_Web_App.PRZ
{create order}
ok
Confirm Open
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
October 28-29, 2003 | Sydney
(order)
ok {submit order}
© 2003 IBM Corporation
11 of 57
IBM Software Services for WebSphere
An example application flow static model Customer application flow static model one "entry point" object per state attributes and relationships show dynamic content Product Order Order Customer Catalog Details Status Home customerID orderID status
customerID
products
items
orders
0..n
0..n
0..n
Product
Line Item
productID description
productID description quantity
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
Order orderID status
Action Result message
Confirm Action orderID action
© 2003 IBM Corporation
12 of 57
IBM Software Services for WebSphere
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 hosted drives the programming model used in detailed design
We will examine the pros/cons of four approaches: web enabled client-server distributed object based web services based web enabled distributed object based
All four will likely be used in a large application
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
13 of 57
IBM Software Services for WebSphere
Three-tier web based application architecture Web Application Server
Browser Product Catalog
Order Details
customerID orderID status products
items
0..n
Customer Home
HTTP
Product Catalog
Order orderID status
cancel
add to order
0..n
Line Item productID description quantity
Action Result message
Order Status open
(order)
customerID
orders
0..n
Product productID description
Order Status
Customer Home
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
ok
[qty < 0] Confirm Submit
{modify item (product, quantity)} Action Result
ok {submit order}
Application flow dynamic model
create()
Confirm Open
submit
edit line item
ok {cancel order}
{create order}
Order Details
Enterprise Logic & Data Server
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Fulfillment
Shipping Marketing ship (shipper) [all items shipped] Completed purge
???
Customer customerID
openOrder product
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Product sku description
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
Pros: browsers are everywhere client 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") October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
14 of 57
IBM Software Services for WebSphere
Distributed object based application architecture Distributed Object Server
Client Application Product Catalog
Order Details
customerID orderID status products
items
0..n
Customer Home
Product Catalog
Order orderID status
cancel
add to order
0..n
Line Item productID description quantity
Order Status
Action Result message
open
(order)
customerID
orders
0..n
Product productID description
Order Status
Customer Home
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
ok
[qty < 0] Confirm Submit
{modify item (product, quantity)} Action Result
ok {submit order}
Application flow dynamic model
IIOP
create()
Confirm Open
submit
edit line item
ok {cancel order}
{create order}
Order Details
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Fulfillment
Shipping Marketing ship (shipper) [all items shipped] Completed purge
Enterprise Logic & Data Server ???
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
Pros: really snappy user interface (performance) client does not need enterprise access business 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 October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
15 of 57
IBM Software Services for WebSphere
Web Services based application architecture Web Services Server
Client Application Product Catalog
Order Details
customerID orderID status products
items
0..n
Customer Home
Customer Home
Line Item productID description quantity
Order Status
Order orderID status
cancel
add to order
Action Result message
open
(order)
Product Catalog
0..n
0..n
Product productID description
Order Status customerID
orders
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
ok
[qty < 0] Confirm Submit
{modify item (product, quantity)} Action Result
ok {submit order}
Application flow dynamic model
HTTP
create()
Confirm Open
submit
edit line item
ok {cancel order}
{create order}
Order Details
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Shipping Marketing ship (shipper) [all items Fulfillment shipped] Completed purge
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Enterprise Logic & Data Server ???
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
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 October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
16 of 57
IBM Software Services for WebSphere
Web enabled distributed object application architecture Web Application Server
Browser Product Catalog
Order Details
customerID orderID status products
items
0..n
0..n
Product productID description
Line Item productID description quantity
Order Status
Customer Home
Customer Home
HTTP
customerID
orders
cancel
add to order
0..n
Action Result
Order orderID status
message
Confirm Action
Order Status open
(order)
Product Catalog
Confirm Cancel
[qty = 0]
orderID action
Application flow static model
{add item (product, quantity)}
{create order}
Order Details
ok
[qty < 0] Confirm Submit
{modify item (product, quantity)} Action Result
IIOP
create()
Confirm Open
submit
edit line item
ok {cancel order}
Distributed Object Server add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
ok {submit order}
Application flow dynamic model
Shipping Marketing ship (shipper) [all items Fulfillment shipped] Completed purge
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Enterprise Logic & Data Server ???
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
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
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
17 of 57
IBM Software Services for WebSphere
Programming model best practices Aspects of the programming model for a given tier to consider: components that you develop hosted on that tier mechanisms used to flow control between components sources 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 Distributed Object Server Enterprise Server
Servlets, JSPs, View Beans, Tags
sendRedirect(), forward(), include()
Request, Session, Servlet Context
Session EJB, Entity EJB, Key/Data Beans
RMI/IIOP
JNDI, JDBC, others
BMP Entity EJB, SessionSynch EJB
beforeXXX(), afterXXX(), ejbXXX()
JNDI, JDBC, others
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
18 of 57
IBM Software Services for WebSphere
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 Web Application Server
Browser Product Catalog
Order Details
customerID orderID status products
items
0..n
0..n
Product productID description
Order Status
Customer Home
HTTP
customerID
0..n
Order orderID status
cancel
add to order
Action Result message
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
Confirm Submit ok {submit order}
IIOP
create()
Confirm Open
[qty < 0]
{modify item (product, quantity)} Action Result
ok
submit
Application flow dynamic model
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
open {create order}
Order Details
edit line item
ok {cancel order}
Distributed Object Server
Order Status (order)
Product Catalog
orders
Line Item productID description quantity
Customer Home
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Fulfillment
Shipping Marketing ship (shipper) [all items shipped] Completed purge
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Enterprise Logic & Data Server ???
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
© 2003 IBM Corporation
19 of 57
IBM Software Services for WebSphere
The network traffic problem, part 1 Think about what would happen if each transition were to result in a request to the web server... Customer Home
problem 4: what if there were lists or cascading menus?
Order Status
open
(order)
Product Catalog add to order {add item (product, quantity)}
problem 3: what about invalid quantities? cancel (order) Confirm Cancel
Order Details
Action Result
02_Part_1_Web_App.PRZ
{create order}
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
October 28-29, 2003 | Sydney
(order)
problem 1: this confirmation would cause extraneous call to web server
ok {submit order}
ok
Confirm Open
problem 2: this confirmation would likely require rerendering details
© 2003 IBM Corporation
20 of 57
IBM Software Services for WebSphere
Full use of Java Script Consider JavaScript to handle transitions (and associated states) on the browser, such as confirmations, validations, lists and menus Customer Home
Order Status open
(order)
Product Catalog
advantage 2: validating quantity causes no request
add to order {add item (product, quantity)}
cancel (order) Confirm Cancel
Order Details
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
{create order}
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
question: should we check for the quantity being less than available inventory?
(order)
Action Result
ok {submit order}
ok
Confirm Open
advantage 1: confirmation causes no request
tradeoff: makes pages more complex, less portable © 2003 IBM Corporation
21 of 57
IBM Software Services for WebSphere
Syntactic validation using Java Script Validations should be limited to checking the format of values (syntactic validation), and possibly ranges (if understood) Customer Home
status: we have minimized the number of requests to the server
Order Status open
(order)
Product Catalog
check for non zero integer is ok
add to order {add item (product, quantity)}
cancel (order) Confirm Cancel
Order Details
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
{create order}
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
warning: validations still need to occur on server side!
(order)
Action Result
ok {submit order}
ok
Confirm Open
check for integer > 0 is ok
these validations should have been explicitly shown on the diagram © 2003 IBM Corporation
22 of 57
IBM Software Services for WebSphere
The web page granularity problem Now think about what would happen if each state were to be represented by a web page... either: each page is relatively small, but navigation would require heavy use of the "back" button...
Customer Home
Product Catalog add to order {add item (product, quantity)}
cancel (order) Confirm Cancel
Order Details
(order)
{create order}
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
Action Result
02_Part_1_Web_App.PRZ
open
(order)
ok {cancel order}
October 28-29, 2003 | Sydney
Order Status
ok {submit order}
ok
Confirm Open
or: each page would require redundant data and navigations
© 2003 IBM Corporation
23 of 57
IBM Software Services for WebSphere
Using framesets and named windows Consider using framesets or named windows to consolidate related states into a single page Customer Home
Navigation area
Order Status open
(order)
Product Catalog add to order {add item (product, quantity)}
Main area cancel (order) Confirm Cancel
Order Details
Action Result
02_Part_1_Web_App.PRZ
{create order}
ok
Confirm Open
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
October 28-29, 2003 | Sydney
(order)
ok {submit order}
Action result area
© 2003 IBM Corporation
24 of 57
IBM Software Services for WebSphere
Framesets and Named Windows: another view One possible frameset view of the application flow Navigation Area
Main Area displays Product Catalog, Order Status or Order Details, depending on selection
simply the Customer Home 'navigation bar' where selections target main area
adding to order, editing quantity, cancelling or submitting targets result area
Action Result Area advantage 1: smaller requests invoked in parallel to load page
advantage 2: only affected areas of the page are re-rendered
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
issues: more complex, less portable, harder to print and bookmark © 2003 IBM Corporation
25 of 57
IBM Software Services for WebSphere
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 downloaded only 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 displayed makes it easier to design for multiple device types not yet ubiquitous, so the web server should be able to handle rendering HTML prior to reply (more on this later) October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
26 of 57
IBM Software Services for WebSphere
Summary for Web page design 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 October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
27 of 57
IBM Software Services for WebSphere
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 Web Application Server
Browser Product Catalog
Order Details
customerID orderID status products
items
0..n
0..n
Product productID description
Order Status
Customer Home
HTTP
customerID
0..n
Order orderID status
cancel
add to order
Action Result message
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
Confirm Submit ok {submit order}
IIOP
create()
Confirm Open
[qty < 0]
{modify item (product, quantity)} Action Result
ok
submit
Application flow dynamic model
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
open {create order}
Order Details
edit line item
ok {cancel order}
Distributed Object Server
Order Status (order)
Product Catalog
orders
Line Item productID description quantity
Customer Home
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Fulfillment
Shipping Marketing ship (shipper) [all items shipped] Completed purge
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Enterprise Logic & Data Server ???
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
© 2003 IBM Corporation
28 of 57
IBM Software Services for WebSphere
The servlet granularity problem Think about what would happen if we only created a single HttpServlet to control the entire application... Customer Home
problem 1: only one programmer could work at a time
cancel (order) Confirm Cancel
Order Details
Action Result
October 28-29, 2003 | Sydney
(order)
{create order}
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
02_Part_1_Web_App.PRZ
open
(order)
Product Catalog add to order {add item (product, quantity)}
Order Status
ok {submit order}
ok
Confirm Open
problem 2: the code would be rather complex to handle all the states and transitions
problem 3: can't use servlet level security, monitoring... © 2003 IBM Corporation
29 of 57
IBM Software Services for WebSphere
HttpServlets end-to-end flow Using an HttpServlet to control the processing associated with a state in the application flow Client Web Browser
Web Application Server
HTTP POST [loc = OrderStatusServlet? OrderStatusServlet? customer=1111] action=add&cust=1111
Order Status Servlet
service(req, res) req.getParameter("action") "add" req.getParameter("cust") "1111" {add order for Customer 1111} res.getPrintWriter().println("...")
[res = "..."] "HTML for Order Details 1000" [loc = OrderStatusServlet? action=add&cust=1111] October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
{repeat}
problem: what happens if the user hits reload, resize, print, ... ? © 2003 IBM Corporation
30 of 57
IBM Software Services for WebSphere
The reload problem Inadvertant re-execution of an HttpServlet due to browser events like reload, resize, back, forward, print Client Web Browser
Web Application Server
HTTP GET [loc = OrderStatusServlet? OrderStatusServlet? customer=1111] action=add&cust=1111 "HTML for Order Details 1000" [loc = OrderStatusServlet? action=add&cust=1111] {reload}
HTTP GET OrderStatusServlet? action=add&cust=1111
Order Status Servlet
service(req, res) {add order for customer 1111 and generate HTML} using POST for update actions helps, but user can still invoke a reload service(req, res)
"HTML for Order Details 1001"
{add order for customer 1111 and generate HTML}
problem: data integrity errors! October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
31 of 57
IBM Software Services for WebSphere
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 Client Web Browser
Web Application Server
Order Status Servlet
Order Details Servlet
HTTP POST [loc = advantage 2: all the logic associated with OrderStatusServlet? OrderStatusServlet? a state is in the associated HttpServlet customer=1111] action=add&cust=1111 service(req, res) {add new order for HTTP REDIRECT customer 1111} OrderDetailsServlet?order=1000 {browser intercepts} HTTP GET OrderDetailsServlet?order=1000
service(req, res)
{get details for order 1000 and "HTML for Order Details 1000" generate HTML} [loc = Order advantage 1: solves problem: logic handling DetailsServlet? updates is intermixed with reload problem order=1000] that for reads in service() {reload} October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
32 of 57
IBM Software Services for WebSphere
HttpServlet doGet() and doPost() end-to-end flow Use doGet() to handle display for a dynamic state and doPost() to handle update transitions Client Web Browser
Web Application Server
Order Status Servlet
Order Details Servlet
HTTP POST [loc = OrderStatusServlet? OrderStatusServlet? customer=1111] action=add&cust=1111 doPost(req, res) HTTP REDIRECT {add new order for customer 1111} OrderDetailsServlet?order=1000 problem 1: cannot {browser intercepts} independently develop or HTTP GET modify logic and layout OrderDetailsServlet?order=1000 doGet(req, res) {get details for order 1000 and "HTML for Order Details 1000" generate HTML} [loc = Order advantage: doPost() and problem 2: can't use DetailsServlet? doGet() can be developed WYSIWYG editor to order=1000] and tested separately help generate HTML {reload} October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
33 of 57
IBM Software Services for WebSphere
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 advantage 2: Web Application can use an IDE for logic Server
advantage1: Order can develop Details & maintain JSP in parallel doGet(req, res) {geti detailsi for order 1000} req.setAttribute("name ", value ) {repeat for each order i i [name = value ] detail variable} getServletContext(). problem 2: problem 1: getRequestDispatcher( multiple name/type "...OrderDetails.jsp" sets/gets convention ).forward(req, res)
Order Details Servlet
i
i
<%=()req.getAttribute("name ")%> {repeat}
value
... [res = "HTML for Order problem 3: must Details 1000"] use expressions and cast result October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
advantage 3: can use a WYSIWYG editor for HTML © 2003 IBM Corporation
34 of 57
IBM Software Services for WebSphere
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 Web Application Server
Order Details Servlet
Order Details Data
Order Details JSP
doGet(req, res)
advantage1: only {get details for order 1 1000} n one set/get with new(v , ..., v ) req.setAttribute( 1 1 n n well defined [p =v , ..., p =v ] name/type "OrderDetails", OrderDetailsData OrderDetailsData) [OrderDetails = getServletContext().getRequestDispatcher( OrderDetailsData] "...OrderDetails.jsp").forward(req, res) advantage 3: <jsp:usebean name=OrderDetails type=OrderDetailsData> tools in both OrderDetailsData IDE and i ... <jsp:beanproperty bean=OrderDetails property=p > page editors i ... getP () use Java i v advantage 2: no Beans i Java required [res = "... v ..."] except for loops {repeat} October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
35 of 57
IBM Software Services for WebSphere
The contract problem Think about how to tell where JSPs and view beans would be useful Customer Home
can't really tell from this dynamic model
cancel (order) Confirm Cancel
Order Details
Action Result
October 28-29, 2003 | Sydney
(order)
{create order}
ok
Confirm Open
edit line item submit (order) {modify item (product, Confirm Submit quantity)}
ok {cancel order}
02_Part_1_Web_App.PRZ
open
(order)
Product Catalog add to order {add item (product, quantity)}
Order Status
ok {submit order}
© 2003 IBM Corporation
36 of 57
IBM Software Services for WebSphere
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 Product Catalog
Order Details
Order Status
customerID orderID status
customerID
Customer Home
little or no dynamic content handled in JavaScript
0..n
0..n
Product
Line Item
productID description
productID description quantity
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
0..n
Order orderID status
Action Result message
Confirm Action action
© 2003 IBM Corporation
37 of 57
IBM Software Services for WebSphere
How do you eliminate Java in JSPs? Consider custom tags for loops and object navigation instead of Java scriptlets ... <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"%> ... <% } %>
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
... <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"/> ...
© 2003 IBM Corporation
38 of 57
IBM Software Services for WebSphere
Basic HttpServlet design summary 1. HTTPServlets control states and associated transitions doGet() gathers data to display doPost() handles updates and flows to next state use sendRedirect after updates to avoid reload problem
2. JSPs generate the view associated with state View beans encapsulate data needed by JSP Custom tags eliminate Java in JSPs
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
39 of 57
IBM Software Services for WebSphere
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 Web Application Server
Browser Product Catalog
Order Details
customerID orderID status products
items
0..n
0..n
Product productID description
Order Status
Customer Home
HTTP
customerID
0..n
Order orderID status
cancel
add to order
Action Result message
Confirm Action orderID action
Application flow static model
Confirm Cancel
[qty = 0] {add item (product, quantity)}
Confirm Submit ok {submit order}
IIOP
create()
Confirm Open
[qty < 0]
{modify item (product, quantity)} Action Result
ok
submit
Application flow dynamic model
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
open {create order}
Order Details
edit line item
ok {cancel order}
Distributed Object Server
Order Status (order)
Product Catalog
orders
Line Item productID description quantity
Customer Home
add line item (product, quantity)
Entry modify line item (product, quantity)
Customer
submit() cancel()
Fulfillment
Shipping Marketing ship (shipper) [all items shipped] Completed purge
[not all items pack line item shipped] (product, quantity)
Business process dynamic model
Enterprise Logic & Data Server ???
Product
Customer
sku description
customerID
openOrder product
Line Item quantity
0..n
0..1 customer
Order 0..n
orderID status
Business process static model
© 2003 IBM Corporation
40 of 57
IBM Software Services for WebSphere
The "page composition" problem Think about how you would deal with the situation where framesets or named windows cannot be used on the client Customer Home
Customer Home Action Result Product Catalog
adding an item to the order redisplays catalog page
want to reuse code to render "substates" of a given page
Action Result Order Status
selecting or adding an order displays details
Customer Home Action Result Order Details
modifying an item, or submit/cancel redisplays order
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
41 of 57
IBM Software Services for WebSphere
RequestDispatcher include() end-to-end flow Use the include() function to compose pages from HttpServlets representing the application flow states Client Web Browser
Web Application Server
Product Catalog Servlet
Customer Home JSP
HTTP GET advantage 1: easy to tradeoff 1: static ProductCatalogServlet? bookmark, print ... states must be JSPs doGet(req, res) start=101 tradeoff 2: must {get products from advantage 2: re-render whole page access bean} can be reused in for every call include( multiple pages problem: maintaining "CustomerHome.jsp", common look and req, res) feel across pages doGet(req, res) {generate "HTML fragment for navigation area} navigation area" [res = "HTML fragment tradeoff 3: ugly URLs for navigation area"] on location line "HTML for composed {repeat include for other "substates", Product Catalog page" like Results and Product Catalog JSP} October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
42 of 57
IBM Software Services for WebSphere
The "common look & feel" problem Think about how unmaintainable the application would be if we modeled and coded behaviors common to every state? Errors
Source State some event
[ok]
[retry]
[authenticated] [not authenticated]
Login
[locked]
October 28-29, 2003 | Sydney
pages may share components
[no errors]
may want different behaviors for GET/POST events
login {authenticate uid & password}
Locked
02_Part_1_Web_App.PRZ
[errors] {some action}
Target State
may want different layouts depending on user's national language, or support different browser types © 2003 IBM Corporation
43 of 57
IBM Software Services for WebSphere
HttpServlet inheritance end-to-end flow Use inheritance and factor common behaviors into an extensible HttpServlet class hierarchy Client Web Browser
Web Application Server
Product Catalog Servlet
Online Buying Servlet
advantage 4: can problem: declare final & abstract minimizing back for enforcement end accesses {check authorization: if not, advantage 1: naming forward to Login JSP} convention makes it doGetOnlineBuying(req, res) could modify easy to extend hierarchy include to include( advantage 2: subclass generate XML "ProductCatalog", methods focus on req, res) advantage 3: instead gathering data, inherited {append directory of user's handling updates convenience preferred language to methods make name and forward} advantage 5: can develop developing & look and feel separately maintaining {catch errors: if any, "HTML for Product even easier forward to Error JSP; Catalog starting at otherwise compose page} item 101" HTTP GET ProductCatalogServlet? doGet(req, res) start=101
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
44 of 57
IBM Software Services for WebSphere
The network traffic problem, part 2 Consider caching the data structure Java Bean for a state in HttpSession to eliminate extraneous back end accesses Client Web Browser
Web Application Server HTTP GET
Order Details Servlet
OrderDetailsServlet?...
doGet(req, res) req.getSession(false).getValue("OrderDetails")
advantage 1: handles timeout
null
{getOrderDetails()} req.getSession(true).putValue("OrderDetails", OrderDetailsBean)
[session = <"OrderDetails", OrderDetailsBean>] "HTML for Order Details"
{OrderDetailsJSP}
{...}
HTTP GET ... doGet(req, res) advantage 2: session req.getSession(false).getValue("OrderDetails") shared across OrderDetailsBean contexts {OrderDetailsJSP} "HTML for Order Details" problem: cache consistency! {repeat} October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
45 of 57
IBM Software Services for WebSphere
The "cache consistency" problem Application events can cause session state to be out of synch with respect to the enterprise data source Client Web Browser
Web Order Order problem 3: Application Status Details what happens Server Servlet Servlet in a clustered [session = configuration? [loc = OrderStatusServlet? <"OrderStatus", OrderStatusBean 1111>, customer=1111] <"OrderDetails", OrderDetailsBean 1000>] problem 2: HTTP POST OrderStatusBean OrderStatusServlet? is out of date action=add&cust=1111 doPost(req, res) HTTP REDIRECT {add new order for customer 1111} OrderDetailsServlet?order=1001 {browser intercepts} POST alternatives: HTTP GET must remove or reread OrderDetailsServlet?order=1001 doGet(req, res) req.getSession(false). problem 1: getValue("OrderDetails") OrderDetailBean does not match order desired OrderDetailsBean 1000 {OrderDetailsJSP} "HTML for Order Details 1000" GET alternatives: must check keys or cache multiple copies October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
46 of 57
IBM Software Services for WebSphere
The "cluster consistency" problem Application events in a clustered environment can cause the session state on different nodes to get out of synch Client Web Browser
Web Application Server 1
Web Application Server 2
HTTP GET OrderDetailsServlet?order=1000 {read details, set session and generate HTML} [session = <"OrderDetails", OrderDetailsData>] "HTML for Order Details 1000" HTTP POST problem: cache is OrderDetailsServlet?action=buy& out of synch order=1000&product=101&qty=1 {update order} [session = ???] HTTP REDIRECT OrderDetailsServlet?order=1000 {browser intercepts} cluster alternatives: turn on affinity, HTTP GET or share persistent sessions OrderDetailsServlet?order=1000 {get session and generate HTML} symptom: subsequent displays routed "HTML for Order Details 1000" to different nodes are inconsistent October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
47 of 57
IBM Software Services for WebSphere
Client-server affinity end-to-end flow Use client-server affinity to insure cache consistency where performance considerations are highest priority Client 1 Web Browser
Web Application Server 1
Web Application Server 2
HTTP GET OrderDetailsServlet?order=1000 {read details, set session and generate HTML} [session = <"OrderDetails", OrderDetailsData>] "HTML for Order Details 1000" HTTP POST advantage: sessions can be stored OrderDetailsServlet?action=buy& in memory for fastest access order=1000&product=101&qty=1 HTTP REDIRECT {update order} problem 1: clients sharing an ISP often appear like the "same" OrderDetailsServlet? [session = ???] order=1000 client, reducing load balancing {browser intercepts} effectiveness HTTP GET OrderDetailsServlet?order=1000 problem 2: does not {get session and generate HTML} support failure bypass "HTML for Order Details 1000" October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
48 of 57
IBM Software Services for WebSphere
Shared persistent session state end-to-end flow Persist sessions in a shared database when load balancing and failover requirements have highest priority Client Web Browser
advantage 2: full Web Web failover support is Application Application Server 1 Server 2 enabled HTTP GET get session OrderDetailsServlet?order=1000
Shared Session Database
null set session = <"OrderDetails", OrderDetailsData> [session = <"OrderDetails", "HTML for Order Details 1000" OrderDetailsData>] problem: what about data shared across users? HTTP POST OrderDetailsServlet?action=buy& remove session order=1000&product=101&qty=1 HTTP REDIRECT [session = ] OrderDetailsServlet?order=1000 {browser intercepts} advantage 1: cache is always HTTP GET synchronized across nodes get session OrderDetailsServlet?order=1000 tradeoff: cache consistency complexity and you end up reading database anyway
"HTML for Order Details 1000" October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
null © 2003 IBM Corporation
49 of 57
IBM Software Services for WebSphere
ServletContext end-to-end flow Consider caching data common to all users in Servlet Context to minimize enterprise access and session size Client Web Browser
Web Application Server
HTTP GET ProductCatalogServlet?start=101
Product Catalog Servlet
doGet(req, res) getServletContext().getAttribute("ProductCatalog") advantage: handles null failure problem 2: have to check for null and load everywhere {getProductCatalog()} getServletContext().setAttribute("ProductCatalog", ProductCatalogData) [context = <"ProductCatalog", ProductCatalogData>] "HTML for Products 101..."
{ProductCatalogJSP}
{...}
doGet(req, res) HTTP GET... start=1851 getServletContext().getAttribute("ProductCatalog") problem 1: servlet context productCatalogData is not sharable in a cluster! {ProductCatalogJSP} "HTML for Products 1851..."
October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
50 of 57
IBM Software Services for WebSphere
HttpServlet init() end-to-end flow Use the HttpServlet init() method to preload stable readonly data into ServletContext cache and servlet instance variables Client Web Browser
Web Application Server
HTTP GET ProductCatalogServlet?start=101
Product Catalog Servlet
advantage 1: data stability eliminates {only first call invokes init} advantage 2: other need for affinity init() HttpServlet instances (same or different getServletContext().getAttribute("ProductCatalog") classes) will find data null {getProductCatalog()} getServletContext().setAttribute("ProductCatalog", ProductCatalogData) [context = <"ProductCatalog", ProductCatalogData>] advantage 3: doGet & doPost is guaranteed to doGet(req, res) have cache loaded {ProductCatalogJSP} "HTML for Product Catalog" problem: caching logic (either in session or context) {...} adds a lot of complexity to web application flow October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
51 of 57
IBM Software Services for WebSphere
Advanced HttpServlet design summary 1. Design JSPs so that they can be composed with include 2. Capture common look-and-feel in inherited HttpServlets rather than "gateway" servlets 3. Let superclass servlet decide whether to call JSP or generate XML for return to XSLT enabled browsers 4. HttpSession should only maintain easily recomputable values to avoid timeout problem 5. Check keys & remove session to avoid cache consistency problems 6. Use client-server affinity or persistent sessions to avoid cluster consistency problem 7. ServletContext should only cache stable readonly data 8. init method on HttpServlet can be used to load cache October 28-29, 2003 | Sydney
02_Part_1_Web_App.PRZ
© 2003 IBM Corporation
52 of 57