Uncover OC4J - Part II

OC4J History and Now

My computer faculty always used to say – ‘In the S/w industry - Only fools write the code from the scratch”, When Oracle has started its Web Components development, might had the same thought - so it did not write the Web Server from scratch instead it has borrowed the Open-source Apache Web Server code.

(Just a nut crack, Oracle's decision to opt for Apache is due to its flexible, modular and extensibile architecture, cost cutting in development and testing for Web Server code and other important implications - all of the above - code reusability ;) )

After Oracle has decided to go for Apache, it has fine-tuned Apache for performance and gave it a new name called OHS – Oracle Http Server. It has then introduced new modules like mod_plsql for accessing database via Web Server, mod_osso for facilitating Single Sign-on etc.

Now, regarding the Java part – if a client (or browser) requests for a JSP / Servlet, the first entity that picks up the request from client (or in other words, the first entity which the request goes to) is Web Server i.e., in our case, Apache Web Server. Now the Apache Web Server detects that it has to serve the client with a Java file, it redirects the request to the Java sub-system, which is mod_jserv. Mod_jserv is again a Apache based module which is again fine tuned by Oracle to serve its Java programs.

Oracle Applications contain many self-service applications, which use mod_jserv for executing / running the self-service pages.

Now mod_jserv is just a Java server and contains mini Servlet containers in which servlets and JSPs do get executed. But it does not contain / does not have a fully-feature servlet containers which have advanced features like load-balancing, connection pools etc and also neither it contains any J2EE compliant containers like EJB Containers, JMS, JMX, JAAS supportability etc.

Technology gets emerged and new components are getting added to J2EE. This is sensed by Oracle long before. To copeup with the competition and technology, Oracle has to create its own Java containers which supports the Java Enterprise Edition standards like JDBC Pools, EJB containers, JMS and JMX suppportability, Security features like JAAS, Mailing specs like Java Mail and others. With these requirements, Oracle has started creation of the OC4J containers.

All the OC4J containers are purely written in Java, which support all the specification and components listed in J2EE Specification. Some of them are fine tuned and customized to suit Oracle needs – for example – Oracle implemention of JAAS specification is called as JAZN.

In short, OC4J is a Java based container that fully supports all the specifications of J2EE. 10.1.3 OC4J supports J2EE 1.4 and part of 1.5 specifications. Also, OC4J itself contains Http Server – called as OHS (Web server with Apache code base) in itself, but this web-server is not for serving the client requests. Instead this webserver is used for management i.e., to:
a) Configure OC4J itself (remember OC4J is just a container and it does not have any interface to get managed unless like in WebLogic where we get a Java console).
b) Configure the applications (like Web beans, EJBs and others) deployed in the OC4J Container. Further going, Oracle replaces mod_jserv and market OC4J server.
c) Create and manage multiple instances of OC4J.

Once you connect to the Webserver of OC4J at 8888 port, the main index page would open up and we all are aware of this component page before – i.e., EM – Enterprise Manager. We will see about this EM application in coming parts.

(One thing to note here is – If Oracle iAS, we still get the Apache folder and all the apache configurations. I agree that this is a duplication of webservers but one thing we should not forget here is that all the requests are first taken by a Web server – here it is Apache Web server and not OC4J Webserver and if any request for J2EE component, would redirect it to mod_oc4j.
Apache Server (also called Oracle Http Server or OHS is for serving the client’s request and the webserver in OC4J is to manage OC4J server). Apache server in production systems generally run at 80 to which clients get connected and OC4J webserver default port is 8888. Apache Server is for clients and OC4J Webserver is for Administrators to configure OC4J and to deploy and manage the J2EE Applications).)

Going further Oracle will remove mod_jserv module and mod_plsql modules from its Applications and iAS versions and market OC4J for all Java and J2EE needs.

There is a reason for this –
mod_plsql is a security vulnerability that is prone to attacks by hackers. Although, I would not go in depth here to list all the techniques but to mention URL re-writing is one of the most used hacking techniques. One could directly call the plsql procedures from URL and thereby accessing the user / transaction data. After the OC4J is introduced and Web Server tightly integrated into the OC4J itself and high security features such as SSL and cipher algorithms incorporated in the Container, chances of attack were bought to a zero. Any access to the data will have to go through several layers of security and via thin drivers only.
As for mod-jserv goes, one reason I can jolt down here is OC4J is Oracle’s child – it can mould it the way it wishes. One more thing is that the properties in the mod_jserv is all in the ASCII text files which is hard to read. In OC4J, all the properties are in XML format and dynamic in nature, easy to program, easy to configure, modular and more-ever a Standard.

Uff, there goes my day off after briefing and boring with all the history that I know of the OC4J.

For me, OC4J still has a longgg way to go and is still in its primary level but ofcourse its still a robust, full-featured, highly integrated, extensible, scalable, easily manageable, one of the containers ever written with low memory footprint and on the above my favourite application server components.

Catch you more inside in the next part of OC4J – coming soon your way – OC4J Part III