Greg Murray's Blog

July 2005 Archives

Got Servlets?

Servlets are one of the older APIs that is now part of Java Enterprise Edition (Java EE). Look at JSF, Struts, Tapestry, Velocity, Shale, or any of the other Java EE or Java based web frameworks and you will see servlets at the core.

The servlet API has stood the test of time because it was designed good from the start and has evolved slowly. As part of Java EE 5.0 servlets will be undergoing a maintenance release. At the same time the servlet EG is starting to think about the direction to take the next major Servlet release in the future.

Some suggestions we have had that we are looking into for the next major release of servlets include:

• Multipart-Support - File upload support.
• Improved Security - This has been an area where we have wanted to refine for sometime. This may includes APIs for programatic login.
• Self Registration - The ability to create accounts and have a remember me cookie.
• Annotation Support - Make servlets easier to define by reducing the number of artifacts a developer needs to create.

The list above is not an exhaustive list but should give an idea as to the direction we see the Servlet API going. As the Servlet specification lead I would also like to invite suggestions from the community at large.

How are you using Servlets? Where do you want them to go?

AJAX - X = No Dice

Most of the focus I seen in the AJAX world seems to revolve around the JavaScript and DHTML operations on the client. Without the 'X" in AJAX you really can't have any rich interaction. At JavaOne there has been much talk about AJAX. There have been some discussions about server-side AJAX components returning other content types than XML. Below are two general models I see with AJAX today. While there are other strategies the two below summaries much of what is used today.

• Returning XML/XML Fragments - This strategy allows for structured data to be interchanged. This strategy requires the server-side component that processes the AJAX request to set content-type header of the HTTP response is set to "text/xml". The benefit of this approach is that you may retrieve a DOM object representing the XML document returned from the server-side component in the callback of a the XMLHttpRequest by calling XMLHttpRequest.responseXML. You may navigate programatically the DOM and extract data from it or insert into the HTML DOM. Consider this strategy if you want to deal with structured data. Also consider this strategy if your server-side AJAX processing code needs to communicate with additional clients other than AJAX clients such as standalone clients, Java applets, or Flash clients that may want to use the same server-side processing.
• Returning Plain Text - In this case simple text is returned. The text may be retrieved by client-side JavaScript callback method by calling XMLHttpRequest.responseText. The text may be further processed on the client-side JavaScript or inserted into the document using the JavaScript DOM APIs or by setting the innerHTML attribute on an element to the text. Calling XMLHttpRequest.responseXML on a plain text will result in an error. JavaScript may also be passed as text and futher evaluated on the client. Generating client-side JavaScript using a server-side component could potentially bind the server-side AJAX code to a specific usecase. One interesting use of this strategy is the Dynamic Web Remoting (DWR) framework which uses AJAX to do RPC calls on server-side Java objects.

What type of content do you pass around with AJAX?

This work is licensed under a Creative Commons License.