1) The type 1 driver is the JDBC-ODBC bridge which provides JDBC access to most ODBC drivers. One drawback however in this approach is that database client code must be loaded and configured on each client machine (via the Control Panel). In addition, the performance overhead of ODBC can effect overall speed. The JDBC-ODBC bridge may not be suitable for applets in a browser, as the browser vendor may have not implemented it due to Internet security issues. 2) The type 2 driver is considered partially Native and partially Java. The driver can convert JDBC calls into calls for the client API (i.e. Interbase, Oracle, etc.) This driver also requires native code on the client side, similar to the Type 1 driver. 3) The type 3 driver is defined as an all Java driver which by way of a particular network protocol translates JDBC calls into a database managment system independent network protocol. Then a Middleware server then translates this into a database managment system protocol. One would use this driver if one wanted to use a database middleware solution. Visigenic, for example, would be considered a middleware vendor. 4) The last driver, a Type 4 driver is a native protocol, 100% Java driver. This allows direct calls from a java client to a DBMS server. Because it's written in 100% Java it requires no configuration on the client machine other than telling your application where to find the driver. However, you still must deal with Java Security mechanisms. For example, an "Untrusted" applet can connect only to the host from which the applet was downloaded.