Enterprise Java and Rational Rose - Part II - Part 2 (Page 2 of 4 ) What Is a Servlet?
As we saw in Part I, an enterprise application may (but does not necessarily) consist of several tiers. Tiers are primarily abstractions to help us understand the architecture. The J2EE architecture usually involves four distinct tiers, as shown in Figure 1.
Figure 1: Multi-Tier Architecture
Servlets reside on the Web tier and typically act as the intermediary between the client tier (end users) and the other tiers (e.g., the business or the EIS tier).
A servlet is really a Java class that is invoked in response to a user's command. The invocation of the servlet follows a procedural request/response process. The Servlet 2.2 specification introduces the notion of a Web Application: the component that is deployed within a servlet container. A Web Application is packaged as a file with the extension ".war" in a format similar to that of the Java Archive (.jar) file.
You've probably used or seen Web sites that use CGI scripts to create an HTML page on the fly. That is exactly the kind of functionality servlets provide, but they are much lighter weight. Unlike CGI scripts, servlets don't require a new process for each HTTP request. All they need is a thread. Plus, they are much easier to maintain.
When a servlet container starts up, it typically creates a pool of servlets. Once the servlets are initialized, they are ready to process requests. For an idea of how servlets work, let's say you visit a Web site that has a servlet for processing registration requests. When you fill out a registration form, and press "Submit," the servlet receives the request and extracts the information you provided in the form via a "request object." (The request object is created by the container and provides an object-based access to the form data.)
Then the servlet does whatever it needs to do (save the information in a database, for example, or ask other objects such as EJBs to do so) and then composes an HTML page via the "response object." The page is then sent back to you, perhaps displaying a "registration successful" message and confirmation number.
By definition, a servlet is stateless. If you want a "stateful" servlet, then you can use either the HttpSession object or the Servlet Context object. The HttpSession object is dedicated to a client session; the Servlet Context object lasts for the life of the application.
If you are familiar with the pre-J2EE servlet specification, you might be wondering where the servlet engine fits into the Servlet 2.2 architecture. As it turns out, the servlet engine is now called the servlet container, which we mentioned earlier. The new specification also introduces a few new concepts, such as an application that can be distributed within several containers.
Although servlets are wonderfully fast, lightweight, and powerful, servlet-based development suffers from one very fundamental flaw. The specification states that
. . . the servlet must contain the presentation aspects as well.
This requirement can be difficult to implement and even more difficult to maintain, since the servlet developer and the presentation creators are, more often than not, different people. The presentation is embedded inside Java statements, which makes it difficult to comprehend. Moreover, the presentation is likely to change more frequently than the logic behind it.
So what's a developer to do? Use JavaServer Pages, or JSPs.
JSPs: Stepping into the Breach
Built on top of the Servlet architecture, the JSP technology allows for a clear separation between presentation logic and business logic. It provides all the power of servlet technology while allowing the servlet developer and the content developer to work independently.
JSPs are great for creating dynamic content. They excel at rendering dynamic HTML/XML documents and provide an easy way to associate template data (XML or HTML) with directives and actions that supply dynamic behaviors on Web pages. These behaviors can be tied to specific requests or entirely independent of any request.
Basically, the JSP technology is a mix of HTML code and Java bits of logic (called scriptlets). A JSP gets compiled dynamically into a servlet at runtime, essentially yielding servlet capabilities without the drawbacks.
The code below shows a sample JSP.
<%--Comment
HTML code to start HTML page and body --%>
<HTML>
<HEAD>
<TITLE>Bonus Calculation</TITLE>
</HEAD>
<%--Comment
Scriptlet for import statements
<%@ indicates a jsp directive --%>
<%@ page import="javax.naming.*" %>
<%@ page import="javax.rmi.PortableRemoteObject" %>
<%@ page import="Beans.*" %>
:
<%! String strMult, socsec; %>
<%! Integer integerMult; %>
<%! int multiplier; %>
<%! double bonus; %>
<%
strMult = request.getParameter("MULTIPLIER");
socsec = request.getParameter("SOCSEC");
.
.
.
%>
The J2EE and the Model-View-Controller Paradigm The J2EE programming model applies the Model-View-Controller design pattern to J2EE development. This allows enterprise application developers to separate tiers efficiently and associate many views with one model. In fact, for any client-server architecture, it's important to isolate the real logic of your application from your end-users so that you can easily change the look and feel of your application without impacting the logic.
Figure 2 shows one representation of this design pattern.
Figure 2: Model-View-Controller Design Pattern Applied at the Enterprise Level
Many design patterns (best practices) recur in J2EE applications: shopping patterns, security patterns, transaction patterns, patterns that involve dependent objects such as value or data access objects, patterns that require a session-to-entity exchange, and so on. If you're designing your own e-commerce application with a Web-centric architecture, remember that an EJB-centric solution will be easier to adopt later if your design clearly separates presentation and business logic, as shown in Figure 3.
Figure 3: Class Diagram of a Typical Shopping Pattern
Figure 4 shows how to map your Web-centric application to an EJB-centric application.
Figure 3: Migration from a Web-Centric Application to an EJB-Centric Application
Developing J2EE Applications with Rational Rose
Rational Rose introduced support for J2EE via the Rose Tech Preview release in July 2000. Rational Rose supports the following capabilities related to J2EE:
Servlet development, including generation of a J2EE compliant deployment descriptor.
Entity Bean development, including generation of a J2EE compliant deployment descriptor.
Session Bean development, including generation of a J2EE compliant deployment descriptor.
Ability to invoke a Java compiler to compile files.
Creation of Web and EJB archive files from within Rose.
Synchronization of home and remote interfaces with the EJB class.
We introduce you to these capabilities in the following examples but do not cover the dialogs in great depth.
Creating and Modifying Servlets
Rational Rose provides a quick and easy way to create and modify servlets. To create a new servlet, right click on a class diagram. Then, from the shortcut menu, select J2EE>New Servlet. This brings up the dialog shown in Figure 5, which allows you to quickly configure the servlet you want to create. Note that the dialog is multi-level (Servlet Class Properties, Advanced Properties, Deployment Descriptor). You can move back and forth among the different levels by clicking the desired item listed on the left.
Figure 5: Servlet Configuration -- Class Properties Dialog
In the Class Properties dialog, you can specify the name of the servlet, whether it is based on the generic servlet or the http servlet class, and so on. You can also choose the exact operations you want to generate for the servlet: e.g., doGet, doPost, destroy, init, etc. Let's specify the name as "myServlet," a subclass of the http servlet class, and select the following operations from the list: init, service, doGet, destroy.
If we click on "Advanced Properties" on the left, we bring up the Advanced Properties dialog shown in Figure 6. This lets us specify whether we want to use a context object, and the exact operation of the servlet in which we want specific activities to take place. For example, if we check getSession and choose doGet from the list, a call to getSession will be placed in the doGet operation at code generation time. Similarly, if we set a BufferSize limit of "7," then a setBufferSize() call will be placed in the doGet operation at code generation time.
The resulting doGet operation is shown below:
/*
Method: doGet
*/
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
/**
Servlet Code Generation Process
-- Content Type --
**/
response.setContentType("text/html");
/**
Servlet Code Generation Process
-- Response Buffering --
**/
response.setBufferSize(7);
/**
Servlet Code Generation Process
-- ServletRequest.getSession --
**/
HttpSession session = request.getSession(true);
}
Figure 6: Servlet Configuration - Advanced Properties Dialog
Next, let's click on Deployment Descriptor on the left, which brings up the dialog shown in Figure 8. Servlets use XML-based deployment descriptors as a way to communicate various configuration details to a container or Web server. At code generation time, Rose J will generate the XML deployment descriptor based on the information we specify. This may include a more descriptive name for the servlet, initialization parameters required for the servlet, a session timeout value, and so on. We can specify the Init and Context parameters by using the radio buttons. We can toggle between Name and Value, and enter the name and value in the text field on the right.
Figure 7: Servlet Configuration - Deployment Descriptor Dialog
We can also modify an existing servlet (created via the process described above) by selecting the servlet class on a class diagram, right clicking, and then choosing J2EE>Servlet-configuration from the shortcut menu. This brings up the same dialogs, pre-populated with the appropriate information. Next: Part 2 Continues >>
More Development Cycles Articles
More By The Rational Edge |
