The Significance of the new Servlet API
The servlet API has been one of Java's greatest successes. Evolving from version 1.0, introduced in 1997, servlets were incorporated in the Java 2 Enterprise Edition (J2EE) starting in 1999. The last major specification change was for version 2.5 in 2003. Now the Servlet 3.0 proposed final draft specification has been released for public review, so it is time to examine the new features. But first let's summarize the evolution from version 1.0 through version 2.5:
- Deployment descriptor. Standardized on web.xml for communicating deployment settings to the container. Initial versions used a hodge-podge of vendor specific files.
- Security. Methods which permitted information to "leak" between applications have been removed or changed, mostly by version 2.1.
- Moving development to the Java community. Developing the specification moved to the Java Community Process as JSR 53 in 2000, with the first release of version 2.3 in 2001. This group also created the JSP 1.2 specification.
- Event listeners. Version 2.3 introduced a mechanism by which events affecting a Web application can be communicated to interested processes. Configuration is via entries in the web.xml deployment descriptor.
- Filters. Version 2.3 also introduced the concept of a "filter" which can redirect or modify a request and response. Filter configuration is also accomplished in the deployment descriptor.
The standard Java library and many specialized tools have evolved in many significant directions since the Java version common when servlet 2.5 was created. These improvements clearly can be useful to servlet developers. In particular, the language added non-blocking IO (NIO) in version 1.4 and annotations in version 1.5. The servlet 3.0 API makes use of both features.
Getting to 3.0
The process of getting to version 3.0 started in Ju...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
ly 2007. The various experts on the JSR committee went through a LOT of proposals and discussions and there were many changes from initial drafts. The following are the main points which the specification writers felt were most important:
- Application "plugability" and ease of deployment.
Program annotations and more flexible configuration are needed to make it easier to simply plug a new application into a servlet container. Ideally, Web applications using annotations would require zero extra configuration files. Java annotations, which let the developer add metadata to Java classes, have been very popular with toolkit developers because they facilitate plugability.
- Support for advanced IO concepts.
Before NIO, the Java networking tools required that each primitive network connection be assigned to a program Thread, thus imposing a serious limit on the number of "simultaneous" connections to a servlet container. Non-blocking input and output increases the number of requests which can be handled and works well with newer Rich Internet Application techniques such as AJAX.
- Alignment with Jersey and other advanced tools.
Significant innovations in Web services toolkits such as the RESTful Web service API (JSR 311) implemented in the Jersey project depend on the servlet API. Servlet 3.0 will support Jersey and many other technolgies such as Java Server Faces, Portlets, and JavaFX.
Unchanged from 2.5
Although servlet configuration possibilities have been greatly expanded, the basic simple servlet life-cycle is unchanged. The servlet container manages the creation of an instance of the servlet class and calls the init() method with information about the context the servlet will operate in before any request is handled. The servlet container is responsible for creating objects representing a request and response and calling the service() method. When the servlet instance has to be closed down, the destroy() method is called so that resources used by the servlet can be properly disposed of. The simplicity of this life-cycle has made it easier for developers used to desktop applications to work in the Web environment.
The Role of Annotations
The use of Java annotations to simplify the deployment of applications has been proven in projects such as Jersey. In the Servlet 3.0 API, the javax.servlet.annotation package contains 6 annotation types used in declaration of servlets, filters and listeners. The following lists these annotation types and functions by name:
- HandlesTypes.
Defines a list of "types" used by the ServletContainerInitializer on initial startup of a server. This list will be used to look for servlet and filter classes.
- MultipartConfig.
In the past, file uploads were not supported directly by the servlet API and programmers used a variety of tools. In servlet 3.0 multi-part/form-data POST requests are supported and this annotation provides information to control them. For example you can define the maximum file size which will be accepted.
- WebFilter.
A servlet filter object controls requests before they are handed to a servlet and handles responses before they are sent to the client. Typical uses on incoming requests include authentication of users, and logging. Outgoing response functions include encryption and compression. This annotation is used to set up how filter classes are associated with URL request patterns and to indicate that a filter class can handle asynchronous NIO.
- WebInitParam.
These annotations provide a way to specify initialization parameters in a servlet or filter class by name and value which are the equivalent of "init-param" entries in web.xml.
- WebListener.
Listeners are classes which receive event notifications during the course of the life of a web application. The servlet 3.0 API defines at least 9 different listener interfaces. Rather than defining an annotation for each type, this annotation declares that a class is a listener, but the container must examine the class and register an instance to receive the appropriate events.
- WebServlet.
This annotation marks a class as being an extension of the HttpServlet base class and provides extensive facilities for defining many parameters to be associated with the servlet instance. For example, the URL patterns it will respond to and whether it supports asynchronous operations.
Asynchronous Operations
The servlet 2.5 request handling on a one Thread per request continues to be available but major additions have been required to optimize use of non-blocking IO. Annotations must be used on filter and servlet classes to indicate that they are capable of making use of NIO. The basic servlet request and response interfaces have major additions to cope with NIO.
Glassfish and Servlet 3.0
For versions of the Servlet API through 2.5, the Apache Tomcat project was the reference implementation. There seems to be some conflict between Sun and the Apache Software Foundation over license terms for the Java Compatibility Kit. For this reason, and not the technical merit of the API, the Glassfish project, not Tomcat is the reference implementation.
The Glassfish v3 distribution is a complete implementation of all of the components of the upcoming Java Enterprise Edition verion 6. Thus it contains much more than a minimum web server. Goodies of interest include the Jersey RESTful web service toolkit, Java Server Faces, and many other new technology projects. As of this writing, Glassfish v 3.0 is released as a "web preview" with new builds roughly every week.
Conclusion
The servlet 3.0 API is a major step forward, bringing the best current Java language capabilities and practices to web developers. This has been accomplished without seriously impacting developers using the servlet 2.5 API.
Resources
JSR315, the Java Servlet 3.0 Specification
Sun tutorial on Annotations
JAX-RS Annotations and RESTful Web Services
