What Is JDBC?
Total Page:16
File Type:pdf, Size:1020Kb
D.2.h (Database Talk) [InterClient Java Technology For InterBase] InterClient Java Technology For InterBase InterClient Java Technology For InterBase from a talk prepared in July 98 by Paul Ostler for BorCon 98 What is JDBC? · Core Java API As a core java api, jdbc is in every java virtual machine. So jdbc applications are byte- code portable across java platforms and databases. As the lowest level java database access api, it forms the basis of all higher level relational database apis. Jdbc is ubiquitous. · Call Level Interface (CLI) Buzzwords that mean it adheres to the x/open and iso standards for cli database access. Odbc is also based on cli. So jdbc can be thought of as the java analog of odbc, but there are some important architectural differences in that many jdbc drivers are distributed and designed with the network in mind, odbc drivers are usually not distributed and rely on the dbms client library for network access and other client-side functionality. · Low level but easy to use Jdbc is at the same level of database access as odbc, namely cli, but jdbc is much easier to use than odbc mostly because it's a java api. In jdbc, both memory management and data byte alignment are handled for you. If you're an odbc or dsql programmer you know about managing data memory areas, or for dsql, managing sql descriptor areas for your dynamic queries. And unless you're allocating memory off the heap for every column separately, you need to make sure that column data is aligned on proper byte boundaries. As a java library, java manages object memory for you, there's no need to surface these low level details to the user at the level of the api. · Base API As a core api, jdbc is used universally by · Web browsers where the jdbc driver lives transparently on the net. · Desktop applications where jdbc is used for local database access. · Application servers for n-tier applications; jdbc is in the middle-tier, and the application could use corba or rmi based communication. · Client/Server applications for 2-tier applications, jdbc is used for direct database access from client to server. · High level APIs such as Enterprise Java Beans for server based components, Java Blend object-relational mapping, JDX object-relational mapping, JDBTools for replication, Embedded SQL (SQLJ) preprocessor to jdbc. The acceptance of java server technology means jdbc will be used on every tier, and is the universal backend for database access. So Where's the Beef? Jdbc sounds great, so why aren't more people using java and jdbc now for industrial applications? "Putting App Servers to the Test," PC Week Labs Report, June 22, 1998 · "We found Java VMs and Java database drivers just aren't ready for the demands of high- load, production environments." An article from JavaWorld suggests four issues that must be resolved before Java can succeed: "Are you ready for the Java backlash?", JavaWorld, August, 1998 · When will Java performance (particularly on the server) be acceptable? Most database drivers are slow too. · When will the reliability of the language and the JVM be acceptable? Some flakey JVM ports have been released. JavaSoft has put a lot of effort into rolling out new APIs quickly, but often at the expense of reliability of the APIs. · When will there be a standard Java upon which major development efforts can depend? When will Bill Gates say uncle? · Is Java ready to be a major database language? Curious, this was an article about java, not database, but this was included. It's interesting that database may be holding up acceptance of Java! Ok, having played the devil's advocate, I believe these problems are being solved rapidly. InterClient is ready for commercial use, and we'll make a few comparisons with other drivers a little later. But before we can talk about the last issue "Is Java ready to be a major database language?", we need to understand JDBC architectures... ODBC Driver Architecture An ODBC driver is a bridge from the ODBC API to the DBMS API. DBMS client library provides client/server A DBMS protocol is a communication protocol between the DBMS client and the DBMS server, it should not be confused with a low level network protocol such as TCP/IP. It regulates data exchange, control of transactions, and the like. So the DBMS client library drives the network messaging protocol which controls the server. This includes issues of pipelining, prefetching rows, two phase commit, event handling, managing database object handles, synchronizing cursor and transaction state with the server, blob streaming, and many other tasks. ODBC is a C api, and is therefore somewhat platform dependent. Recompilation is necessary, as well as porting of any non-standardized system calls. Here's some example dbms client libraries you may have heard of: Oracle oci, or Sybase dbLib, or InterBase isc. The network messaging protocol for Sybase is known as Tabular Data Stream (TDS), and the DBMS Remote Layer might be Sybase Open Server. BDE Architecture BDE/SQLLinks is a bridge to the DBMS client library BDE is more componentized that ODBC because it defers the database dependencies to SQL Links. So there are separate SQL Links drivers for each database, but only one BDE. DBMS client library provides client/server The BDE also provides higher level functionality than ODBC, such as dataset caching. BDE is a C api and runs only on Windows. Class 1 JDBC Driver Architecture There are 4 classes of jdbc drivers, class 1 and 2 are similar to your traditional driver architecture. A class 1 driver is a bridge from the JDBC API to the ODBC API. Both jdbc and odbc are based on cli, so this mapping is a natural, and allows Java applications to access a database with existing odbc support. JavaSoft provides this jdbc-odbc bridge as part of the jdk. There is only one jdbc-odbc bridge, but there is a separate odbc driver for each database. DBMS client library provides client/server Jdbc is a java api, and the bridge is written in java; odbc is a c api, and an odbc driver is written in C. So the jdbc-odbc bridge is what i call a language driver; the semantic difference between odbc and jdbc is minimal, the main difference is the language barrier. So this same kind of architecture could be used by other language drivers, eg. a perl to odbc bridge. Class 2 JDBC Driver Architecture A class 2 driver is a bridge from the JDBC API to the DBMS API. Similar to class 1 except we're bridging directly to the database's native C client library rather than to odbc. So the closer the client library is to cli, the more amenable it is for the driver. DBMS client library provides client/server We're still a language driver, because we're still bridging from java to c. The jdbc driver is in java, and the dbms client library is in C. This is the most common architecture for language drivers, eg. IBPerl, written by our very own Bill Karwin, has this architecture. Although interclient, which is a class 3 driver, is faster than class 2 drivers. In general, class 2 drivers are the the fastest class of drivers because they use the native C libraries and protocols which have been around a while and have been finely tuned. So why is a class 2 driver architecture not the best architecture for java drivers? Well, it turns out there's a problem with this architecture on the Java platform... Distributed Drivers Just to review, bridges provide a mapping to an underlying database API, and don't have client/server functionality directly, rather bridges rely on the underlying client libraries for client/server functionality. · So what's the problem with bridges in the Java platform? It basically boils down to java's interpreted byte-code capabilities, security sandbox, and zero-install clients. · Applet security One of the biggest strengths of java is its portable byte code without recompilation. Java was designed for the network. Java byte code can float the network, be downloaded dynamically, and execute within the context of a security sandbox. But if the java code makes C calls, the underlying C routine runs outside the security sandbox, so the java verifier has no choice but to assume the code is insecure. · Preinstalled client libraries This entails your traditional client maintenance, configuration and installation of C libraries. And a pre-installed client library defeats the purpose of network capable applets. · Portability Java is cross platform without recompilation. C is not interpreted so requires recompilation across platforms, and ANSI C is a language, not a platform, and does not attempt to standardize system libraries as java does. · So what's the solution? No more C on the client! This means, put the entire database client functionality into an embeddable all java driver! Class 3 JDBC Driver Architecture A class 3 driver is the first of two distributed solutions. In this case, the driver is distributed into client and server components. All client components are pure Java Driver subsumes DBMS client library and protocol The dbms api could either be a server api or a client api. So the jdbc server may reside in a middle tier and is called a gateway if it can proxy service to a remote database server. This could occur if the jdbc server uses a dbms client library. Besides an all-java client, there's another advantage to this architecture. The jdbc protocol is tailored for jdbc access and control.