John B Moore
Micro-Phyla Systems
After the dust has settled on that new bleeding edge dynamic Web project, there will be one singular and dreaded reality, maintenance! The day after the project goes live, someone will need to change something, and most likely not a "minor something". If you have not designed your Web application, first and foremost for this contingency, you will regret that omission. With all the fast RAD schedules and "internet time" it is very easy to bypass the extra planning and design required to insure that the site will scale and evolve with the business, and within that framework, be maintainable. This session will be exploring the relationships between JSP, JavaBeans, HTML, and design patterns with a primary focus on how JavaBeans can be one major tool in your arsenal to help in maximizing maintainability. It is important to emphasize that I will not be covering all the available JSP syntax. There are other sources (books and websites) that cover this material quite well. Instead, a general strategy will be outlined, and only those parts of the JSP/JavaBean syntax that support that strategy will be discussed. There are many other strategies. Given the limitations of time, this will be only one. But should provide an outline for the types of issues you will need to address in your own quest for the truly maintainable, scalable website.
One of the first impressions many get when viewing the source code for a JSP page is the mixing of HTML, Java, and special JSP tags. It does not take long to realize that, if done improperly, this is a recipe for "nightmares in maintenance". Aside from the many proprietary schemes that have been developed from various vendors, there are only two basic components and a number of strategies to simplify this mix of languages in one document. The fundamental goal is to focus on keeping the HTML presentation layer separated from any logic, data access, and other bookkeeping chores. This is done by using:
In addition to Custom Tag libraries and JavaBeans, there a number of architectural patterns that can define the relationship between JSP, JavaBeans, HTML and Servlets. These architectural patterns also provide maintenance benefits and should be seriously investigated. These patterns, such as "Model-View-Controller", "Dispatcher", and "Service to Workers", to name a few, came about to solve problems and provide structure and maintenance features . Using Servlets as a controller or dispatcher factors out considerable amounts of java code that would be needed to authenticate users and route requests based on special conditions or business logic. Another approach is to utilize an existing framework or develop your own framework. Examples of such frameworks are; Cocoon, Resin and Struts, to name a few of the more common framework projects (see links provided at the end of this paper). Even if you feel like rolling your own, it is quite valuable to study these frameworks for ideas.
Our focus for this paper will be on the JavaBean primarily, to see how far we can go in simplifying a JSP document using JavaBeans. The patterns I will demonstrate will be a combination of the "Dispatcher" and "Service to Workers". You may wisely choose to use a framework in the end, but the exercise will be valuable and educational in understanding the relationships between servlets, JavaBeans and JSP. Ways that JavaBeans can bridge between Servlets and the JSP page will also be incorporated in the examples. Custom Tag Libraries can also factor into this but that becomes a bit to much too cover within a single presentation. There are many tutorials on the Web that can provide good overviews of the entire JSP specification (links provided at the end of this paper) of which will NOT be done here. Strategies that will minimize maintenance will be the over-riding theme. Those maintenance benefits come from the a number of general approaches in how JavaBeans are used that can be leveraged individually or in combination. I will divide those into the following groups.
The essential core concept that provides the most maintainability, is keeping as much "java" out of the JSP page as possible. This allows skilled HTML presentation designers to avoid learning little to no Java. At a minimum, very specific and well documented JSP "scriptlet tags" are provided by the Java programmer. It must be emphasized that ultimately a combination of JavaBeans and custom Tags will provide the minimum Java exposure in the JSP page. In this presentation the focus will be on "scriptlet" tags that can be used and are to be documented for the HTML designer. These "scriptlet" tags can be just as useful as custom Tags. These issues will be illustrated at various points, later in this paper.
What follows next are some key concepts within the JSP specification that I think warrant emphasis and will be referred to in later examples. This quick summary of these points is provided to refresh your memory before we dive into specific examples. The examples will be much more involved and complex, therefore, keeping the following concepts in mind will be helpful. Again I must emphasize that the JSP syntax covered will be very limited, and therefore by definition, incomplete. For a complete coverage, other sources are available (see links at end of paper).
You should already be familiar with JavaBeans as used in both visual and non-visual components in regular Java applications. There is nothing special about a JavaBean for the Web. It, just like any other JavaBean, must have a zero argument public constructor and use getter and setter methods to access non-public data fields in the class. Web JavaBeans, like their counter parts elsewhere in the Java world, are used to contain reusable functionality. These ideas sound simple, but the devil is in the details, as doing this in one way can create more work, another, minimizes work. JavaBeans for the Web provide plugable units of logic in which either a method can be called within the JSP page, or from within a custom JSP tag. Properties and values can be accessed with standard JSP tags. We will review those aspects of using JavaBeans that can be leveraged to minimize that work, and point out what aspects might be counter productive.
Before you can access any properties or methods from your JavaBean, the bean must first be loaded into your JSP page. The basic syntax is;
|
<jsp:useBean id="beanName" scope="page" class="package.Class" /> |
This can be thought of as equivalent to the Java code:
|
package.Class beanName = new package.Class(); |
Properly utilizing scope is critical to various design, memory efficiency, and coding considerations. In general, the bean should be only available where it is needed. The following reviews each scope, and examples of how this would be used. Remember, these are implicit objects created by the JSP container. You do not have to create them, but use accessors to obtain a handle to each of these scope objects.
The bean exists for the life of the page. This is the most restrictive state and the default. If you declare no scope in the useBean tag, then you get the page scope. When in doubt, leave the default setting. The access and instantiation of the bean will be limited to that page. Information is stored in the PageContext and is available using "this" keyword within the service methods. (See http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/jsp/PageContext.html for details.)
The bean's internal information is stored in the ServletRequest object and the bean will only be available for the current client request. This scope is handy for storing and making available information from page to "included" page, as well as available to other beans that receive the request object. Good uses of this scope are limited, but would include adding information to the request object that would be useful later in the request. An example of this might be a controller servlet that stuffs values into the request that it then forwards to a JSP page for presentation. Generally, even this use would be better handled by the next scope type, Session. Though it is entirely possible in particular situation that information is only useful during that single request, this is generally rare. In those cases the Request scope would be entirely appropriate.
(See http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpServletRequest.html for details.)
The bean is available to all of your JSP pages for the entire session unless, of course, you cause the bean to be destroyed. Information is stored in the HttpSession object. This scope is probably the most useful of all scopes in that it allows for communication between all the components of the web session. Via this scope, servlets and JSP can pass values and JavaBeans references to JSP pages and other servlets. This scope is very useful in the MVC design pattern of building a website.
(See http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html for details.)
The bean will remain until the application is reloaded or the server is restarted. Information is available to all pages that share the same ServletContext. This scope is useful for making "application" beans available from all sessions, both servlets and JSP pages. Only information that would be of use application-wide should be set to this scope. An example might be a management JavaBean that tracks request and "hit" rates, measures performance, and global properties like a database connection pool, and servicing issues would be very useful.
( See http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletContext.html for details.)
Once the JavaBean is available there are several techniques by which the JavaBean can interact with the document. They are:
This tag allows the developer to set values in the JavaBean. Unfortunately this often assumes that there was some logic in the JSP that generated a value that is needed somewhere else on the page, request, session or application (see Scope previously). This generally would not create a JSP page that is very maintainable. There are several versions that would be helpful in loading important values into a bean and minimizing the appearance of "code" in the document.
|
<jsp:setProperty name="id" property="*"/> |
This simple but powerful tag looks in the bean and calls all methods that match properties in the request object. The "name" is the name of the bean that has the "setters" to be searched. Therefore in the above example the bean "id" is searched for setter methods that match the "name/value" pairs found in the incoming request object. Any property that lacks a "setter" will be ignored. Keep in mind that a method like "getValue()" will be available as "value" (note the lower case change). To be useful for the HTML designer, there would need to be documentation as to what properties would then be available. Planning and documentation is very important.
| Note: There are several other variations on this tag that I have intentionally omitted, not because they are not of value, but that they require increasingly more knowledge by the presentation designer. I would recommend avoiding these two versions in the beginning, because if you do use them, you will have increased your documentation and raised the "training bar" for the presentation designers. This note, in general, applies to many of the other tags discussed. |
The other half of setProperty is the accessing the property later in the page utilizing "getProperty". There will also be cases where the property is never directly accessed, but instead is needed internal to the bean to service values for other "methods".
Documenting the request properties for the HTML designer and later maintenance is the critical set. Following would be a simple example of the type of documentation:
SetPropertyExample.jsp |
UseBean tag (place tag at beginning of page) |
|
<jsp:useBean id="example" scope="page" class="com.mps.jspbeans.propertyex" /> |
| Load Request Values (place tag after UseBean tag) |
|
<jsp:setProperty name="example" property="*"/> |
| Available Tags (use any of these tags as needed, there after) |
|
<jsp:getProperty name="example" property="userID"/> |
|
<jsp:getProperty name="example" property="pin"/> |
|
<jsp:getProperty name="example" property="state"/> |
|
<jsp:getProperty name="example" property="other"/> |
Both the HTML designer and later maintenance can use the above documentation. From the designer's perspective the tags can be simple "cut and paste" from the docs to the HTML where needed. From the maintenance perspective, the tags, their origin, and even their purpose could be added to the documentation. This documentation is provided by the JavaBean "builder" such that the documentation happens BEFORE rather then AFTER. (A novel concept on many projects). A sample page using these tags might look like:
<HTML>
<HEAD>
<jsp:useBean id="example" scope="page" class="com.mps.jspbeans.propertyex"/>
<jsp:setProperty name="example" property="*"/>
<TITLE></TITLE>
</HEAD>
<BODY>
<DIV ALIGN="CENTER">
<H1>User Info</H1>
<TABLE WIDTH="100%" BORDER="2" CELLPADDING="0" CELLSPACING="0">
<TR>
<TD>UserID:<jsp:getProperty name="example" property="userID"/></TD>
</TR>
<TR>
<TD>UserPin:<jsp:getProperty name="example" property="pin"/></TD>
</TR>
<TR>
<TD>State:<jsp:getProperty name="example" property="state"/></TD>
</TR>
</TABLE>
</DIV>
</BODY>
</HTML> |
Scriptlets are blocks of Java code embedded in the HTML document; a maintenance red flag! Despite this, they can be very useful if used carefully and are well documented. Though the bulk of the "code" is in the JavaBean, and very specific methods are surfaced as "tags" from the JavaBean for the designer to use in the HTML document, there are tasks that require a bit more "logic". These would be what I will call "scriptlet tags". Again, the documentation is the key to communicating the syntax from the bean developer to the presentation developer. The following is another simplified example of what that documentation might look like:
CustomerBean |
| UseBean (Place this tag at beginning of HTML page) |
|
<jsp:useBean id="customer" scope="session" class="com.mps.jspbeans.customer" /> |
| Load Request Values (place tag after UseBean tag, sets customer ID) |
|
<jsp:setProperty name="customer" property="*"/> |
| Useful Method Tags (paste these tags wherever these values are needed) |
|
<%=customer.getLastName()%> |
|
<%=customer.getCustID()%> |
|
<%customer.getAddress()%> |
The HTML designer does not have to understand that these method tags are "Java" embedded in their HTML. The method names should be "self documenting" such that the designer needs little additional documentation (more documentation is NEVER a bad thing, though it is often not read). The simple kind of chart provided above should be all that is needed for the HTML designer, and later the maintenance person, to understand and manipulate the page. A sample page using these tags might look like:
<HTML>
<HEAD>
<jsp:useBean id="customer" scope="session"
class="com.mps.jspbeans.customer" />
<TITLE></TITLE>
</HEAD>
<BODY>
<DIV ALIGN="CENTER">
<H1>Customer Info</H1>
<TABLE WIDTH="100%" BORDER="2" CELLPADDING="0" CELLSPACING="0">
<TR>
<TD>Customer ID:<%=customer.getCustID()%></TD>
</TR>
<TR>
<TD>Customer Name:<%=customer.getLastName()%></TD>
</TR>
<TR>
<TD>Address:<%customer.getAddress()%></TD>
</TR>
</TABLE>
</DIV>
</BODY>
</HTML> |
This paper is not going to cover custom tags, but it is very important to emphasize that this would be the next logical step in providing tags for the HTML designer to utilize.
JBuilder provides a number of handy wizards to help you get off on the right foot. Having all the pieces in the right place is the first big step toward a maintainable website. Since getting started correctly is so important, we will briefly walk through these first critical steps.
Our first step after creating a new project is to use the Web Application Wizard (Figure #1)
Figure #1
This will leave you with a project structure similar to the following: (Figure #2)
Figure #2)
And on your web server the following structure will appear under the servlet engines's root. (Figure #3)
(Figure #3)
Next, as an example, we will create our first JSP page within this project structure, using the JSP wizard (Figure #4)
(Figure #4)
Make sure to select the new web app context in the first page of the Wizard. (Figure #5) As an example, check the "generate sample bean" and "generate errorpage" check boxes.
(Figure #5)
The last page on the JSP Wizard has a special function. Here you can have JBuilder include additional "usebeans" for other JavaBeans you might have created. This can be easily be done later, but it is handy to do it here if you already know what other JavaBeans this JSP page will be needing. (Figure #6)
(Figure #6)
To finish up our small demo, click "Make Project" and the file "Jjava.war" will now appear in the directory pane. Double click this .war file and you can now browse the contents of the .war file in the structure pane. (Figure #7)
(Figure #7)
That concludes this brief step overview on how to begin developing your web application in JBuilder. Now to move on to discussing in a bit more detail the three core maintainability features introduced earlier that JavaBeans will provide for your web application.
There is no formal typing of Web JavaBeans, but for discussion it might prove to be of value to divide the purpose of web JavaBeans into three general "types". Often each of these types may be developed by a different person in a large project. Therefore, keeping their functions clearly separate is part of keeping the web application maintainable. Also, by keeping each of the tasks separate many of the beans can be shared between various other projects. This increases the use of the development investment, as well as leveraging the robustness and stability of well tested beans.
Earlier versions of the Servlet API allow access to handles on any servlet within that servlet container. This allowed the developer to communicate between servlets. This method was depreciated in the current 2.x API because this servlet handle access could be dangerous. The requested servlet could not exist any longer because the container might have destroyed it or this servlet could be in another container on a different machine. Despite this, there still is a need to communicate between servlets, and by extension JSPs, which are in fact also servlets "not compiled yet". The solution is basically simple - pass the information via an object (that is serializable) and therefore can be passed between containers and is maintained by the servlet container(s) (In vendor-specific ways unknown to the developer) For example, the steps for making a property file available to all servlets and JSP pages are:
| 1 2 3 4 5 6 |
ServletContext _appcontext = this.getServletContext();
SitePropertiesBean _siteprop = (SitePropertiesBean)_appcontext.getAttribute("SiteProps");
if (_siteprop == null) {
_siteprop = new SitePropertiesBean(_debug);
_appcontext.setAttribute("SiteProps",_siteprop);
}
_siteURL = _appcontext.getSiteURL(); |
Every servlet or JSP page can now request the "SiteProps" object that was pre-loaded by the first JSP or servlet and utilize application wide information in that object. Seems like a lot of work, but generally your website is designed in a hierarchical fashion, and therefore most of the subsequent servlets only have to use lines (1) and (2) before moving on to line (6), and the JSP only has to have the tag:
| <jsp:getProperty name="mybeanID" property="siteURL"/> |
This is fairly painless and easy to use.
Another example of communication is part of the "Service to Workers"design pattern. In this pattern, most every JSP page has an associated JavaBean. In this fashion the bean is preset with needed values, loaded into the correct context, and then the JSP page is called.
| 1 2 3 4 5 6 7 8 |
LoginBean _logbean = new LoginBean();
_logbean.setSessionID(_sessionID);
_type = request.getParameter("type"); // member or guest
_logbean.setType(_type);
_logbean.setBaseProp(_action,_source);
_session.setAttribute("LoginBean",_logbean);
RequestDispatcher dispatcher = _session.getRequestDispatcher("/Login.jsp");
dispatcher.forward(arg_req, arg_resp); |
First, the required bean is created (1) and then values that will be needed in the JSP page are acquired and loaded into the bean (2,3,4,5). The bean object is then loaded into the session context (6). A dispatcher object is acquired from the session object (an implicit object that is always available) (7), and the dispatcher is used to forward the request to the Login.jsp page (8).
In the Login JSP page, this information is then used to set values in that page
<%@ page errorPage="LoginErrorPage.jsp" %>
<HTML>
<HEAD>
<jsp:useBean id="LoginBeanId" scope="session" class="com.microps.clubmgr.LoginBean" />
<jsp:setProperty name="LoginBeanId" property="*" />
<TITLE>
Login
</TITLE>
</HEAD>
<BODY BACKGROUND="<%= request.getContextPath()%>/images/Steel_bkground.gif">
<DIV ALIGN="CENTER">
<TABLE WIDTH="100%" CELLPADDING="0" CELLSPACING="0">
<TR>
<TD>
<DIV ALIGN="CENTER">
<H1>Member Login</H1>
</DIV></TD>
</TR>
<TR>
<TD>
<DIV ALIGN="CENTER">
<FORM NAME="LoginForm" ACTION="http://microps-212:8080/servlet/com.microps.clubmgr.ServletCtrl">
<TABLE WIDTH="100%" CELLPADDING="5" CELLSPACING="5">
<TR>
<TD ALIGN="CENTER"> </TD>
</TR>
<TR>
<TD ALIGN="CENTER">
<FONT FACE="Arial"><B>UserID:</B></FONT>
<INPUT TYPE="TEXT" NAME="UserID" VALUE="" SIZE="30"></TD>
</TR>
<TR>
<TD ALIGN="CENTER"><FONT FACE="Arial"><B>Password:</B></FONT>
<INPUT TYPE="PASSWORD" NAME="Password" SIZE="30"></TD>
</TR>
<TR>
<TD ALIGN="CENTER">
<TABLE WIDTH="100%" CELLPADDING="5" CELLSPACING="5">
<TR>
<TD ALIGN="CENTER" WIDTH="50%">
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE=" Login "></TD>
<TD ALIGN="CENTER" WIDTH="50%">
<INPUT TYPE="RESET" NAME="Reset" VALUE=" Reset "></TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
<DIV>
<INPUT TYPE="HIDDEN" NAME="type" VALUE="<jsp:getProperty name="loginBeanId" property="type"/>">
<INPUT TYPE="HIDDEN" NAME="action" VALUE="<jsp:getProperty name="loginBeanId" property="action"/>">
<INPUT TYPE="HIDDEN" NAME="source" VALUE="<jsp:getProperty name="loginBeanId" property="source"/>">
</DIV>
</FORM>
</DIV>
</TD>
</TR>
</TABLE></DIV></BODY>
</HTML>
|
The JSP code first calls "usebean" to acquire a handle on the LoginBean. If the bean exists in the "scope" the JSP engine will acquire a handle that bean, else create a new bean. In our case this bean was placed in the session context, therefore it will be available to the Login.jsp. Lastly the getProperty tag is used to access the three values needed in this page. This is a very simplistic example, but illustrates the power of the technique in reducing the communication from a servlet or JSP to another JSP. (In a JSP you would have loaded the values using setProperty)
The key feature of the Service & Communication beans are their simplicity and single mindedness. Very little or no "processing" is done within these beans, they are simply repositories for servicing a JSP page or communication between servlets.
This next type of JavaBean is the focus of the logic that is specific to your web application. This is where values are acquired from a database, calculations made, and values validated from the user. It is very tempting to merge the functions of this bean with the "Service & Communication" beans. This is not generally wise. The Service & Communication beans are application or JSP specific. The Business logic beans, can also be application specific, but very often can be reused. Validating a customer, calculating a discount, and providing customers with custom product lists are functions that could be used in other parts of the web application.
One such "business" task is to validate a user that logs onto the website. This bean connects to your datasource bean (provided by a dataconnection bean to be discussed next). This bean contains methods to validate both the user, and return the necessary information that determines that user's access to different pages.
I would suggest extending my example to cache the most frequently accessed information inside the bean. This will minimize datasource access and improve performance. The bean is maintained in the application context so that all servlets and JSPs can take advantage of that caching.
The guts of the validation bean is of little importance to our discussion. What is important is how it is used.
| 1 2 3 4 5 6 7 8 |
if (_logbean.getMemberID() == "") {
ValidateUserBean _valuser = (ValidateUserBean)_appcontext.getAttribute("ValUser");
if (_valuser == null) {
_valuser = new ValidateUserBean(this);
_appcontext.setAttribute("ValUser",_valuser);
}
String _password = (String)request.getAttribute("Password");
if (!_valuser.IsMember(_loginName,_password)) {
_disp.dispatchRequest(_source,request,response);
}
} |
1. If the logbean does not return a member ID then
2. Load the validation bean instance from the application context.
3-5. Create a new instance of the validation bean if none exists.
6. Get the password from the request object.
7. If the user is NOT member, based on their user name and password.
8. Send them back to where they came from..
Otherwise continue on to this next block of code:
| 1 2 3 4 |
if (_siteprop.IsValidAction("Member",_action)) {
_mstrPage.setPage(_action);
_disp.dispatchRequest("/PageMaster.jsp",request,response);
} else {
_disp.dispatchRequest(_source,request,response);
} |
Where line (1) validates that this is a valid member page. If the member is valid, set the service bean for this page with the required action (2) , then dispatch to the "PageMaster" JSP (3). If not send the user back to the page they came from (4).
The master page is the original template JSP page. The PageMaster's service bean can configure itself via datasource which can be an xml configuration file, a property file, or a database. The maintenance is then reduced to setting the various components needed for the master page within this datasource.
Anything that does not fit in the above groups, goes here. The DataConnection bean and Property bean are a few examples. We have already utilized the Property bean that maintains the properties for the application, in the examples previously. The DataConnection bean is another example. These utility beans provide functions that are generally independent of the specific application structure. The DataConnection bean wraps all the tasks that are required to provide pooled connections to any other bean, servlet, or JSP.
Important Note: Forwarding vs RedirectingThese two mechanisms for passing a request to another resource are very similar in the end result but very different in how they each achieve that goal. A redirect (response.sendRedirect(URL)) causes the server to send an HTTP 302 message back to the client telling it that the resource has moved, and to access it using the supplied URL. A forward does not communicate with the client, but instead passes the request and the response objects directly to the new resource. The last key difference is a forward maintains the session link and object bindings with that client request, whereas a redirect does not. |
We have covered a lot of material in a very short time. At this point it is important to quickly review the core issues that need to be addressed in developing a dynamic and maintainable website using JSP.
Once the core development is completed, non-programmers can maintain and administer much of the site. Programmers and HTML designers can focus on the most certain new features and changes. The HTML designer can adjust the look and feel without going back to the Java programmers. The Java Programmers can move on to much needed "new" projects, or extend and expand on the existing project's next feature matrix target.
JDance - Good collection of JSP links and resources. http://www.jdance.com/jsp.shtm
JSP Introduction. The Java Developer ConnectionSM (JDC) presents a Short Course written by JavaTM Software licensee jGuru (formerly named the MageLang Institute). This short course provides an introduction to JavaServer PagesTM (JSPTM) technology.
http://developer.java.sun.com/developer/onlineTraining/JSPIntro/contents.html
Cocoon is a 100% pure Java publishing framework that relies on new W3C technologies (such as DOM, XML, and XSL) to provide web content.
Resin® serves the fastest servlets and JSP. With Java and JavaScript support, Resin gives web applications the flexibility to choose the right language for the task. Resin's leading XSL (XML stylesheet language) support encourages separation of content from formatting.
The Struts Framework. The goal of this project is to provide an open source framework useful in building web applications with Java Servlet and JavaServer Pages (JSP) technology. Struts encourages application architectures based on the Model-View-Controller (MVC) design paradigm, colloquially known as Model 2 in discussions on various servlet and JSP related mailing lists.
http://jakarta.apache.org/struts/
There are a lot of books available now on JSP and Servlets. What I have listed here is what I consider the "Top Four" in my library of over a dozen books on this topic. I added a brief comment as to why I consider it a member of this group.
Core Servlets and JavaServer Pages, Marty Hall, ISBN 0-13-089340-4
Very good "basic" reference book with useful examples. (Some books have such trivial examples)
JavaServer Pages, Larne Pekowsky, ISBN 0201704218
If you want to "read a book from beginning to end" on JSP, this would be the one. Simple, clear and well organized. A good place to start.
Professional JSP, Karl Avedal, et. al., ISBN 1-861003-62-5
Some great code examples, the best I have found. More of a reference, though some chapters are worth reading if that is a area you are working.
Java Developer's Guide to Servlets and JSP, Bill Brogden, ISBN
Code examples that are not found in most other books. Good XML examples using SAX and DOM parsers.