Java and Database Synergy
Many of the major database vendors - Oracle, Informix, Sybase and IBM, are supporting Java by embedding a Java Virtual Machine (JVM) in their servers. This shotgun marriage is the beginnings of a powerful new synergy - a combination of relational database and object-oriented capabilities.
With support from the major database vendors, Java is available for most database systems. Developers now have a stored procedure language that can be portable across database servers from different manufacturers. Java provides a viable alternative to the proprietary stored procedure languages previously offered.
However, Java is more than just a universal stored procedure language. Java objects can be stored as values in database columns. These are special columns whose type is a Java class. Java column values are active objects whose methods can be accessed in SQL commands or when retrieved locally.
Stored Procedures in Java
Since the beginning, stored procedure languages have been proprietary to each database vendors, with no commonality. Using more portable languages, like C++, for server procedures has raised issues of safety (an errant procedure could crash the server) and security. Now, with most vendors supporting it, Java is becoming the stored procedure language of choice, promising portability and safety.
Java servlets are an excellent fit as a stored procedure language:
- Portability - Java database servlets can be written in Pure Java using standard JDBC for database access.
- Safety - Java code is free from pointer misuse and memory leaks. The JVM (Java Virtual Machine) applies the sandbox approach to executing Java code, restricting external access.
- Security - The JVM sandbox mechnism provides secure execution of Java code. The JVM also supports authentication of Java servlets.
With a portable stored procedure language, code can be transferred between servers from different vendors,
vendor-specific training is reduced and database-independent applications can be distributed with application-specific
stored procedure code.
Java Objects in the Database
Even more revolutionary than Java database servlets is the ability to define the type of a database column as a Java class. The major database vendors support cataloging a Java class in the database. Columns in database tables can then use the class for their type definition.
In the rows of the database table, the value of a column defined with Java class is an instance (object) of the Java class. Instances are created using the constructor for the class. Column values are active instances. Their methods are callable in SQL commands. When the client retrieves a column value defined as a Java class, it is an active object that is often executed in the Client's JVM. Both class and instance methods may be accessable.
Java objects in SQL databases are an excellent synergy of Object-Oriented and Relational Databases. It greatly extends the expressive power of SQL while making object-oriented database techniques widely available.
Java in the Database or the Database in Java?
How should relational databases and object-oriented capabilities be combined using Java? The major vendors have opted for embedding Java. They are including a JVM (Java Virtual Machine) in their existing database systems.
The server embedded JVMs are all proprietary. This is because the JVM must be tightly integrated with the database system. Special internal interfaces are required since the main server is implemented in a different language (usually, C/C++).
Are the proprietary JVMs going to do the job? Or, are they replacing proprietary stored procedure languages with a somewhat more portable language? Compatibility and efficiency will be a problem. Will the database Java's be able to keep up with enhancements in the language and improvements in JVM technology? The JVMs from database vendors will not be best-of-breed!
A last consideration is compatibility between the JVM running on the database server and any JVM running on the client system. This is needed to retrieve Java objects from the database and efficiently execute them on the client. To achieve compatibility, the client may need to use a database vendor supplied/recommended JVM.
FirstSQL/J database products are implemented entirely in the Java(tm) programming language. Both the database server and any Java servlets or Java database objects run on the same JVM. Server administrators can choose the best JVM for their server configuration. They can select the JVM for the client from a wide variety of vendors to meet any desired compatibility.
Execution of user-defined Java servlets and database objects is more efficient with a Java RDBMS because no translation bridges to the server are required. There is also a severe reduction in memory overhead. The RDBMS uses native JVM services.