JSR 315 - Servlet 3.0

Asynchronous Servlet Discussion

Abstract

This document contains a discussion regarding the requirements to
extend the Servlet API as defined by JSR 154 with asynchronous
concerns to meet the goals of JSR 315.

Introduction

JSR 315 Targeted features

JSR 315 nominates "Async and
Comet Support" as a targeted feature, described as:

Non-blocking input

The ability to receive data from a
client without blocking if the data is slow arriving.

Non-blocking output

The ability to send data to a client
without blocking if the client or network is slow.

Delay request handling

The comet style of Ajax web
application can require that a request handling is delayed until
either a timeout or an event has occurred. Delaying request handling
is also useful if a remote/slow resource must be obtained before
servicing the request or if access to a specific resource needs to be
throttled to prevent too many simultaneous accesses.

Delay response close

The comet style of Ajax web
application can require that a response is held open to allow
additional data to be sent when asynchronous events occur.

Blocking/Non-blocking notification

The ability to notify push blocking
or non-blocking events. Channels concept - The ability to subscribe
to a channel and get asynchronous events from that channel. This
implies being able to create, subscribe, unsubscribe and also apply
some security restriction on who can join and who
cannot.

Additional Requirements

The following additional requirements
have been used to guide the design of this proposal. These
requirements are only from the experience of the author and should
themselves be subject to review and discussion:

Service method

All substantive
handling of asynchronous requests and generation of asynchronous
responses should take place within the existing calling chain through
Filter.doFilter(..)
to {{Servlet.service(...).}}It is only within this calling chain
that we have a well defined environment for authentication,
authorization, JNDI, and access to other Java EE services. The creation
of additional request handling or response generating methods will
require substantial redefinition of the servlet environment and will
impede frame work compatibility.

First Class Servlet

An asynchronous servlet should be a
first class servlet and not limited in any significant way. To this
effect an asynchronous servlet should be able to:

• Be filtered by name or URL path.
• Be secured by standard security mechanisms
• The initiator or target of a RequestDispatchers

Framework compatibility

Handling of asynchronous requests and
responses should be able to be done by existing frameworks with
little or no modification. For example, JSP and/or JSF should be able
to be used to handle a comet request and to generate the comet
response.

Container IO empowerment

The servlet container should be empowered to handle common or difficult IO tasks
that are currently handled by the servlet developer. With 2.5
servlets, the only content-type that is automatically handed by the
container is "application/x-www-form-urlencoded".
The servlet developer (or framework) must handle common tasks such
as:

• Parsing multi-part mime
• Parsing XML to DOM from request input streams
• Writing DOM to response output streams
• Moving data from requests to Files or Files to responses.

It is exceedingly difficult, if not impossible to design an API that would allow these tasks to be handled by user extensible code in the most efficient mechanism available to the container. Simple decisions such as choice of buffer type in the API (eg byte array or NIO Buffer) can greatly affect the efficiency, portability and lifespan of the API
and handlers based on it.

Even with an API, it is a complex and bug-prone task to write asynchronous content
handlers for every servlet application and/or framework. To remove this source of
errors and duplicated effort, the servlet
container should instead be empowered to implement common IO tasks on
behalf of the servlet developer. The container could then be free to
use efficient asynchronous techniques (or even native optimizations)
to perform IO on behalf of the servlet developer.