DBA Tips Archive for Oracle


[an error occurred while processing this directive]

No Title

[an error occurred while processing this directive]

by Michael New, MichaelNew@earthlink.net, Gradation LLC



This article includes a brief overview of how and where Oracle provides support for Java and J2EE.

To understand the Java implementations that Oracle provides, you really need a history of it. Basically, Java technology is moving right along, and Oracle is keeping up with it. Sun has set the J2EE standards to follow, and OC4J is Oracle's implementation that is J2EE compliant and that exists today. From a marketing standpoint, Oracle is dedicated to enhancing its Java solutions by providing 100% compliance with J2EE.

Currently OC4J is the big push, and the Java direction of Oracle, plus is 100% J2EE compliant. Though there are cases when the java option in the database will still be used. Short of openly admitting various problems (difficult to install, lack of stability, performance, and scalability) with its own J2EE products offerings (OJSP, OSE, and EJE), Oracle quietly switched focus to OC4J, which is Orion Server with an Oracle label. Oracle also recommended customers not to use any of the J2EE containers it offered up to now for J2EE deployment.

In addition to OC4J, Oracle has implemented other solutions in the past that include the following:

The biggest difference between implementing OC4J within Oracle Application Server or implementing technologies (listed above) is that OC4J is the most current when it comes to implementing the most current J2EE specifications. Even though EJBs and Servlets (using Oracle Servlet Engine) can be developed today, Oracle is pushing for deployment to OC4J.

Oracle is placing high expectations on the latest version of its 9iAS application server and is going after IBM (WebShpere), Sun's iPlanet and (WebLogics) "guns a-blazing". Oracle has finally retired its older (and performance plagued) Java engine in favor of a third-party J2EE-certified EJB container from Orion. As mentioned above, Oracle's OC4J solution is nothing more than the Orion Server with an Oracle label attached. If you look at the company package names of all the classes in the ZIP, they [Oracle] haven't even changed the name to 'oracle'. Orion was created in an apartment by two developers aged 22 and 24 years old from Sweden. While far from proven technology, Orion is a product that has cultivated a small by loyal audience. In addition to this new Java engine, 9iAS also includes capabilities for portals, workflow, clustering, caching, application integration, reporting and other features.

Oracle Web Server 1.0

The World Wide Web began to gain acceptance in many businesses around the world in 1995. Oracle responded to this growth by bringing Oracle Web Server 1.0 into the marketplace.

Oracle Web Server 1.0 was nothing more than an HTTP server, often called the Web listener, licensed from a third party company called Spyglass. Like many other Web Servers during this time, Oracle's Web listener provided support for two of the most common protocols: Hypertext Transport (HTTP) and Common Gateway Interface (CGI).

Included with Oracle Web Server 1.0 was a CGI program named the Oracle Web Agent (OWA). The Web listener would invoke the Oracle Web Agent CGI application to execute stored PL/SQL procedures that would be responsible for generating an HTML response for an HTTP request. All stored PL/SQL procedures would use a PL/SQL Web Toolkit (also included with Oracle Web Server 1.0) to generate an HTML response (dynamically) containing data retrieved from the database, ensuring the document delivered to the Web browser that contained current and up-to-date data.


The PL/SQL Web Toolkit is a collection of stored PL/SQL packages used to produce HTML tags containing database data.

Figure 1: Web Server 1.0

One of the major obstacles for this approach was scalability. For each HTTP request, the Web Listener created a new CGI application process and presented a huge cost of spawning a process for each request. This was especially true for larger numbers of simultaneous client requests for enterprise systems.

Oracle Web Server 2.0

Knowing they needed to address the scalability issues inherent in CGI, Oracle released Web Server 2.0. Oracle completely redesigned their architecture and added support for plug-in services.

One of the biggest changes with Oracle Web Server 2.0 was the inclusion of a persistent process called the Web Request Broker (WRB). An application programing interface (API) was provided with the Web Request Broker that was used to build "plug-in" applications. The WRB would then act as a switch to direct all HTTP requests to a specific plug-in application. The OWA CGI application (included with Oracle Web Server 1.0) that executed stored PL/SQL procedures was converted into an application plug-in called the PL/SQL Agent.

Also included with Oracle Web Server 2.0 was a Java plug-in to execute Java applications for dynamically generating HTML. The Java plug-in was based on JDK 1.1.2 and included an integrated Java Virtual Machine (JVM). The JVM included with OWS 2.0 had the standard input and output streams "rewired" to communicate with the WRB. In short, the Web Request Broker would direct all HTTP requests to either the PL/SQL Agent or Java plug-in. The WRB then returns all HTTP responses back to the client view through the Web listener.

Figure 2: Web Server 2.0

Another plug-in included for Server-Side Includes (SSI) was the LiveHTML plug-in. Oracle also published the Web Request Broker API to allow anyone to build a plug-in application. These application plug-ins is what made Oracle Web Server 2.0 an extensible environment. A Web Request Broker (WRB) process was assigned to each Web listener and was already executing (persistent) before an HTTP request arrived. The overhead of starting a new process for each HTTP request was eliminated, as was the case in the order CGI implementation in Oracle Web Server 1.0, and thereby improving performance when processing HTTP requests.

