【正文】 urity, implementation, robustness, and automatic portability of applications. ? A literal translation of the ODBC C API into a Java API would not be desirable. For example, Java has no pointers, and ODBC makes copious use of them, including the notoriously errorprone generic pointer ``void *39。 solution. When ODBC is used, the ODBC driver manager and drivers must be manually installed on every client machine. When the JDBC driver is written pletely in Java, however, JDBC code is automatically installable, portable, and secure on all Java platforms from work puters to mainframes. In summary, the JDBC API is a natural Java interface to the basic SQL abstractions and concepts. It builds on ODBC rather than starting from scratch, so programmers familiar with ODBC will find it very easy to learn JDBC. JDBC retains the basic design features of ODBC。 in Appendix B. However, we feel that most new functionality belongs in higherlevel APIs such as the object/relational mappings and embedded SQL we mentioned earlier in ``JDBC Is a Lowlevel API and a Base for Higherlevel APIs.39。s machine as the client, and the machine housing the database as the server. The work can be an intra, which, for example, connects employees within a corporation, or it can be the Inter. In the threetier model, mands are sent to a ``middle tier39。39。s JDBC implementation has passed the conformance tests provided by JavaSoft. These conformance tests check for the existence of all of the classes and methods defined in the JDBC API, and check as much as possible that the SQL Entry Level functionality is available. Such tests are not exhaustive, of course, and JavaSoft is not currently branding vendor implementations, but this pliance definition provides some degree of confidence in a JDBC implementation. With wider and wider acceptance of the JDBC API by database vendors, connectivity vendors, Inter service vendors, and application writers, JDBC is quickly being the standard for Java database access. JDBC Products At the time of this writing, a number of JDBCbased products have already been deployed or are under development. The status of these products changes frequently, so the reader should consult the JDBC web page for the latest information. It can be found at the following URL: JDBC Driver Types The JDBC drivers that we are aware of at this time generally fit into one of four categories: 1. JDBCODBC bridge plus ODBC driver: The JavaSoft bridge product provides JDBC access via ODBC drivers. Note that ODBC binary code, and in many cases database client code, must be loaded on each client machine that uses this driver. As a result, this kind of driver is most appropriate on a corporate work where client installations are not a major problem, or for application server code written in Java in a threetier architecture. 2. NativeAPI partlyJava driver: This kind of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine. 3. JDBCNet pure Java driver: This driver translates JDBC calls into a DBMSindependent protocol which is then translated to a DBMS protocol by a server. This server middleware is able to connect its pure Java clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC alternative. It is likely that all vendors of this solution will provide products suitable for intra use. In order for these products to also support Inter access, they must handle the additional requirements for security, access through firewalls, and so forth, that the Web imposes. 4. Nativeprotocol pure Java driver: This kind of driver converts JDBC calls into the work protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is an excellent solution for intra access. Since many of these protocols are proprietary, the database vendors themselves will be the primary source. Several database vendors have these in progress. The expectation is that eventually driver categories 3 and 4 will be the preferred way to access databases from JDBC. Driver categories 1 and 2 are interim solutions where direct pure Java drivers are not yet available. There are possible variations on categories 1 and 2 (not shown in the table below) that require a connector, but these are generally less desirable solutions. Categories 3 and 4 offer all the advantages of Java, including automatic installation (for example, downloading the JDBC driver with an applet that uses it).