OC4J Architecture

An OC4J container is essentially composed of a JVM and Java class files containing code. Server-side Java programs running as JSPs, Servlets, or EJBs execute within the JVM provided by an OC4J instance process. The OHS server determines which OC4J instance is appropriate for the incoming request and routes it to that container. Each instance itself can run one or more separate applications and can have one or more processes. The details of this activity are further explained in the "Structure" and "Processing" sections.

Structure

Within the 10g AS mid- tier instance, there are OC4J instances in addition to the OHS instance. The default OC4J instance is called home and in this case you can see that an additional OC4J instance Payroll has been created, as shown here:

 Component               Type          Up Status     In Sync Status ======================================================================== 1   home                    OC4J          Up            True 2   HTTP_Server             HTTP_Server   Up            True 3   Payroll                 OC4J          Up            True 

Each instance by default has one process that contains one JVM, however additional identical processes (and thus JVMs) can be spawned for an OC4J instance. Additionally, the OC4J process's JVM can have the amount of memory it uses configured by the administrator.

By having additional processes configured for an OC4J instance, you gain a degree of fault tolerance and a performance improvement via load balancing by OHS. If a process dies, requests are transparently passed to one of the surviving processes by OHS. Additionally, a new process will replace the failed process, if possible, through Oracle Process Management Notification (OPMN).

In a clustered environment, two or more mid-tier instances are identically configured so if one component fails, the other will pick up the processing. This redundancy can be extended to the OC4J process level with islands . Each OC4J instance in a cluster has the same application configuration; however, the number of processes in each can differ . The individual processes can have their application state replicated to other OC4J processes in the cluster if they're part of an island. By definition, an OC4J island is a group of OC4J processes in which the application state is replicated across all processes to provide transparent fault tolerance for stateful transactions. Basically this is clustering where application state is replicated, not just application code. Figure 17-2 shows a sample island configuration.

Figure 17-2: OC4J island configuration

In the previous example you'll see two clustered instances, each with a different number of processes. The processes are subdivided into two islands within the same OC4J Payroll instance type, but on different mid-tier clustered instances. Also note that although each instance is configured identically for the same application, you can have a different number of processes in each and not all are parts of an island. The reason not all processes have the application state replicated is because of the performance impact; replicating the state of every transaction to multiple servers would not scale in large, busy systems.

Processing

By design, not all OC4J containers are configured to process requests from every deployed application, yet the mid-tier instance will receive requests for every application it hosts . It's the OHS that receives a URL request and then determines if it's Java based, and if so which OC4J container is configured to process it. For example, it may get a request to run a simple Servlet such as Hello World, as shown here: http://mike.wessler. name :7777/j2ee/servlet/HelloWorldServlet .

In this example, the /j2ee indicates to OHS that this is a Java request. All Java requests are handled by mod_oc4j so the request is routed to the OHS module OC4J. These mappings are contained in the mod_oc4j.conf file located in $ORACLE_HOME/Apache/Apache/conf . The following code sample shows how any requests for j2ee, webapp, cabo , or IsWebCacheWorking will be handled by the default home instance:

 Oc4jMount /j2ee/* Oc4jMount /webapp home Oc4jMount /webapp/* home Oc4jMount /cabo home Oc4jMount /cabo/* home Oc4jMount /IsWebCacheWorking home Oc4jMount /IsWebCacheWorking/* home 

This mapping file identifies which OC4J containers get which requests based on the URL. As you can see in the preceding sample, nothing is currently configured to go to the Payroll OC4J container. However, for a Business Intelligence instance, you can see that Reports and Discoverer requests are configured to be routed to OC4J_BI_Forms container, as follows :

 Oc4jMount /reports OC4J_BI_Forms Oc4jMount /reports/* OC4J_BI_Forms Oc4jMount /discoverer OC4J_BI_Forms Oc4jMount /discoverer/* OC4J_BI_Forms 

Once the correct container for OC4J has been identified by mod_oc4j , the request needs to be passed from OHS to the container for processing. This pass off of the request is via the Apache JServ Protocol (AJP), which is an unencrypted communication protocol between the mod_oc4j module to the receiving OC4J container. Most times the container is local within the same mid-tier instance. However, the container can also be remote, for example, on a different physical server. The following is an example of how requests of Oracle Reports could be routed to the OC4J_BI_Forms container located on a different server, in order to improve performance:

 Oc4jMount /reports instance://904mt2.acme.com:OC4J_BI_Forms Oc4jMount /reports/* instance://904mt2.acme.com:OC4J_BI_Forms 

During execution, the Java program may make calls to a data source (database) via JDBC or remote Java components (programs) via RMI, or may place processing requests in a queue via JMS. In Figure 17-3, you can see an example of how the processing of OC4J can occur within a single mid-tier instance.

Figure 17-3: Processing with multiple OC4J instances

In the previous example you can see a simple call to the HelloWorldServlet executed by the home OC4J instance. The request is routed from the client to OHS via HTTP or HTTPS. Based on the URL to mod_oc4j.conf mappings, the request is routed to the home instance via AJP. If the request had been intended for the Payroll OC4J container, it would have gone to any one of four Payroll OC4J processes and could have connected to an Oracle database via JDBC for any data access or manipulation.