Moving Web Apps From Synchronous to Asynchronous Processing Jason Carreira Architect, ePlus Systems OpenSymphony member

Normal web processing Users make requests and wait for the response Each user’s browser holds an open connection, waiting for the server to send back the page or file

What if requests come too fast?

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

What causes the problem? Too many users / too many requests Popularity can be a curse

What causes the problem? (continued) Processing requests takes too long Too much work Some things just take a long time

What causes the problem? (continued) Integrating with backend systems Remote roundtrips take a long time

So what do we do? Some ideas… Faster Hardware Clustering Worker Threads Messaging Middleware (JMS)

Hardware and Clustering Works well for scaling up number of users Long running processing and system integrations still take a long time

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

What can asynchronous processing solve? Too many users / too many requests Long running processing Time consuming calls to backend systems

What can asynchronous processing solve? Too many users / too many requests Long running processing Time consuming calls to backend systems

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

An example: Searching for flights

So how do we build it?

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

Normal Web MVC: Each user request is handled synchronously

Executing in a Worker Thread

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

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

Let’s 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

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.

Bridging the Synchronous / Asynchronous Gap The SendMessageAction creates a MapMessage with the request and configuration parameters Can be configured to execute any Action

Looking at a Message Driven Example Uses MessageWork, based on XWork Shows the same Action configured to be executed from a JMS Queue

Some Implementation Challenges with MessageWork JMS vs. 1.1 compatibility Implementing Session / Application contexts and propagation Integration and System testing

Further Ideas Federated web applications Online and Batch mode web applications

Questions?

For More Information The WebWork and XWork projects from OpenSymphony ( The Xwork-Optional project (home of MessageWork) at optional.dev.java.net/ optional.dev.java.net/ Check out “WebWork in Action” from Manning