3.2. JDBC Driver API
java.sql.Driver在第9章有完整的定义了.大部分JDBC驱动只需要完成这些JDBC API所定义的抽象类就可以了。特别地，所有的driver必须提供对java.sql.Connection,java.sql.State-ment, java.sql.Prepared－Statement, and java.sql.ResultSet的实现。如果目标DBMS提供有OUT参数的内嵌过程，那么还必须提供java.sql.CallableStatement 接口。
每个database driver必须提供一个类：java.sql.Driver以使得系统可以由java.sql.DriverManager来管理。
一个显然的driver是在ODBC之上提供对JDBC的实现，从而提供与ODBC接口的JDBC-ODBC 桥，就象前面的图所显示的.由于JDBC放在ODBC之后，所以实现起来简单而且高效。另外一个有用的驱动直接接触数据库无关的网络协议。发布一个协议允许多个服务器实现的方法，例如在ODBC或者特定的DBMS上（尽管已经有了一些使用固定协议的产品，但是我们不打算对它们实现标准化。），是可取的。
4. JDBC使用场合
Before looking at specifics of the JDBC API, an understanding of typical use scenarios is help-ful. There are two common scenarios that must be treated differently for our purposes: applets and applications.
在看JDBC API之前了解一下典型的使用场合是有帮助的。通常有两种情形必须分别对待：applet和application.
4.1. Applet
目前Java使用的最多的从网络中下载的applet，它们作为web文件的一个部分。当中有数据库存取applet和能够使用JDBC来接触数据库的applet。
例如，一个用户可能下载一个显示股票历史价格图的applet。这个applet通过inte.net来从关系数据库中获得股票历史价格。最一般的情况里面，对applet的使用是通过不可靠的边界的。例如从另外一个公司或者Internet上获得这些applet。于是称这个情况为"Internet"场合。然而applet也可能通过局域网下载。在这个情况里面，客户机的安全都还是一个问题。
典型的applet在几个方面与传统的数据库应用程序有所不同：
1. 不可靠的applet被严格地限制在他们被允许执行的的操作上。特别地，不允许他们存取本地的文件，切不允许他们对任意的数据库建立网络连接。
2. 就标识和连接网上数据库来说，Internet环境里面的applet面临新的问题。
3. 当数据库可能与你相隔万里的时候，效率的考虑也有所不同了。与局域网相比，Internet上数据库applet可能会碰到十分不同的反应时间。
4.2. Application
Java也可以用来建立普通的应用，从而想一般的应用一样在客户机上使用。我们相信随着开发工具越来越多，人们开始认识到提高程序生产效率的必要性，以及Java的其他优点，Java的这种用法将越来越流行。在这种方式里面，Java的代码是可以信赖的，且被允许读写文件打开网络连接等等，就想其他的应用程序代码一样。
也许这些Java应用使用的最多的是在一个公司内部或者在Intranet上，所以不妨成为Intranet场合。例如一个公司希望利用Java及其GUI构件工具来建立他的基于合作数据模式的合作软件。这些应用程序将存取局域网或者广域网的数据。Java应用可以作到这些。
Java应用程序场合和Intranet场合与applet场合有诸多不同。例如标定一个数据库最自然的方式是用一个数据库的名字，就象"Customers" 和"Personnel"这样。然后用户希望系统能够定位具体的机器，DBMS，JDBC driver，和Java应用程序。
4.3. 其他场合
还有其他一些有趣的场合：
1. 已验证的applet（Trusted applets）是指那些已经被Java虚拟机器认定是可以信赖的applet。他们之所以被认为是可信的是因为他们已经对上了特定的密匙，或者用户认为从特定来源来的applet是可信的。在安全的方面上他们与应用（appliction）相同，但是其他方面（例如定位一个数据库）与则与applet相似。
2. 与直接从Java GUI出发用客户/服务器模式来度曲DBMS服务器不同，三层存取方式可能被使用。在这个场合里面，Java应用程序对中间层的服务发出调用，中间层的服务在网上，它又再去调用数据库。这些调用可能通过RPC (remote procedure call)或者ORB (object requestbroker )。在这两种场合里面，中间层最好使用一个对象变化。我们希望三层结构会变得越来越普遍，因为对于MIS管理者来说，这可以使得他们有机会在公共数据库上显式地定义合法操作等。同时三层结构可以提供许多效率上的好处。
目前中间层一般用C或者C 这样的语言来完成。通过优化编译器把把Java 字节代码翻译成为高效的机器代码，中间层也可以用Java来实现。Java有许多优良特性（健壮性，安全性，多线程）可以达到中间层需要达到的目的。
5. 安全性考虑
作为网络上的语言JAVA必须十分注安全性的考虑。基于上面的讨论，JDBC的两种主要使用场合里面，我们必须考虑安全性问题：
在Java applications的场合里面Java代码是本地的，所以也是"trusted",没有验证的Java applet代码不可以存取本地的以及其他网络的数据。
5.1. JDBC 和未验证的applet
JDBC首先必须符合JAVA的一般安全规则。另外：
JDBC 必须认为没有验证的applets是不可靠的。l JDBC 不可以让不可靠的applets存取本地数据库。
一个已经向JDBC DriverManager注册的是JDBC Driver只能存取它所来的数据源。
一个applet也只能向它所Download来的服务器来存取数据。
如果JDBC驱动层如果完全确信对一个数据库服务器打开连接不会引起认证或者权限问题（可能由网上随机主机上运行的程序引起），那么它就允许applet打开这样的连接。数据库服务器不通过IP地址来限制存取是相当少的，主要是为了举例。（当心，这一段话我可能翻译反了！！！大家看看原文。）这些限制是相当烦琐的。不过他们与对一般applet的限制是一致的我们没有必要放开这些限制。
5.2. JDBC 和Java应用程序
对于一个普通的Java应用程序（例如全部用Java代码而不是不可靠的applet ）JDBC将从本地的类路径里面获得驱动，并且允许应用程序自由存取文件，远程服务器等等。但是和applet一样，如果由于某些原因一个没有验证的sun.sql.Driver类从远程的来源里面获得，那么这个驱动只能和相同地方来的代码配合。
5.3. Driver的安全责任
JDBC driver可能在各种情况下使用，所以驱动的编制者遵循一定的简单的安全规则，从而避免applet做非法的数据库连接。如果所有的驱动都象applet一样从网上下载，那么这些原则将是不必要的，因为普通的安全规则已经对它做了限制。但是驱动的编写者必须记住一旦他们的驱动获得成功，用户将在本地磁盘安装这些驱动，那么驱动将成为Java环境中一个被信任的部分，所以必须确信它不会被来访的applet所滥用。所以我们鼓励所有的驱动编写者必须遵循一定安全原则。
所有这些原则都是在连接打开的时候使用。这正式驱动和虚拟机器检查当前调用者是否真的可以与指定的数据库连接的时刻。一旦连接建立就不必做更多的检查了。
5.3.1. 分享TCP/IP连接的时候必须谨慎
如果一个JDBC驱动试图打开一个 TCP 连接，那么这个打开会被Java 安全管理机制自动检查。这个机构会检查当前调用栈里面有没有applet，如果有那么就限定它可以访问的机器集合。所以一般地JDBC驱动可以把TCP建立检查留给Java虚拟机。但是如果一个JDBC驱动试图在多个数据库连接之间共享一个TCP连接，那么驱动就必须自己负责检查每个调用者是否真的被允许与目标数据库联系。例如如果我们为applet A打开了一个通往机器foobah 的TCP连接，这并不意味着applet B被自动允许来共享这个连接。applet B可能没有任何访问机器foobah的权力。所以在允许某个程序重用一个现成的TCP连接之前，JDBC 驱动必须通过安全机构来检查当前的的调用者是否可以访问这个连接。通过下面的代码可是实现这个功能。
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkConnect(hostName, portNumber);
}
如果连接是不允许的，那么Security.checkConnect方法将产生一个java.lang.SecurityException。
5.3.2. 检查所有的本地文件访问
如果一个JDBC取得需要访问本地机器上的数据，那么他必须确信调用者是被允许打开这个文件的。例如：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkRead(fileName);
}
如果对特定文件的访问是不允许的，那么Security.checkRead方法将产生一个java.lang.SecurityException。
5.3.3. 作好最坏的准备
一些驱动可能使用本地的方法来桥接底层数据库程序。则这些情况里面判断那些本地文件将被底层函数所访问是困难的。在这些环境里面用户必须作好最坏的打算，并且否决所有下载applet所发出的数据库存取，除非驱动可能完全确信将要做存取是没有问题的。
例如一个JDBC-ODBC桥接器必须检查ODBC数据源的的名称，确保applet只可以访问它的“生源地”。如果对有的名字中不能判断出数据源的主机名，那么只能否决这个访问。为了决定一个当前的调用者是可以信赖的应用还是一个applet，JDBC驱动必须能够检查这个调用者是否可以写一个随机的文件：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkWrite("foobaz");
I. }
（全文完）
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
