Java Web Programming Glossary

This is a continuously growing list of terms for Java Web Programming.

Last added:

- Invoker Servlet

- EJB Container

- EJBContext

The server already knows about the servlet classes, but the compiler (i.e., javac) you use for development probably doesn't - servlets and JSP are not part of the Java 2 platform, standard edition. So you must not only add your development directory, but also the servlet and jsp jars of the Servlet Container to CLASSPATH. For example for Tomcat it would be:

• install_dir/common/lib/servlet-api.jar
• install_dir/common/lib/jsp-api.jar

In the server-side J2EE context, a component is a unit of functionality that is assembled, along with any required resources, into a J2EE application. There are three kinds of defined components:

• Client components, which correlate to the client containers.

• Web components — servlets and JSPs.

• EJB components.

The application server maintains control and provides services through an interface or framework known as a container. There are five defined container types in the J2EE specification. Three of these are server-side containers:

• The server itself, which provides the J2EE runtime environment and the other two containers.

• An EJB container to manage EJB components.

• A Web container to manage servlets and JavaServer Pages.

The other two container types are client-side:

• An application container for standalone GUIs, console, and batch-type programs — the familiar Java applications started with the java command.
• An applet container, meaning a browser, usually with the Java Plug-in.

A context is a set of name-to-object bindings. Every context has an associated naming convention. A context provides a lookup (resolution) operation that returns the object and may provide operations such as those for binding names, unbinding names, and listing bound names. A name in one context object can be bound to another context object (called a subcontext) that has the same naming convention.

Examples:

- A file directory, such as /usr, in the UNIX file system is a context. A file directory named relative to another file directory is a subcontext (subdirectory).

- A DNS domain, such as COM, is a context. A DNS domain named relative to another DNS domain is a subcontext. For example, in the DNS domain Sun.COM, the DNS domain Sun is a subcontext of COM.

- An LDAP entry, such as c=us, is a context. An LDAP entry named relative to another LDAP entry is a subcontext. For example, in the an LDAP entry o=sun,c=us, the entry o=sun is a subcontext of c=us.

Deployment descriptors are XML documents named web.xml, located in the /<SERVER_ROOT>/applicationname/WEB-INF/ directory, that describe configuration and other deployment settings. The statements in the deployment descriptor are declarative instructions to the J2EE container; for example, transactional settings.

The information it contains includes the following elements:

• ServletContext Init Parameters
• Localized Content
• Session Configuration
• Servlet / JSP Definitions
• Servlet / JSP Mappings
• Mime Type Mappings
• Welcome File list
• Error Pages
• Security

When you are packaging a J2EE enterprise application, you can package EJB JAR files and Web application WAR files as part of a J2EE enterprise archive (EAR) file.

EJBs are server-side, modular, and reusable components similar to the normal Java but which are subject to special restrictions and must provide specific interfaces for container and client use and access. They can only run properly in an EJB container, which manages and invokes specific life cycle behavior.

There are 3 types of EJBs:

• Session beans (either stateful or stateless)
• Entity beans
• Message-driven beans

EJBs are never accessed directly by clients but only through JNDI.

The EJB 2.0 specification has significant differences from the previous versions. In particular, container-managed persistence is newly implemented in the 2.0 version, and message-driven beans are a brand new bean type.

The EJB container hosts and manages an enterprise bean in the same manner that the Java Web Server hosts a servlet or an HTML browser hosts a Java applet. An enterprise bean cannot function outside of an EJB container. The EJB container manages every aspect of an enterprise bean at runtimes including remote access to the bean, security, persistence, transactions, concurrency, and access to and pooling of resources.

Every bean obtains an EJBContext object, which is a reference directly to the container. The EJBContext interface provides methods for interacting with the container so that that bean can request information about its environment like the identity of its client, the status of a transaction, or to obtain remote references to itself.

The deployment descriptor for an Enterprise JavaBean must be named ejb-jar.xml, and it resides in the META-INF directory inside the EJB JAR file.

The EJB 1.1 specification introduced the ENC as a means of enhancing portability and avoiding name clashes in the JNDI namespace.

In practice, this means that you should preface the lookup string with java:comp/env/. The container is required to recognize a lookup coded in this manner as an alias or nickname rather than the direct JNDI name. A deployment descriptor entry (ejb-ref) links the alias to the actual JNDI entry.

Use of the ENC also means that the developer doesn't have to worry about hardcoded JNDI names.

The JNDI ENC allows a bean to access resources like JDBC connections, other enterprise beans, and properties specific to that bean.

In essence, the home interface provides bean management and life cycle methods. It allows the client to create, remove, and find objects of the same type. The client uses a JNDI lookup to locate a bean's home interface.

Within the home interface, the specification normally requires that you implement at least one create() method.

Servlet extends javax.servlet.http.HttpServlet, the standard base class for HTTP Servlets.

