Java and its role in the corporate database
Java holds great promise for a wide variety of computing, telecommunications, and entertainment applications. The world is rife with software products, but the center of the corporate universe is the database and the information it contains. The new JDBC database API to be finalized by JavaSoft this week is an excellent start as far as making Java a major component in corporate information systems. Creative developers don’t have to wait for JDBC to connect to database servers today.
The corporate database
Designing, updating, securing, reporting, and disseminating information in databases is the chief occupation of the majority of information professionals, and this information may be stored in hierarchical, CODASYL, relational, object-relational, or object databases.
If you seek evidence of the importance of databases, consider the following: Five of the top dozen software companies (IBM, Oracle, Sybase, Informix, and Software A.G.) have built their businesses primarily on databases. The top 25 software companies are heavily skewed toward databases, database tools, and applications built on top of databases. And in the corporate world, product licensing and staffing costs are primarily oriented toward building, deploying, and maintaining database applications.
In order for Java to be a serious power in the enterprise, programmers must be able to write client applets, server servlets, and server applications that easily integrate with corporate databases. While the lure of Hollywood and the Internet may be painting Java as a tool to enliven Web sites with entertaining multimedia and interactivity, it is in the nuts-and-bolts world of data management that the language will either succeed or fail.
Java and JDBC
The JDBC specification has been available for review on JavaSoft’s site on the World Wide Web since March and is expected to be finalized by the time you read this article. JDBC is built around three basic assumptions: Java must have native support for popular databases; the initial API should be built to include compatibility with existing database APIs like ODBC; and database support must range from remote access via applets through multitier applications distributed across servers.
Java must have native support for SQL databases at a minimum, and ideally must include support for SQL3, object-relational databases, and object databases. Object and object-relational databases are relatively easy to support because they are flexible enough to provide support for all Java data structures directly. Indeed, for many object database vendors like Object Design, supporting Java is easier than supporting the complete C++ data model as they do today. Mapping Java’s object view of the world to the 2-D world of relational databases is a greater challenge, but simply accessing information from these sources through a low-level interface is not.
The JDBC API is an enhancement of concepts in widespread use through the call-level interface (CLI) originally defined by X/Open and popularized through Microsoft’s ODBC. As a call-level interface, JDBC is a low-level standard, its primary purpose being to execute raw SQL statements and return their results to the caller (in many cases a browser). While SQL itself is a “standard,” variants on that standard are supported by nearly every database vendor as a means toward product differentiation. This is particularly true in areas such as outer joins and stored procedures. JDBC is designed to pass any query string to the underlying database; it will permit access to extended SQL features at the potential risk of generating an error from data sources where the feature is not supported. The minimum level of SQL support required from a database product is SQL-2 Entry Level, on which most existing products can comfortably reside.
Importantly, JDBC is designed to insure that its API fits easily with existing APIs like ODBC. JavaSoft is working closely with a number of database vendors and tools suppliers (such as Intersolv) to provide bridges between the two standards. However, ODBC is not the only standard that may be supported via JDBC. Database-specific interfaces from Oracle, Sybase, and IBM, among others, will undoubtedly be written for applications that must coexist with existing applications, or in cases in which performance is of primary concern. Similarly, JDBC interfaces will evolve for network interfaces to enable access to multiple databases on different servers.
Today many people think of Java as a language for building applets that are downloaded to and executed by browsers, but its database API has been designed for much larger, more sophisticated applications. JDBC provides for the concept of database access applets. It lets developers distinguish between trusted and untrusted applets. Untrusted applets are typical in an Internet scenario in which information is transferred across insecure boundaries. Untrusted applets face a particular set of challenges in that they must execute in the “sandbox” of the Java Virtual Machine (JVM), from which there is no access to — and frequently no knowledge of — the local client’s systems resources. Communications between databases and Internet applets also face an unknown latency as requests are routed across an ever-changing network topology to a server that may be in the next room or on the next continent.
JDBC presupposes that Java will be used in other application scenarios. As such, the API is designed to manage data access where code is trusted and is permitted to access local or network resources (beyond a specific URL) to read and write files and open network connections. To succeed as a language and as an interface, Java and JDBC must provide a solution to developers who write these mission-critical database applications. In a typical intranet scenario, developers may use Java to build multiple applications on which access to a single database is both common and essential.
JDBC is also designed to provide a natural implementation platform for N-tier client/server environments. In this scenario, a Java application may make a call to a middleware layer of services, which in turn accesses databases. These calls may be made through mechanisms such as a remote procedure call (RPC), an object request broker, or — dare we say it — OLE. Multitier database implementations provide an additional layer of security, performance, and management for database administrators by providing mediated access to specific databases where caching or local business rules may be implemented as needed.
An alternative solution
While JDBC holds great promise for database applications built in Java, it isn’t quite there yet. Developers who need to implement an application immediately have a clever alternative. As long as there is a non-Java program on the server to handle the basic details of database interface, existing APIs like ODBC can be used with Java applets without recourse to any other interface.
Some background: One of the great benefits of using Internet technologies is the simple but elegant construct of a universal resource locator (URL). In today’s world, URLs typically point to static HTML pages. This may be more an artifact of Internet history than a design limitation. The reality is that URLs can (and increasingly will) point to other resources — especially programs. URLs are an excellent mechanism for interfacing with programs because they consist not only of a network address but of an argument list that can be interpreted by an intelligent resource.
When a program resides at the end of a URL address, these arguments can simply become arguments to a program and can be executed on a remote server. Through two simple calls, GET to pass a single packet of information to the server and POST for arbitrary-length requests that can amount to entire files, a client can pass a complex stream of information to the server for interpretation and execution. When the server application is a program (a C++ program is the best example), it is quite possible to use this simple mechanism to do the equivalent of a remote procedure call over the network.
The URL address points to the server application, the application invokes a method on the server, and the URL’s arguments are input to this method. Where the method accesses a database through an existing standard like ODBC, the arguments can execute typical database constructs such as INSERT, DELETE, and UPDATE. Results are returned to the client via the standard HTTP protocol for interpretation and display by the browser. The results may be converted by the server program into any standard HTML content type or any available plug-in. Typically the conversion will be to an HTML page that replaces the typical dialog box in a standard ODBC environment.
Since the concept of a URL is built into Java, and since Java applets are capable of executing on many browsers, the language provides a flexible environment for distributing logic across clients and servers. The nature of Java promotes the use of object-oriented constructs and the notion of method passing as the primary interface between client and server. The fact that the client is a Java applet running in a browser, and the server is a C++ program executing as part of an HTTP server, is only relevant to the harried developer.
Conclusion
Databases are the center of the corporate universe and central to Java’s future. When the history of information management is written by some hominid in the future, most of the paragraphs that include the word Java will also include the word database. While JDBC will be the focus of this history, existing standards like ODBC will be much more than a footnote, and they are readily accessible to the creative programmer today.
