With all the Java news lately, perhaps you havenıt heard the rumor that Java is a great language for database management. Actually, itıs not just rumor. Already some products are out to prove the proposition that in addition to SQL, a programming language standard is just what the database server industry needs -- and that language should be Java.
A little skepticism at this point is healthy. Despite the zealous claims, Java canıt do everything. So what can an object-oriented programming language do for relational database servers such as Oracle, Informix, or Sybase? The answers start with the two marquee features of Java. Javaıs core code (the Java classes) and the compiler (the Java Virtual Machine, JVM) are distributed to nearly every computer that connects to the Internet with Netscape Navigator and Microsoft Internet Explorer browsers. The benefits of this distribution are that Java programs written for the browser environment need very little code, and the same code will run anywhere these browsers will run (at least in theory).
Many of the directions taken with Java in database management have played off the features of Java distribution model -- small, portable implementations suitable for the Internet. This is one reason why many of the early products are targeted for the embedded systems market. These are products with a small footprint, typically requiring 2MB of RAM or less, that are easy to incorporate into other software as the background database engine. For example, application software vendor Janna Systems (www.janna.com), a maker of contact management software, has decided to use embedded Java database engines (in this case Oracle Lite). Vendors such as Janna are looking for consistency with their own Java code, portability for the application, and the ability to shift data management between client and server as needed.
Most of the big RDBMS companies such as Oracle, Sybase, IBM, and Informix are introducing various approaches to Java in the database server environment. (Microsoft is notably absent.) Perhaps it would be more accurate to say these vendors are experimenting with Java and database engines. With the exception of IBM, which has already put Java hooks in its DB2 Universal Server, the others have fit Java into smaller database products before turning to their main server. Oracle has incorporated a lot of Java in its Oracle Lite 3.0, and Sybase is soon to release a new version of its SQL Anywhere product (now called Adaptive Server Anywhere) that will have many Java features.
These advances toward Java, usually coupled with other Web-enabling features, are often interpreted as desperate attempts to bring relational systems into the object world of the Internet. This isnıt a matter of a bridge over troubled waters, however. Sure, the major relational database systems need to embrace objects, and they wonıt always be able to do it elegantly. The relational and object models are not very compatible (disjointed might be the word). Thereıs always been an odd relationship between data and objects, however. In the object-oriented world, data is presumed to be self-contained, encapsulated within an object. More often than not, though, data comes from some external source, typically a database. This is another way of saying that programming with objects doesnıt really depend on how objects get their data. The Java world and the relational database world coexist quite well, thank you.
Coexistence isnıt automatic, however. It takes some effort to employ Java within the relational framework, and vice versa. The common ground seems to boil down to four areas: JDBC support, using Java in triggers and stored procedures, storing Java objects, and, in a few cases, writing the database server in Java.
When they reach for Java, the first place most relational database systems start with is JDBC. Like the ubiquitous ODBC upon which it is patterned, JDBC is an API and a set of drivers for specific databases. It can connect to anything that will recognize a SQL command and even some data formats such as ASCII text files that donıt. Drivers for JDBC are no more difficult to write than they are for ODBC (which doesnıt make them easy), and like ODBC, there are good drivers and not-so-good drivers. The advantage for JDBC if youıre programming in Java is that you can modify or extend the data access classes to fit the needs of an application. These days, if a product says it is Java enabled, it will at the very least support JDBC.
Whether itıs the sudden growth in the number of Java programmers or the inherent suitability of Java as a programming language, it seems likely that using Java for database triggers and stored procedures will be successful. Java promises a standard for a world thatıs now splintered by dozens of unique or proprietary languages. Right now, these nonportable, proprietary languages tend to lock in the choice of database -- unless the developer is willing to rewrite the code for every database server in the organization. In most corporations a mixture of database servers is the rule, so it would be a boon to require knowing only two languages -- Java and SQL -- that are both more or less portable among all DBMS servers. As a bonus, Java is a major language supported by far more third-party software than is remotely possible for proprietary languages. Java has tools, hundreds of them, and more are coming every day.
One of the problems encountered by Java, notably in the Web environment, is the preservation of the status of objects. While Java classes instantiating the objects are permanent pieces of code, the objects themselves -- their current condition and methods -- disappear as soon as you leave the program. This can be very inconvenient for people on the Web or for developers who need to work with the objects on a daily basis. This problem can be solved by storing Java objects in a database along with the state information needed to create their working environment.
This kind of object storage, usually called an object repository, is becoming a standard usage for object-relational and object-oriented DBMSs. Their ability to store objects and the related metadata makes them ideal for embedded systems within object brokers, application development environments, and other software that must retain Java objects.
Letıs look at some of the first products to incorporate Java within the database engine environment. They come in many shapes and sizes, but in one way or another, they all try to use the Java features I've just mentioned.
Although it hasn't rewritten DB2 Universal Server in Java quite yet, IBMıs effort to incorporate Java in its main database product is the first among the major RDBMS vendors. Universal Server is IBMıs object/relational DBMS, which the company skillfully inserted into its product lineup without the dislocation that struck the ill-fated Informix Universal Server. IBM seems to have realized early on that, in addition to support for mixed data types, it needed to include Java and Web-oriented capabilities in its server.
To that end, DB2 Universal Server supports the JDBC API for dynamic SQL requests. There is also support for stored procedures and user-defined functions written in Java, although Java triggers are not included. Java applications can connect to DB2 via the Client Application Enabler running on the client. Java applets are supported by DB2 without needing the enabler. Bundled with DB2 is IBMıs Net.Data, a middleware application manager on the Web server that can coordinate DB2 with client and server processes, including Java servlets.
Oracle took a lot of heat for abandoning its ambitious Sedona project, a major incorporation of object-oriented technology into the main Oracle database system. Perhaps the project was too ambitious, and for the most part, it wasnıt Java. Fortunately for Oracle, there are many ways to get in the saddle with object-oriented technology, including retrofitting a less conspicuous product. Thatıs part of what makes Oracle Lite 3.0 interesting. Itıs a smaller-scale effort at incorporating Java objects and programming into a database engine environment without the overhead and complexity of the main Oracle database system.
You may have noticed the 3.0 version designation. This doesnıt mean Oracle Lite is a third-generation Java product. Previously the product was called Personal Oracle Lite and was Oracleıs single-user database engine that it marketed as a front end to the heavyweight Oracle7 system. Then in December of 1997, Oracle released Oracle Lite 3.0 as a much-changed, Java-oriented product.
The new Oracle Lite retained much of its previous data management capabilities, especially the data replication facility and automatic connections to Oracle7 and Oracle8. The significant changes were the addition of Java-related features. These included JDBC support, the ability to create triggers and stored procedures in Java, the ability to use Java access classes to store Java objects, and the management of data through a Java-enabled browser application. Oracle Lite 3.0 can fit in approximately 1MB of RAM and requires less than 2.5MB of disk space.
Oracleıs implementation of stored procedures and database triggers is worth a closer look. (See Figure 1.) Itıs both simple to use and fairly sophisticated in scope. Hereıs a brief example of how a stored procedure is implemented in Oracle Lite:
1. Create the Java class "Employee" in a file called Employee.java, which contains the method Pay_Salary:
Public class Employee {
Public static void Pay_Salary( connection conn, String ssno, float sal, String bankID)
{/* deposit code goes here */
}
}2. Attach the Java class to a table:
ALTER TABLE EMPLOYEE ATTACH SOURCE "Employee" IN ı/tempı;
3. After the table has been loaded and the program is running, you can execute the Pay_Salary method, for example like this:
SELECT EMPLOYEE."Pay_Salary"(ı123456789ı,ı222-34-4425ı
,60000.00,ı10-21-BA-74ı)
FROM EMPLOYEE;Table-level stored procedures do not even require the creation of Java objects. They can be called simply by referring to them as table_name.method_name along with the method arguments. Row-level procedures do require a Java object, where the constructor takes the values in the row as arguments. These calls are embedded in the SELECT statement (as in the previous example). Unlike Oracleıs PL/SQL, stored procedures and triggers are not programmed within the database environment. In fact, they can be programmed with any tool you choose.
Oracle Liteıs implementation of Java object storage is also interesting because it uses a collection of Java classes to access the metadata stored in the database. These Java Access Classes provide a direct route to the data without the need for mapping object data to relational data, which should save time for programmers. The access classes have other sophisticated capabilities including data schema creation and query, persistent object management, Java stored-procedure invocation, ACID property enforcement for transactions, and Java proxy-class generation.
You use proxy classes in your application to set up a direct interface to Java classes that model the data stored in the Oracle Lite database. This avoids maintaining an open low-level handle to persistent objects through the Java Access Classes layerıin short, it reduces processor and memory overhead.
Oracle Lite demonstrates a successful attempt to blend Java portability and size advantages without losing the original capabilities of the underlying relational database and data replication features. In the short term, Oracle Lite 3.0 is positioned as a repository for Java objects (similar in concept to Object Designıs PSE Pro). For the medium term, Oracle Lite is aimed at the small-footprint, mobile applications such as the network computer (NC).
Oracleıs use of Java within its database products is heavily motivated by the companyıs commitment to the NC. In a way, placing Oracle Lite in an NC, probably as part of the NC Operating System (NCOS), is an admission that even the network computer needs some local storage and a database manager to handle it. There's no shame in that, because some form of limited and secure local storage should pose no threat to the portability or security of the Java code. No doubt, Oracle would prefer to see its Oracle Lite engine embedded within a Web browser. It already ships with development tools from Netscape, so Netscape might be amenable. Microsoft, however, would probably be less than eager.
While Sybaseıs Adaptive Server Anywhere (formerly SQL Anywhere, and before that Watcom SQL Anywhere) has been the long-time leader in mobile and embedded database systems, Sybase has been playing a bit of catch up with the incorporation of Java. The new version 6.0, which should be appearing about the time you read this, has been renamed Adaptive Server Anywhere, although itıs definitely not a junior version of the flagship Adaptive Server Enterprise.
Sybaseıs stated goal is to let developers use Java as a common language across all tiers. Adaptive Server Anywhere is the first product to use a new "common language processor," which translates either Java or SQL Transact (Sybaseıs proprietary database language) into a machine-language stored procedure. Also being added is the ability to store Java objects in the columns of its Adaptive Server Anywhere relational database. Each column is, in effect, a data type with a name the same as the Java class it stores.
Because products like Adaptive Server Anywhere donıt use the Java classes and JVM found in Web browsers, thereıs considerable speculation that they will become too big to compete in the mobile computer market. Of course, until products like this are actually deployed on the Web or in hand-held computers such as those using Microsoft Windows CE, itıs hard to tell what will be an unacceptable size. On the Web, anything over half a megabyte is already too big for unobservable downloading. On the other hand, anything that fits within the available ROM of a handheld or PDA computer will do.
Not to be outdone, although late to the party, Informix announced at the JavaOne show in March that it would follow a four-point strategy for incorporating Java -- specifically Enterprise JavaBeans -- into its flagship Dynamic Server.
Informix was careful not to talk about replacing stored procedures and triggers with Java methods. In fact, the general drift of the announcements was that Informix would support JavaBeans because they are relatively independent.
Broadbase Inc. doesnıt toot its Java horn nearly as much as other companies, probably because it has a different constituency. Broadbase 1.2 is a turnkey data mart program that includes online analytical processing (OLAP) and Web access. It was designed to extract and manipulate data from a variety of sources and then apply various analytical tools. For example, it provides specialized OLAP tools such as a relational cube -- a database object that stores precompiled aggregates with a number of specified characteristics or dimensions (such as region, sales manager, and fiscal quarter).
Behind the scenes, Broadbase uses a relational database engine and accesses data through ODBC and, of course, JDBC. Interestingly, and Iıd say ironically, Broadbase makes extensive use of the Microsoft COM technology and ships with the Microsoft JVM. If you want to extend or modify the programıs functionality, you can do this by using Java as the procedural language. This is similar in spirit to creating stored procedures in the other products. (Broadbase was reviewed in the DBMS March 1998 issue.)
If you have the impression that Java in database servers has a lot to offer, perhaps the next question ought to be, "Why not go all the way and write the server in Java?" Thatıs more or less what JBMS 1.0 from Cloudscape Inc. has done.(See Martin Rennhackkamp's column in April 1998 DBMS for a review of JBMS.)
Cloudscape's JBMS fits the pattern established by the other RDBMS vendors by shooting for the small footprint, embedded systems market. JBMS is an object/relational DBMS, an approach that Cloudscape says it chose to maintain an affinity for the world of relational data. Like everybody else, JBMS connects to other data through JDBC and uses SQL as the query language. Unlike most others, JBMS is 100-percent pure Java and modular in ways that make it easy to add or subtract components depending on the needs of the application. It can be configured to optimize for attributes such as single-user, small footprint (1MB or less), or multiple users. Its Java code can be extended with modular access and sorting methods.
Note that Broadbase uses a relational database and JBMS an object-relational system. A few more steps in the direction of objects and it would seem natural to consider object-oriented DBMSs that support Java. Youıll find that most of the major ODBMS vendors, including Object Store, Poet, Objectivity, and Ardent Software (formerly O2 Technology, which merged with Unidata), have developed connections to Java. They are diligently working through the Object Database Management Group (ODMG) to implement a standard Java API for object databases.
It should be pointed out that none of the established object-oriented DBMS systems was written in Java. For that, youıll have to check out emerging companies such as W3apps Inc. (www.w3apps.com), which recently released Jeevan, an object-oriented DBMS written in Java. Theoretically, the mating of Java (the programming language) and object-oriented data management should be fruitful. There should be no confusing translation between data organized in tuples and tables and how it is used in properties and methods. Zero impedance mismatch, as the object-oriented DBMS vendors like to say. The model for the programming is the same as the model for the data.
There are those in the relational database industry who feel that Java and its object-oriented entourage is a herd of Trojan horses. Using Java for triggers and stored procedures is almost certain to be more attractive than using proprietary database languages such as Oracleıs PL/SQL. At the very least, the Java programming skills are more broadly marketable. Worse yet (or better yet, depending on your perspective), using Java means introducing classes and objects to the traditionally procedural environment of SQL databases. At some point, it may occur to people who are heavily committed to Java (and depend on it) that a fully object-oriented DBMS might make more sense.
Others say this is nonsense. We wonıt have triggers and stored procedures in Java unless companies like Oracle do the work to make it possible. That fact that they are willing to do it indicates that theyıre not particularly concerned with a sudden shift to object-oriented databases. The fact that JDBC was an extremely high priority for Java (and JavaSoft) is proof enough that relational databases are the driving force in most applications -- and this isnıt going to change soon. Thatıs one reason why Oracle, Informix, and IBM have been willing to cooperate on SQLJ, the specification for embedding SQL within Java. Whether you manipulate the data with Java or some other language wonıt change the fundamentals of the database structure.
Either way, vendors will be trying to exploit Javaıs unique distribution model and its rampant trendiness. When you look at Java in the database server market carefully, youıll probably say, "Boy this is just getting started." At the same time, youıll continue hearing how great Java is for data management, middleware, and distributed applications. Is it too early to be completely optimistic? Yes. The available products are still very green around the gills. The green-gill phase passes very quickly on Internet time, however. It wonıt be more than a year or two before the experimental phase of incorporating Java into database servers gives way to mainstream implementations. It seems likely that as distributed objects become increasingly important, Java-oriented database systems that create, manage, and store the objects will become more important. Just take my word for it ı and pass it on.
Figure 1. Oracle Lite's implementation of Java stored procedures and triggers.
|
What did you think of this article? Send a letter to the editor.