HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 
Enterprise Java: Oracle8iJVM

The Oracle Internet Platform embeds the Oracle8i JVM within the Oracle8i database and Oracle Internet Application Server (iAS) as the enterprise Java engine for Oracle. This article explains Oracle8i JVM's base architecture, its support for J2EE APIs and its latest performance and architecture enhancements.

E-Business Platform Base Architecture
The base architecture, the foundation on which a Java platform's building blocks are implemented, is typically the VM architecture: memory management, execution environment and so on. As an e-business platform, it should provide robustness, reliability and scalability across all system components. One key question: What makes the Oracle8i JVM different from other VMs?

Session-Based Architecture
In a break from the design of most client Java Virtual Machines, the Oracle8i JVM has promoted a session-based architecture in which each user executes within a session. From the user's perspective, each session executes Java with its own dedicated JVM that has its own containers and its own Java global variables and garbage collector. Under the covers, sessions are scheduled and run on a dynamically allocated set of processes (or threads on Windows/NT) – typically less than 10% of the number of connected users – using Oracle's multithreaded server (MTS). The MTS architecture provides robustness, as a replacement process is automatically started by the Oracle 8i runtime in the event that process fails. By isolating sessions, this architecture allows parallel and independent processing, memory allocation and garbage collection (see Figure 1). On the other hand, sharing of code, metadata, immutable statics and read-only objects across sessions reduces session memory footprint and activation time.

Figure 1
Figure 1

Session Isolation vs Sharing
Java objects held in static variables between calls are, by default, completely private to the users session. The 8i JVM maintains the complete context of each session so that isolation is an implicit part of the system, not one that's enforced by the programming model. Session isolation doesn't allow the sharing of user "state" or contexts. Oracle8i JVM sessions can share read-only objects across sessions through JNDI. This feature is used internally for now to maximize sharing of metadata and will be exposed in the future for use by user programs as well.

Connectivity
The total number of MTS processes required to run tens of thousands of connected users sessions is dynamically adjustable and approximately equals the number of concurrently active sessions (approximately less than 10% of the number of connected users).

Session IIOP
Session IIOP provides Oracle JVM with the ability to create and access objects in multiple sessions from a single client and services that handle multiple server objects in multiple sessions. This allows the JVM to distinguish objects based on the session in which they are activated. The standard CORBA doesn't have the notion of "sessions." Oracle8i JVM does. It achieves this by extending the IIOP protocol, using a Session IIOP component tag within the object reference (the OMG assigned component tag ID for session IIOP is 0x4f524100). Session IIOP still looks the same, on the wire, as regular IIOP. URLs have the following form: sess_iiop://<host>:<port>:<service>/:session/name.

Storing Java in the Database
Java sources, classes and resources are stored within the database in internal structures called libunits. Libunits are managed by the Oracle8i runtime in the same way Oracle's PL/SQL packages are managed, providing LRU tradeout of Java classes and keeping track of class dependencies during development and updating of Java applications. Users can place Java code in the repository graphically using Oracle JDeveloper or by a command-line utility (loadjava). Classes can be resolved and updated dynamically without interrupting or recycling the 8i JVM.

Consistent JDK Across Platforms
This base architecture, currently based on Sun's JDK 1.2.1, is identical on every platform where Oracle8i or iAS is ported, providing a consistent Java deployment environment across more than 60 platforms.

E-Business Base Infrastructure Services
The Object Management Group has defined one of the most exhaustive standards-based infrastructure services via CORBA services. Several key services in this collection have been respecified as is or redesigned by Sun Microsystems as part of Enterprise Java infrastructure services. Among them are Naming, Transaction, Security and Persistence. These services form the foundation for higher-level services required by e-business applications. Oracle8i JVM incorporates these services.

