Asynchronous Request Dispatcher Quick Start Guide

This is a quick guide to get started with the IBM Asynchronous Request Dispatcher (ARD)

• Configure the server to support ARD.


• Go to Servers->Server Types->WebSphere Application Servers->yourServer->Web Container Settings->Web Container-> Asynchronous Request Dispatching.


• Click check box for Allow Asynchronous Request Dispatcher.


• Click OK and save.

Code up your asynchronous include:
((IBMServletContext)getServletContext().getContext("/YourContext")).getAsyncRequestDispatcher("/YourServlet").include(request,response);

You can also retrieve an include and insert it later in the page as such:
AsyncRequestDispatcher dispatcher1 = ((IBMServletContext)getServletContext().getContext("/YourContext")).getAsyncRequestDispatcher("/YourServlet");
FragmentResponse response1 = dispatcher1.getFragmentResponse(request,response);
...
response1.insertFragmentBlocking(request,response);

• Install your ear as detailed below:


• Select server side or client side under "Asynchronous Request Dispatch Type" in Step 1 of the app install panels
  Server side will aggregate the includes in memory.
  Client side will aggregate on client side using javascript.
  I suggest using client side so you can verify its working more easily.
  To verify, just hit your servlet and click on the page and view source and you should see the javascript added to retrieve the include.
  

You can contact me on linkedin for more information.

Servlet 3.0 at java one

Just popping in for a few comments. If anyone saw the servlet 3.0 presentation, you'd know Jan, Rajiv, and Greg did a great job. I did notice a point of disagreement with greg. He mentioned that the simplest case of async servlets is startAsync followed by a dispatch to generate the response. I would argue that startAsync/complete is the simplest case. This requires no re-dispatch and a re-dispatch should not be needed unless you need something like jsp to do more complex content generation.

Also, it was not mentioned that the web fragment ordering effects and restricts annotation scanning as far as I recall. This is important to be able to prevent "rogue" framework jars from putting out servlets that can service requests without your knowledge

WebSphere Asynchronous Request Dispatcher

Please check out my blog on the Asynchronous Request Dispatcher introduced in Version 7.
Part 1, Part 2

WebSphere Community Blog

Please go to the WebSphere Community Blog to see some of the great things we have in Version 7.0 of WebSphere Application Server.

Servlet 3.0 Public Draft

This is in response to Greg Wilkins's blog about the Servlet 3.0 Public Draft.

We have discussed some of the use cases on the EG for things you have said do not have use cases. However, they are not in the Servlet spec and I think they should be. Also, I think your criticism of the JCP should be separate from your arguments about the Servlet spec. They are two different issues and when they are put together it just invites more defensiveness on the part of folks who have a higher interest in making JCP successful. Fixing the JCP is not something that's going to be fixed before we decide on a Final Draft, so I hope we can simply focus on the servlet issues at hand.

I'm not personally a huge fan of using forward semantics in the async case especially because it clears out any content already written which seems like a prime candidate for a reason to keep the wrappers. However, I do think it is better than not having any redispatch ability at all.

I still agree there should be a mechanism for excluding/including jars you need to scan for framework pluggability. However, that is not a showstopper for me and can certainly be a value add feature of any app server.