|IBM home | Products & services | Support & downloads | My account|
|J2EE pathfinder: J2EE technologies for the stateless network|
The Java industry has grown exponentially over the last few years. As an enterprise application developer, architect, or technical manager, you can choose from dozens of vendors, best practices, specifications, and component types for your Java technology implementation. The goal of the J2EE pathfinder series is to help you forge a path through these options, by aiding you in the process of selecting the appropriate technology for any given situation.
In this first installment, we'll explore stateless J2EE components and evaluate the most appropriate one to use for your enterprise architecture. When it comes to stateless, request-processing components, you have two primary J2EE technologies to choose from: servlets or Enterprise JavaBeans technology -- or more specifically, stateless session beans.
Broadly speaking, both servlets and EJB components are designed to function as the transaction-management component for an enterprise architecture. Each technology is powerful in its own right. The strength of the servlet architecture is in its overall efficiency and relative simplicity. EJB components, on the other hand, are more robust, and consequently more complicated to develop, maintain, and debug.
We'll begin by briefly discussing the qualities of the stateless (as opposed to stateful) network, then talk in detail about the pros and cons of each of our two stateless technologies. We'll close the article with a broad look at the most common application setups you will encounter in J2EE enterprise programming, and the best technology solutions for each setup given our two options.
Please note that JSP (Java ServerPages) technology is, for the purposes of this article, considered to be a specialized type of servlet. Considering that every JSP page is converted into a servlet prior to execution, this is not a stretch. Because servlets are inherently stateless, we will limit our focus to stateless session beans and the features they provide for handling stateless client requests. The next article in this series will compare stateful session beans with servlets and the HTTP Session API.
The stateless network
HTTP is a good example of a stateless protocol based on client-server requests and responses. Under HTTP no memory of the client-server interaction is maintained from one request to another.
Of course, without the ability to maintain state, the Internet would be reduced to a glorified encyclopedia, electronic yellow pages, and cool animated games on Shockwave.com. Thus, there are several tricks for simulating a stateful session over HTTP. Stateful information can be stored in HTML form fields, appended to a hyperlink, or stored in a cookie on the user's machine. It is then the responsibility of the application developer to manage, track, and maintain the client's state to ensure a smooth, secure, and engaging experience.
The case for servlets
Although servlets typically handle HTTP requests, the servlet
architecture is protocol independent. The servlet interface defines the
basic methods needed for communicating with a servlet, regardless of the
network protocol. We will deal exclusively with HTTP servlets, both for
simplicity's sake and because they are the most common type. In fact, if
you extend your custom servlet classes from
From an architectural standpoint, servlets can function both as controllers and views. Typically, JSP pages are used as view components, and JSP pages or pure servlets are used as controller components. Servlets do an effective job of handling user interactions such as content formatting and display, basic request processing, security requests, and more. Typically, a servlet will use helper classes (often JavaBeans-style classes) to handle the heavy processing or use them to interface with back-end components. This allows the servlet layer to focus on client interaction rather than business processing.
Servlets are very lightweight, in that limited resources are required
to initialize and maintain a servlet instance. Servlet scalability is
particularly smooth and efficient. Under the servlet architecture, a given
servlet instance handles simultaneous requests by spawning a new thread
for every request and executing the
Whether you need to administer a servlet container, set up server load
balancing, process a simple HTML form, or even perform complex processing
on a stream of HTTP data, the servlet architecture and API make Web
application development and deployment quite easy. The setup and
administration of a Web server with a servlet container is fairly
straightforward, requiring little configuration. Often one or two XML
files will contain all the necessary configuration settings for server
deployment. It is also very simple to program a servlet. The servlet API
abstracts much of the detail involved in intercepting a client request,
routing it to the appropriate servlet instance, retrieving a thread from
the thread pool, calling the correct method to handle the request
The case for session
Communication with an enterprise bean takes place initially through the bean's home interface, and eventually through the bean's remote or local interface. Since external clients cannot use the local interface, we'll concentrate only on the remote interface. Communication through the remote interface takes place using Java Remote Method Invocation (RMI). This is a Java platform-specific network protocol that allows one Java object to interact with a remote Java object as though it were local. Thus, only Java components (applets, servlets, AWT, Swing, non-GUI Java apps, and so on) can serve as direct EJB clients. Any other client types (such as cell phone, browser, or non-Java app) must communicate through a Java application.
The EJB architecture
Although the session bean is the most lightweight EJB type by far, the EJB container and EJB architecture come at a cost. An EJB container requires a substantial amount of server power and memory. Unlike the lightweight threading mechanism employed by Java servlets, EJB components require the creation and management of multiple object instances and associated resources (see Figure 2). In exchange for this higher overhead, however, EJB components provide effective management of enterprise resources, transactions, and security checks, without sacrificing much in the way of response times and overall scalability. Because stateless session beans do not have to maintain any client state, they can be efficiently pooled and used to fulfill any client's request.
Whether you need to administer an EJB container, set up server clustering, declare configuration settings for an enterprise bean, or tap into one of the container's many services (including security, transaction management, resource management, and so on), the EJB architecture and API make the development and deployment of robust, full-featured J2EE applications surprisingly simple. Deployment descriptors define the container and bean configurations, and the EJB API uses interfaces, bean life cycle callback methods, and the Factory pattern to provide a clean separation between the container and the enterprise beans, while still allowing bean developers to easily access container services.
Choosing the right
As you examine these scenarios, keep in mind what you've learned about each technology. In particular, remember that the servlet architecture's lightweight threading model makes servlet scalability particularly efficient, whereas stateless session beans provide an excellent balance between access to robust enterprise resources, good response time, and overall scalability, which is sometimes better suited to more heavyweight applications.
Enterprise application integration
In the case of EAI there is little contest between servlets and EJB components, since servlets have limited usage in an integration context. In the rare scenario where an application needs to invoke a J2EE method and no other mechanism is available aside from HTTP, a servlet is useful for EAI. Otherwise, it simply poses additional overhead and unnecessary architectural complexity.
Unlike servlets, stateless session beans are well designed for EAI. They are very lightweight (in contrast to stateful session beans), and can be easily pooled to ensure excellent scalability. State management is often needed within EAI, but this can be handled by a proprietary mechanism or by J2EE transactions. Thus, the burden of state management is removed from the application server.
Another possibility is to invoke an EJB component as though it were a CORBA (Common Object Request Broker) component. This is an especially useful option in the case of EAI, where one or more of the applications to be integrated are CORBA components.
Rich GUI client
Applets are loaded as a part of an HTML page, and provide the rich, dynamic user interface that people have come to expect from the Web. (HTML is excellent for displaying text but it makes a lousy user interface.) Applets are powerful in that they are browser-neutral, provide a rich GUI interface, and are prevented by the applet sandbox from accessing local resources without permission. Applets also provide a compelling solution to the problem of updating a client interface: simply install the latest applet class and supporting libraries on the server and the client will download the new files every time the applet is accessed. The price of this flexibility is that the applet class and supporting libraries must be downloaded to the client each time the applet is accessed.
Stand-alone applications are installed directly on an end user's machine. They are not dependent upon a browser and are stored locally rather than being downloaded from a remote site. As a result, they can provide very quick startup and response times. They do not have the security limitations of applets, and thus can more easily access the local client machine and any accessible remote server. On the downside, stand-alone applications are notoriously difficult to maintain and update. Each machine holds a local copy, so it is not possible to automatically update all the applications across a network.
Java Web Start -- essentially a hybrid between applets and stand-alone applications -- is a newer technology that is coming into greater prominence (see Resources for more information). Like an applet, Java Web Start can be invoked from a Web browser and can interact with a servlet. Unlike applets, Java Web Start applications, cache files on the local hard drive and only download additional files when necessary. Java Web Start applications can be installed from a local resource or remotely across the Web. Additionally, the GUI that is launched is a full-fledged Swing client. The browser can be closed without disrupting the application. The result is the best of the applet world combined with the best of the non-applet world. Java Web Start isn't perfect, however. It requires that every resource be contained in a local JAR file (no loose files); it does not allow resources to be accessed directly (they're accessed through an abstract resource-management mechanism); and it does not support the deployment of native applications.
The following solutions are applicable to any of these three rich GUI component types:
Finally, if you have a non-Java GUI (that is, native GUI) client that needs to manage a complicated transaction or series of transactions, you'll want to consider the option of invoking an EJB component as though it were a CORBA component.
Multiple client types
Next month, we'll weigh the pros and cons of managing state in the Web
tier (using servlets plus