Naming: Built-in JNDI
As a central naming repository, Oracle8i JVM implements JNDI 1.2 API using database tables for secure, robust and scalable storage of namespace mappings. This JNDI implementation provides a server-side SQL-based driver (SQL SPI) for accessing JNDI directly from within the server tier and a client-side RMI/IIOP-based driver (RMI/IIOP SPI) for accessing the JNDI service from Java clients. It's used for binding or registering servlets and JSPs, CORBA/EJB components and non-Java CORBA Objects. It also allows the sharing of read-only objects across sessions and the registration of services at database start-up, typically IIOP and HTTP. The CORBA CosNaming interface has been implemented on top of the JNDI namespace for pure CORBA users.

RMI/IIOP
For robustness, scalability and ease of programming (no IDL), Oracle8i JVM has implemented RMI over IIOP based on Visigenics Caffeine; it also provides support for method overloading and Java exception handling through serialization.

Java Transaction API
Oracle8i JVM implements the Java Transaction API (JTA) 1.0 standard, including client- and server-side transaction demarcation, two-phase coordination, multitier transaction context propagation, single-phase commit optimization, and support for JDBC as well as CORBA/EJB transaction managers. It also provides support for JDBC, HTTP, RMI/IIOP clients and mixed client types.

Security
Oracle8i JVM security is based on:

  • A built-in Oracle8i database security: execution rights required on stored Java classes as well as on SQL execution
  • Java 2 Security, including granting or revoking fine-grain or collections of Java permissions to roles
  • Execute rights required on published objects in JNDI
  • SSL (SSL 3.0) authentication and non-SSL login authentication based on a challenge response protocol using DES 48 bit encryption
Query and Persistence
Object-relational mapping is achieved by:
  • Either direct access to Oracle8i's rich database object types that are SQL Types, Object Types, Variable Arrays (varrays), Nested Tables, XML documents and SQL Types exposed to Java (JPublisher) through JDBC/SQLJ or Java Stored Procedures
  • Or by using transparent persistence mechanisms like the Persistence Service Interface for CMP EJB in conjunction with persistence managers that implement such an interface (PSI Reference Implementation, Oracle Business Components Java (BC4J) – O/R mapping and third party O/R mapping) (see Figure 2.)
Figure 2
Figure 2

Component-Based Applications Architecture
The main characteristic of a component-based application is the loose coupling between layers, allowing reuse, partitioning and minimal change impact. Typically there are four logical layers to a partitioned application: View, Application-Model, Domain-Model and Database (see Figure 3).

Figure 3
Figure 3

View Layer
Components that implement the user interface handle the GUI screens and Web pages using GCI scripts, static HTML, Perl scripts, ActiveX, Visual Basic, Java Client Application, Java Applet, Servlets and JavaServer Pages (JSPs).

Servlets are server-side Java classes that execute independently or call back-end components (EJBs, CORBA Server Objects, Java/PLSQL Stored Procedures, other Servlets) and generate coarse-grained dynamic content, typically used as a UI controller or application controller, in conjunction with JSP (serving as the View). Servlets can be chained or pipelined to extend Web server functionality.

JSPs are used to dynamically generate the actual UI or Web pages by assembling coarse-grained dynamic content from servlets and back-end components (EJBs, CORBA Server Objects, Java/PLSQL Stored Procedures) with fine-grained content from Java Scriptlets and static HTML.

Oracle Servlet Engine
Oracle8i JVM embeds a Servlet 2.2-compliant engine suitable primarily for stateful servlets. All servlets activated by one client are in the same session, along with EJBs, CORBA Server Objects, Java Stored Procedures, the default server-side JDBC connection and the SQL engine. The first servlet request creates a session for the client and eventually (on request) an HTTPsession object per stateful servlet context; further requests are routed to the same session using cookies or URL rewrites. OSE supports authentication and access control as specified by Servlet 2.2 through Realms and URL security mappings in the JNDI namespace.

Servletclasses are loaded, stored as library units (libunits) in the database repository, then resolved and published in the JNDI namespace where they can be looked up and invoked through HTTP. For example: http://cavist.com:8080/cellar/welcome.html<path_info>.

public class Hello extends HttpServlet {
public void doGet(HttpServletRequest rq, HttpServletResponse rsp){
rsp.setContentType("text/html");
PrintWriter out = rsp.getWriter();
out.println("<HTML><HEAD><TITLE>Welcome</TITLE></HEAD>");
out.println("<BODY><H3>Welcome!</H3>");
out.println("<P>Today is "+ new java.util.Date()+
".</P>");
out.println("</BODY></HTML>");
}
}

