Moving Web Apps From Synchronous to Asynchronous Processing
Jason Carreira Architect, ePlus Systems OpenSymphony member Slide 2
Normal web processing Users make requests and wait for the response
Each users browser holds an open connection, waiting for the server
to send back the page or file Slide 3 What if requests come too
fast? Slide 4 What if requests come too fast? (continued) Requests
back up Each request requires some resources on the server side
Users are left waiting with no feedback Requests start to take
LONGER, making the problem escalate Slide 5 What causes the
problem? Too many users / too many requests Popularity can be a
curse Slide 6 What causes the problem? (continued) Processing
requests takes too long Too much work Some things just take a long
time Slide 7 What causes the problem? (continued) Integrating with
backend systems Remote roundtrips take a long time Slide 8 So what
do we do? Some ideas Faster Hardware Clustering Worker Threads
Messaging Middleware (JMS) Slide 9 Hardware and Clustering Works
well for scaling up number of users Long running processing and
system integrations still take a long time Slide 10 Worker Threads
and JMS: Asynchronous Processing Separates processing web request
and doing the work Users get a response quickly, get full response
when work is done Slide 11 What can asynchronous processing solve?
Too many users / too many requests Long running processing Time
consuming calls to backend systems Slide 12 What can asynchronous
processing solve? Too many users / too many requests Long running
processing Time consuming calls to backend systems Slide 13 Giving
the user feedback The user gets a response showing a working page
The page refreshes periodically to check if the work is done When
the work is done, the server redirects the user to see the final
result Slide 14 An example: Searching for flights Slide 15 So how
do we build it? Slide 16 Normal Web MVC Processing The controller
routes the request to the correct Action The Action executes
(calling services, DAOs, etc) and specifies which view to render
The view is rendered and returned to the user Slide 17 Normal Web
MVC: Each user request is handled synchronously Slide 18 Executing
in a Worker Thread Slide 19 Executing in a Worker Thread
(continued) The first request creates a thread to execute the
Action A working page is shown to the user which refreshes to check
if the Action is done When the Action is done, the final view is
rendered Slide 20 The ExecuteAndWait Interceptor Catches the
request processing before it gets to the Action Creates a Thread
and gives it the Action to execute Sends the user to the working
page Slide 21 Lets Look at Some Code (Finally)! Based on XWork /
WebWork Show the same Action executed synchronously and
asynchronously Look at the framework code that makes it work Slide
22 Executing from a Message Queue The controller is a JMS
MessageListener (can be an MDB) The Result can send a message on a
response queue, send messages on the same work queue, etc. Slide 23
Bridging the Synchronous / Asynchronous Gap The SendMessageAction
creates a MapMessage with the request and configuration parameters
Can be configured to execute any Action Slide 24 Looking at a
Message Driven Example Uses MessageWork, based on XWork Shows the
same Action configured to be executed from a JMS Queue Slide 25
Some Implementation Challenges with MessageWork JMS 1.0.2 vs. 1.1
compatibility Implementing Session / Application contexts and
propagation Integration and System testing Slide 26 Further Ideas
Federated web applications Online and Batch mode web applications
Slide 27 Questions? Slide 28 For More Information The WebWork and
XWork projects from OpenSymphony (http://www.opensymphony.com/) The
Xwork-Optional project (home of MessageWork) at https://xwork-
optional.dev.java.net/https://xwork- optional.dev.java.net/ Check
out WebWork in Action from Manning