Writing a Java application for Oracle Web Server 2.0 was very simple and straightforward. All a developer would need to do was to provide a standard public static main() method in their Java class, and use System.out.println() to write the generated HTML to standard output.

At the time Oracle Web Server 2.0 was released, the Sun Servlet API was still a work-in-progress and had not yet been published. Oracle Web Server 2.0 was really Oracle's first step into the world of Java. Oracle also at around this time licensed Borland's JBuilder technology to provide developers with a Java development tool. Oracle first named the development tool AppBuilder for Java but later renamed it JDeveloper.

Oracle Web Application Server 3.0

Oracle continued their mission for a web application server platform that provided a superior scalable architecture. Using work that was started in Web Server 2.0, Oracle refined and extended this product and released Oracle Web Application Server (OWAS) 3.0. OWAS 3.0 also laid the foundation for a later generation of the product known as Oracle Application Server (OAS) 4.0.

By far, the biggest change in OWAS 3.0 was the introduction of a CORBA infrastructure through which other components communicated using a common and accepted protocol. All processes in OWAS 3.0 used the CORBA infrastructure could be be distributed across multiple server nodes which provided load balancing for requests over multiple nodes. Not only did this new architecture provide a significant leap forward in scalability but also provided redundancy when a remote node failed.

For the case of this article, the term node refers to a single host server running the OWAS 3.0 (or 4.0) software. The first OAS node installed is called the primary node, while all subsequent servers are called remote nodes. Web Server 2.0 started one Web Request Broker for each Web listener process in the site. This is not the case with OWAS 3.0 where only one Web Request broker is started for an Oracle Web Application Server 3.0 site, independent of the number of Web listeners running.

The OWAS 3.0 architecture added A cartridge factory process was added to the OWAS 3.0 architecture whose primary responsibility was to start, stop and monitor all cartridge-based applications (e.g. Java cartridge, PL/SQL cartridge, and LiveHTML cartridge).

Although the new CORBA infrastructure and resulting multi-node architecture provided a giant leap forward in scalability and redundancy, so did the cost of administrating the environment. Administration of a multi-node site was still manual and each node had to be started in a controlled fashion, starting with the primary node. The term plug-in services from Oracle Web Server 2.0 was replaced and came to be known as cartridges. Oracle also added several pre-installed cartridges such as Perl, and the Java/CORBA cartridge for Java clients using the Internet InterORB Protocol (IIOP) to connect to CORBA objects. By using a remove server facilitator, the IIOP protocol allows a client to invoke a method on a remote server. Another significant change was that the included JVM used to execute the Java cartridge code was upgraded to support JDK 1.1.4.

Figure 3: Web Server 3.0

Another significant change OWAS 3.0 provided was to offer a choice of the Web listener from the following:

Oracle Application Server 4.0

Oracle's pursuit to further expand their scalability in an application server technology continued with their release of Oracle Application Server 4.0. The cartridge processes from OWAS 3.0 are now multi-threaded processes called cartridge servers, or application processes. It is possible for a cartridge server process to run multiple cartridge instances (or threads) of the same type: (e.g. a PL/SQL cartridge server can run multiple PL/SQL cartridges with each cartridge servicing one HTTP request). This was a major improvement over OWAS 3.0, where each cartridge handling an HTTP request was a separate process. Other important changes in the OWAS 4.0 architecture included:

Figure 4: Web Server 4.0

Oracle 9i Application Server Release 1

Oracle9i Application Server Release 1 (V1.0.2.2.x) is Oracle's new application server platform and follows on from OWAS 3.0 with far more performance and scalability than in any previous release. Oracle9iAS uses the Apache Web server software for all HTTP traffic, and the Apache JServ module for Java servlets.


At the time of this writing, the use of the Apache / Tomcat implementation was being considered.

The PL/SQL cartridge in Oracle9iAS written as an Apache module (called a mod). (i.e. mod_plsql which is now called the PL/SQL gateway)

In addition to the Apache modules, Oracle provides its own Java Server Page (JSP) engine, and the Oracle8i JVM for executing Enterprise JavaBeans or CORBA components.


The Apache / Tomcat implementation is under consideration for a future release of Oracle9i Application Server.

In order to run the Oracle8i JVM with Oracle9iAS, you need only install an Oracle database instance with the Apache software option to direct requests to the Oracle JVM when required. For a detailed look at this type of configuration, refer to "Deploying Java Servlets and JSPs using the Oracle HTTP Server (8i or higher)".

Oracle 9i Application Server Release 2

At the time of this writing, Oracle's current production version of their Application Server Release 2 is (V 9.0.2). At the core of this version is a product called "Oracle 9iAS Containers for Java" (OC4J). The version of OC4J that comes with V 9.0.2 is not fully compatible with J2EE 1.3 specifications but very close. There is a separate download available of just OC4J that is in "pre-release" form called Oracle9iAS Containers for J2EE - 1.3 Developer Preview.

Keep in mind that many of the different Oracle/Java Technologies talked about previously ARE NOT 100% compliant with J2EE. Oracle 9iAS Release 2 is the first of Oracle's product line that contains full support for J2EE.

About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.

Copyright (c) 1998-2018 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at jhunter@idevelopment.info.

I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.

Last modified on
Wednesday, 28-Dec-2011 13:53:03 EST
Page Count: 29202