OracleJSP Engine
Oracle8i JVM embeds a JSP engine (JSP 1.1- compliant) on top of the OSE, the Oracle HTTP server (powered by Apache Jserv) and all Web-enabled Oracle products (Oracle Portal, Portal-to-go, Oracle JDeveloper). The Oracle JSP engine supports SQLJ within JSP Scriplets, data access beans for connecting and querying an Oracle database, custom tag handlers and the ability to format results of a JSP using XSL. It emulates some Servlet 2.2 features on Servlet 2.0 engines (JServ) using a globals.jsa file:

<HTML><HEAD><TITLE>Welcome</TITLE></HEAD>
<BODY><H3>Welcome!</H3>
<P>Today is <%= new java.util.Date() %>.</P>
</BODY></HTML>

Oracle HTTP Server Powered by Apache and Extension Mods
Oracle8i JVM ships with an HTTP server (based on Apache) as the default HTTP listener for serving fine-grained static HTML and stateless servlets (JServ). Oracle extends Apache with extension modules (Mods):

  • mod_ose: Dispatches HTTP requests for stateful, coarse-grained dynamic contents to the Oracle servlet engine
  • mod_plsql: Dispatches HTTP requests for stateless PL/SQL and Java stored procedures; maintains database connections specified by DADs (database access descriptors)
Application Model Layer
This layer hosts components that implement stateful business processes (such as a shopping cart), use case controllers or view controllers. It also hosts stateless service components (e.g., rate engine, tax calculator). They can be implemented using servlets and stateful and/or stateless session EJBs, as well as CORBA server objects when infrastructure services are invoked programmatically. The componentization of this layer allows users with different interfaces to access the same components using different types of client interfaces.

Domain Objects or Data Component Layer
This layer hosts components that model and implement coarse-grained domain objects, also called data components or business components.

