Introduction to Oracle Containers for J2EE Oracle Application Server Tips by Burleson Consulting

Enterprise JavaBeans are J2EE software components that exist and operate in a container. The container provides all the services an EJB needs to interact with other EJBs, the client application, and the server resources. It is through the container that the client application accesses the EJB. The container lists the EJBs it holds in a Java Naming and Directory Interface. When an EJB is accessed, the container is responsible for starting the EJB and managing the execution of the request. The request could require that a new copy of the bean be instantiated, select one from a pool of instantiated beans, or use an EJB already running. The container is responsible for supporting the operation of the EJB, and this includes maintaining transactions, security, and persistence. The container may handle the database connectivity of an entity bean, or the entity bean may connect to the database using a JDBC connection. OC4J is Oracle Application Server 10g?s container for J2EE.

Servlets, JSPs, and Apache Jserv

OC4J is Oracle?s container for EJBs, servlets, and JSP processing. OC4J implements a servlet container to execute servlets. The module mod_oc4j (on the Oracle HTTP server) is the default method for communicating with OC4J to handle servlets and JSPs. Mod_oc4j communicates with the servlet container using AJP (Apache Jserv Protocol) or by a direct HTTP request. Using a direct HTTP request allows OHS to communicate through a firewall to the servlet container. However, communications using AJP between mod_oc4j and the OC4J container are not secure, so it is recommended that both OHS and OC4J be located behind a firewall. Although Oracle Application Server 10g embeds the OC4J containers in the application server, you can implement a standalone OC4J container. OC4J containers and their administration are covered in more detail in the next chapter.

Executing Servlets in OC4J

The OC4J servlet container implements the Servlet 2.3 specification. It is also 100 percent code compatible with Apache?s Tomcat. All servlets are normally deployed into the servlet container as WAR files, but they can also be manually placed in a subdirectory where the servlet container will look for them when needed. When deployed as a WAR file, the servlet container is responsible for executing the servlets contained in the WAR file, which includes uncompressing the file and installing the servlet. The servlet container also provides for high availability through automatic restart if the JVM fails. A servlet running inside the OC4J servlet container has access to the full array of J2EE APIs, including database connectivity and EJBs running in the OC4J container. The servlet container also provides the servlet access to properties included in the HTTP request.

Figure 3: Servlet running in the OC4J servlet container

Again, coding a servlet is beyond the scope of this book, but you do need to understand how servlets are maintained in the Application Server. The OC4J servlet container looks in the $ORACLE_HOME/j2ee/home/default-web-apps/WEB-INF/classes directory for servlet class files. During development, using this directory will speed the testing process because the servlet container can detect changed code and automatically recompile the servlet before executing it. To activate this feature, edit the global-web-application.xml configuration file located in the $ORACLE_HOME/j2ee/home/config directory and set development="true" as shown here:

<orion-web-app
        jsp-cache-directory="./persistence"
        servlet-webdir="/servlet"
        development="true"
        jsp-timeout="0"
> 

Now when the servlet container executes the servlet, it will first check the source file (.java), and if it has changes, the servlet container will recompile the servlet with the new source code before executing it. The global-web-application.xml file sets default parameters for applications and will be discussed in detail in the next chapter. While it is effective to call the servlet?s class file directly during development, it is not recommended for a production environment for security reasons. In a production environment, servlets should be deployed in a WAR file, normally inside an EAR file.

When a web component is deployed, the WAR file contains a deployment descriptor called web.xml. This XML file is read when the servlet is started and can be used to pass initial parameters if needed. Many times the web.xml file declares a name for the servlet that is different from the servlet?s class file. In the next example, the servlet snoop is defined using the SnoopServlet class file.

<web-app>
  <servlet>
    <servlet-name>snoop</servlet-name>
    <servlet-class>SnoopServlet</servlet-class>
  </servlet>
</web-app>

If the servlet?s web.xml file declares the tag <load-on-startup>, the servlet container loads it when the container starts. Otherwise the servlet is loaded when a client requests it.

Deployment of web components (servlet/JSPs) is discussed later in this chapter as part of deploying an application.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.