Using Servlets with Other J2EE APIs

---

Servlets provide the web tier of the J2EE scenario, but servlets often need to use additional aspects and services of the J2EE platform to process client requests. We will now outline the J2EE services that servlet-based web applications may use. Some of these may only be available on servers that implement the full J2EE platform specifications; for example, web servers such as Tomcat, which provide a web container but no EJB container, implement only a subset of the J2EE specifications. Sun provides a complete J2EE Reference Implementation.

Connecting Servlets to Information Sources

At the heart of almost every servlet-based web application is the processing of data (at least one, if not two way). To do this the servlet needs access to information from EIS systems and databases. There are three main J2EE APIs that are associated with data access that may be used by servlets.

The J2EE Connector Architecture

The Connector Architecture gives developers a standard architecture for connecting J2EE and web applications to heterogeneous Enterprise Information Systems (EIS) (databases, legacy systems, enterprise resource planning systems, and so on). To you and I, these are pre-existing information systems that are available to the programmer through the Connector API.

This allows us to interact with a range of enterprise information systems and send data to and/or receive data from these systems. To use the Connector API to access such a system we need a resource adapter to support the EIS: this acts like a JDBC driver in database access.

The definition of and the inclusion of the Connector Architecture and API in J2EE is an important development, especially for companies with large pre-existing and possibly diverse systems that need to be accessed and interconnected. With this architecture we can begin to draw the resources of these diverse systems into our application in order to utilize existing services. This will become more significant as more companies get more involved in business-to-business electronic commerce.

Using this architecture, our web-based applications can access EIS's not normally available. Generally the preferred method to access such resources is to encapsulate the logic in an EJB, but where EJBs are not employed, our web applications can access them directly with the appropriate resource adapter.

Database Connectivity

JDBC provides a standard API to access a wide range of relational databases. It provides an application interface to access the database or build higher-level components on, and a service provider interface to attach the JDBC driver to the J2EE platform. We can use JDBC to connect to a database from servlets. JDBC is important in servlet development when we bypass the EJB/business tier and directly access the database tier.

Considering that many (if not most) enterprise applications are, in practice, servlet-based and do not use EJBs, access to the JDBC API is critical for most servlet-based web applications.

The Java Transaction Service

The Java Transaction Service (JTS) and API are potentially very valuable to many applications. Many J2EE and servlet-based applications rely heavily (at some level) on transactions and transaction processing, and the JTS provides an API for processing complex distributed (and non-distributed) transactions. The API allows a high level of control of the transactions, with control of committal and rollback.

This kind of transaction service allows transactions spanning multiple databases to be treated as a single transaction. If any part of the transaction fails, all parts of the transaction can be rolled back, or alternatively if no parts of the transaction fail, the service guarantees that the whole transaction (incorporating one or more transactions) will be successfully committed as if it were a single transaction.

JTS is most frequently used on the business EJB layer for processing transactions, but is available on J2EE servers for servlets as well. This will allow our applications to manage more complex transaction scenarios.

Messaging in J2EE

Servlets need to communicate beyond the client request-response cycle. They may only need to listen for special events that trigger messages sent over a message service, or they may need to send information to a user or administrator. In these cases servlets often make use of the JMS or JavaMail APIs to communicate outside the normal cycle.

The Java Message Service

The Java Message Service (JMS) provides a standard API for applications that need to incorporate messaging into their J2EE applications. It allows components to engage in reliable asynchronous communication (in other words, communication where the message does not have to be processed and acknowledged immediately after it has been received) by creating, sending, receiving, and reading messages.

We use JMS in web applications where our servlet may need to listen to JMS messages for updated information (stock prices and alerts etc), or it may need to broadcast messages.

JavaMail

Where applications need to send messages/notifications of important errors or events, we can use the JavaMail API included in the J2EE platform. It is also used as an alternative to the asynchronous messaging of JMS, but can be slower and less dependable. The JavaMail API allows our applications to send or receive messages over some of the most widely-available Internet mail protocols such as SMTP, POP3, and IMAP, and also supports MIME. JavaMail relies on the JavaBeans Activation Framework (JAF) that is therefore included in the J2EE specifications.

The JavaMail API is useful in servlet-based web applications on many fronts. At the most basic level it can be used to send messages notifying relevant personnel of important events. This could include application level events such as significant errors or warnings, or just alerts such as important news announcements, or messages direct from the client via a servlet.

Servlet Security and JAAS

Servlet applications often implement their own custom security architecture, but the Java Authentication and Authorization Service (JAAS) is often overlooked and not designed into the web application architecture.

The JAAS provides the ability to restrict the right to execute code based upon the privileges of the user attempting to call that code. This can be important for a client application where only certain types of users may use particular resources on the J2EE server (for instance we might want to restrict access to an administration servlet to administrators only).

There are two parts to the JAAS. The first is the reliable authentication of the client, regardless of the way that the client is connecting to the server. It specifies a pluggable authentication module for the J2EE platform so that modifications or upgrades to the authentication component can take place independently of any modifications to the J2EE application.

The second part is authorization, which allows programmers to specify the roles of the users that may have access to our application resources. Web components and EJB methods can be protected, requiring authorization of the caller. We can also restrict the use of specified classes and methods to certain types of users according to their roles.

The Java Naming and Directory Interface

The Java Naming and Directory Interface (JNDI) provides two distinct services on the J2EE platform. Firstly, a servlet can use JNDI to look up components such as EJBs, JDBC connections, and other servlets to get a reference to the selected resource. Secondly it makes available a standardized interface for accessing multiple naming and directory services such as the Lightweight Directory Access Protocol (LDAP).

The Java API for XML Processing

The Java API for XML Processing (JAXP) provides standardized support, through the API, for processing XML documents using different SAX parsers, DOM builders, and XSLT transformation engines. By configuring JAXP we can specify the particular implementations of SAX and DOM to use relevant to the requirements of the situation.

Servlets providing web services will definitely find use for this API, because XML documents are increasingly becoming both the source matter and the output of requests. XML has become ubiquitous and should be an integral part of the servlet programmers' technical arsenal.

---