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:

• Oracle Servlet Engine (OSE)
• Apache JServ
• EJB's in the database using JServer

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 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.

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

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.

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.

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.

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.

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

• Spyglass (Oracle Web listener)
• Microsoft Internet Information Server (IIS) Web listener
• Netscape FastTrack or Enterprise Server.

• The node manager now provided administration control over a multi-node OAS installation from a single location.
• The JServlet cartridge now supported the Sun Servlet API and replaces the original Java cartridge, the JWeb cartridge.
• Support was added for the Apache Web listener on UNIX systems.
• The Java Virtual Machine (JVM) was upgraded to support JDK 1.1.6.

NOTE: 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.

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

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.