Moving Web Apps From Synchronous to Asynchronous Processing

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

2. 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

3. What if requests come too fast?

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

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

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

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

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

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

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

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

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

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

14. An example: Searching for flights

15. So how do we build it?

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

17. Normal Web MVC: Each user request is handled synchronously

18. Executing in a Worker Thread

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

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

21. 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

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.

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

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

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

26. Further Ideas • Federated web applications • Online and Batch mode web applications

27. Questions?

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/ • Check out “WebWork in Action” from Manning