Coarse-grained business objects are designed as root objects and dependent objects using a design pattern (Façade). They can be implemented as simple persistent Java objects (when they don't require their own transaction and security services) but also as CORBA server objects (programmatic invocation of transaction and security services) or entity EJB (declarative transaction, security services and persistence calls by EJB container).

Oracle8i JVM EJB Architecture
The EJB component model allows the design and implementation of complex business components:

  • Stateless business services: tax calculator, rate engine, for example
  • Stateful business processes/use cases: shopping cart, for example
  • Persistent, uniquely identifiable, coarse-grained, application-independent business entities: customer, portfolio, purchase order, for example
The EJB container in Release 3 of Oracle8i JVM is fully compliant with the EJB 1.1 specification, which mandates the support of entity EJB (bean-managed and container-managed persistency), including a standard and provider-specific XML deployment descriptors. The container is activated within the session address space along with all collocated Java components, including the server-side JDBC driver and the SQL engine. EJB's classes are stored within the shared libunits repository (the database), then published and looked up from the distributed objects subdomain of the JNDI namespace; they run as transactional Java objects when invoked locally from collocated components (like servlets) or as CORBA server objects when invoked remotely through RMI/IIOP.

Persistence Service Interface
For container-managed persistence EJB, Oracle has defined a persistence service interface (PSI) to handle the relationship between the Oracle8i JVM EJB container and the persistence manager (see Figure 2). The container handles the allocation and management of EJB objects, transparent service invocation (transaction and security) and bean deployment. The persistence manager handles the allocation and management of beans; their loading, storing and caching; and JTA synchronization for commits/rollbacks.

Oracle8i JVM ships with a PSI reference implementation (PSI-RI) that provides a simple attribute to column mapping: persistence manager. Oracle's JDeveloper and third-party vendors provide PSI-compliant, complex mapping persistence managers. By providing a common way for dealing with persistence managers (á la EJB 2.0), PSI allows their replacement with little impact.

Object Request Broker
Oracle8i JVM embeds a 100% Java CORBA 2.0-compliant ORB (Visibroker 3.4) that can be activated within MTS processes and shared by multiple sessions while preserving their context isolation. It extends the IIOP protocol and IORs with session ID (for routing), implements the CosNaming JNDI URL interface (for easy and consistent naming) and allows programmatic invocation of all infrastructure services.

Data Access and Management Layer
JDBC Drivers

Oracle8i JVM supports four main JDBC drivers:

  1. Oracle call interface (OCI) client driver (type 2): Must be installed on the Client. Partly Java, it allows the use of Oracle's Advanced Networking options, Net8 tracing and logging; components are deployed on a middle tier but an applet can use this driver.
  2. Thin client driver (type 4): All Java, and uses Net8/TTC database protocol over Java sockets; applets must use this driver, as can components deployed on a middle tier.
  3. Thin server driver (type 4): For applications that need to access other databases through JDBC, from within Oracle8i.
  4. Server-side driver ("kprb"): Runs inside the Session address space, incurring no network round-trip; all components, EJBs, Servlets and Java Stored Procedures deployed on an Oracle8i's tier must use this driver.
An ultrathin driver ("proxy"), under development at the time of this writing, will act as a client-side proxy for the "kprb" driver, reducing memory footprint on the client side.

Object Types
Oracle JDBC drivers materialize database objects as instances of Java objects using either a default mapping (object as oracle.sql.STRUCT) or explicit customized mapping (SQLData interface). For example:

ResultSet rs = stmt.executeQuery ("select VALUE(p) from CUSTOMER_TAB p");
while (rs.next ())
{
// retrieve the STRUCT
oracle.sql.STRUCT cust_struct = (STRUCT)rs.getObject(1);
// list the attributes
Object cust_attrs[] = cust_struct.getAttributes();
// string attribute in Object
String name = (String) cust_attrs[0];
// embedded object
oracle.sql.STRUCT address = (STRUCT)cust_attrs[1];
//embedded array
oracle.sql.ARRAY = (ARRAY)cust_attrs[2];
}
Enhanced Support for JDBC and SQLJ
Oracle8i JVMs' JDBC drivers have complete support for JDBC 2.0 including the XA Resource API, basic statement caching that minimizes cursor creation and tears down overhead, LONG functions on LOBs, JDBC/SQLJ support for VARCHAR functions on CLOBs and support for PL/SQL table of scalars.

In addition, numerous performance improvements have been made at the server-side JDBC driver level and for access to objects.

SQLJ
A higher level than JDBC API, which allows embedding static SQL in Java:

#sql {UPDATE emp Set sal = 3000 WHERE ename = 'SCOTT'};
SQLJ provides support for selecting a single row directly into Java variables, named and positional iterators for accessing the results set of a multirow query and connection to multiple schemas at the same time, although an SQL statement executes in a single connection context:
#sqlj [ctx1] departments = {select dept_name from departments}
Oracle8i JVM enhances its SQLJ implementation by supporting all the JDBC 2.0 features as outlined in the forthcoming ISO standard, including structured types, scrollable iterators, datasources, batching, row prefetching and interoperability with JDBC 2.0 connection pooling. It also provides three different runtime versions: (1) a generic runtime that can be used with any Oracle JDBC driver, (2) a runtime optimized for JDK 1.1 environment, and (3) a runtime optimized for JDK 1.2 environment.

JDBC versus ...

String name;
int id=131341;
float salary=6000;
PreparedStatement pstmt =conn.preparedStatement
("select ename from emp where empno=? And sal>?");
pstmt.setInt(1,id);
pstmt.setFloat(2,salary);
ResultSet rs = pstmt.executeQuery();
while (rs.next()) {
name=rs.getString(1);
System.out.println("Name is: " + name);}
rs.close();
pstmst.close();

... SQLJ

String name;
int id=131341;
float salary=6000;
#sql (select ename into :name from emp where empno=:id and sal>:salary);
System.out.println("Name is: " + name);
Java Stored Procedures
Oracle also provides Java stored procedures. They implement compute-intensive procedures (as opposed to SQL-intensive procedures for which PL/SQL is more suitable). Java stored procedures can be used in the same ways as PLSQL: as stored functions, stored procedures, user-defined functions and database triggers.

Stored procedures are standards based, portable across vendor and secure (access control). They can be invoked through the JDBC by EJBs, servlets and JSPs or called by non-Java and legacy modules or servers (PLSQL packages, Forms, Reports, etc.). Using the same call specification or wrapper as PL/SQL, Java stored procedures allow transparent migration to Java (transparently replacing PL/SQL code with Java, when recommended).

Any public static methods of Java classes can be published and called or invoked as Java stored procedure.

public class Foo {
public static String prependHello(String tail) {
return "Hello " + tail;
}
}

To create a PL/SQL wrapper to expose/publish/register the method and make it callable:

CREATE FUNCTION PREPENDHELLO (s VARCHAR2) RETURN VARCHAR2 AS
LANGUAGE JAVA NAME 'Foo.prependHello(java.lang.String)
return java.lang.String';
E-Business Deployment Platform
Runtime Performance: Bytecode Compilation

By default, Java applications run interpreted. A Java interpreter successively fetches, decodes and executes Java bytecodes. The fetching and decoding steps can be avoided by natively compiling the bytecode; also, the compilation process can apply some code optimization techniques. Oracle8i JVM offers native compilation and optimization.

Oracle8i JVM Accelerator
Oracle8i JVM provides a native bytecode accelerator that allows a deployed Java bytecode (.jar or .class) to be translated into platform-independent C code. The C code is then compiled using platform-specific compilers (optimized for their respective platforms), yielding fully optimized platform-dependent Oracle8i JVM-specific native shared libraries, and run as natively compiled code. Performance improvements range several orders of magnitude.

Deployment Schema
Most Java platforms on the market promote a three-tier deployment with all Java and Web components on a middle tier, typically an application server, and data access and management components on the database tier (see Figure 4).

Figure 4
Figure 4

Oracle Internet Platform Deployment Scenario
Being present in both Oracle8i and iAS servers, Oracle8i JVM allows flexible Web and Java components partitioning across tiers. The following four deployment scenarios are simply examples. Customers can make variations in the way components are deployed over the Oracle Internet Platform.

  1. Single-tier deployment: In this schema all components are deployed on the Oracle8i tier. The benefits include local calls, hence reduced network traversal. This scenario scales to tens of thousands of concurrent users against a single Oracle8i instance using the high-connectivity capabilities of the shared server MTS architecture. Since Oracle8i JVM and its containers are the same on the iAS tiers, beyond this level of scalability offloading the Oracle8i tier on iAS tiers will provide additional scalability.

  2. View layer on iAS; other layers on Oracle8i: A Web site activity consists primarily (75%) of static HTML and stateless servlet requests; this can be served by a farm of iAS/Apache HTTP servers. The remaining 25%, involving stateful servlets, stateless session EJBs, persistent EJBs or CORBA servers, and JDBC/SQLJ/Java stored procedures, can be served by an 8i tier.

  3. View and application layers on iAS; domain layers and data access and manipulation on 8i: In this scenario static HTML, stateless and stateful servlets, and stateful and stateless session EJBs run on the iAS tier while entity EJBs or persistent CORBA server s objects reside on the 8i tier along with JDBC/SQLJ/Java stored procedures. Since domain components are data-oriented, running inside the database will provide efficient execution.

  4. Traditional middle-tier deployment: In this scenario Web/EJB/CORBA components are deployed on the iAS tier while data access and management modules (JDBC/SQLJ and Java stored procedures) reside on the Oracle8i tier. iAS tiers can be duplicated to support the requirements of hundreds of thousands of concurrent users.
Conclusion
By extending its support to J2EE containers and programming models, and enhancing the architecture and performance of Oracle8i JVM, the Oracle Internet platform offers a scalable, secure and robust end-to-end Enterprise Java platform for developing and deploying e-business applications.

AUTHOR BIO
Kuassi Mensah is a senior product manager in Oracle's server technology division and leads the product management team of the Java products group. He can be contacted at: [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.