Example:

import javax.servlet.http.*;

public class HelloWorld extends HttpServlet

used to specify the HTTP response line and headers (e.g. specifying the content type, setting cookies).

2: import javax.servlet.*;

3: import javax.servlet.http.*;

4:

5: public class HelloWorld extends HttpServlet

6: {

7: protected void doGet(HttpServletRequest req,

8: HttpServletResponse res)

9: throws ServletException, IOException

10: {

11: res.setContentType("text/html");

12: PrintWriter out = res.getWriter();

13: out.println("<HTML><HEAD><TITLE>Hello Client!</TITLE>"+

14: "</HEAD><BODY>Hello Client!</BODY></HTML>");

15: out.close();

16: }

17:

18: public String getServletInfo()

19: {

20: return "HelloClientServlet 1.0 by Stefan Zeiger";

21: }

22: }

used to read incoming HTTP headers (e.g. cookies) and HTML form data (e.g. data the user entered and submitted)

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class HelloClientServlet extends HttpServlet

{

protected void doGet(HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException

{

...

}

}

This is a high-level interface built on top of cookies or URL-rewriting for Session Tracking. Many servers automatically revert to URL-rewriting when cookies are unsupported or explicitly disabled.

The invoker servlet lets you run servlets without first making changes to your Web application's deployment descriptor (i.e., the WEB-INF/web.xml file). Instead, you just drop your servlet into WEB-INF/classes.

Before performing any operation on a naming or directory service, you need to acquire an initial context--the starting point into the namespace because all methods on naming and directory services are performed relative to a context.

Client interface files and EJB components reside in JAR files.

you must set the JAVA_HOME environment variable to tell your Web Appliaction Server where to find Java. Failing to properly set this variable prevents the compilation of JSP pages. This variable should list the base JDK installation directory, not the bin subdirectory.

The Home Interface extend the javax.ejb.EJBHome Interface which is a subclass of the java.rmi.Remote interface.

The Remote Interface extend the javax.ejb.EJBObject Interface which is a subclass of the java.rmi.Remote interface.

For every remote interface there is an implementation class; a business object that actually implements the business methods defined in the remote interface. This is the bean class; the key element of the bean.

According to the J2EE specification, "Applications must be able to access resources and external information in their operational environment without knowledge of how the external information is named and organized in that environment." J2EE makes use of the JNDI to accomplish this goal.

The container makes the EJBs available to their clients via JNDI (except for Message-driven beans, which have no direct client). That's why session and entity beans must provide a Home Interface to allow the Container and Clients to obtain a reference to a specific bean.

JSP technology allows the page designer to create servlets without being distracted with Java code. Tags allow Java programmers to extend JSP files by making Java code look like HTML.

Local home interfaces extend the javax.ejb.EJBLocalHome interface.

Message-driven beans listen asynchronously for Java Message Service (JMS) messages from any client or component and are used for loosely coupled, typically batch-type, processing.

A Web Application can be packaged into a single War File for more convenient deployment by using Jar Tool.

EJBs are never accessed directly by clients. Instead, the container generates proxy objects that implement the home and component interfaces and are used by the client for communication with a bean. The proxy objects then call upon the bean to perform the requested task.

This mechanism allows the container to coordinate and manage beans however and wherever it sees fit; the client remains blissfully unaware of the internal details.

The remote home interface that you write extend the javax.ejb.EJBHome interface.

The Root Directory of a Web Application is where all JSP and XHTML files are stored. It is located under the SERVER_ROOT directory.

It is the directory of the installed Java Web Server for example /jakarta-tomcat-4.0/webapps

One of the main characteristics of a web application is its relationship to the ServletContext. Each web application has one and only one ServletContext.

While any or all of the containers and components may be on the same or multiple machines — remember, J2EE is a distributed model — conceptually, the architecture is almost always three tier. These tiers are client, business logic, and database or Enterprise Information Systems (EIS).

According to the Java Servlet Specification 2.2, a "Web Application is a collection of servlets, html pages, classes, and other resources that can be bundled and run on multiple containers from multiple vendors."

The following items can exist in a web application:

• Servlets
• JavaServer Pages
• Utility Classes
• Static Documents including, XHTML, images, etc.
• Client side classes
• Meta information that describes the web application

One of the main characteristics of a web application is its relationship to the ServletContext. Each web application has one and only one ServletContext.

You typically distribute a Web application (Web components) as a single compressed WAR file. The WAR file the complete directory structure and all files that define the application.

This directory, under a Web Application Root Directory, contains all resources related to the application that are not in the document root of the application. This is where the deployment descriptor is located.

The WEB-INF directory is not part of the public document. No files contained in this directory can be served directly to a client.

Classes will be stored in both the /WEB-INF/classes and /WEB-INF/lib directories. Of these two, the class loader will load classes from the /classes directory first followed by the JARs in the /lib directory.