基于Java的访问远程数据库的高效的标准软件体系结构

基于Java的访问远程数据库的高效的标准软件体系结构摘要：新颖的客户端服务器体系结构利用WEB技术越来越有利于远程数据库存取，其结构是在客户端采取WEB浏览器作为图形用户界面，在服务器端采取传统的SQL数据库管理系统(DBMSs)。目前，在标准浏览器和具体DBMSs之间的活动是由一定数量的基于上一代浏览器中的Java 虚拟机的软件结构支持。这些软件结构, 从开放性和灵活性问题看似乎很好, 但在数据库存取方面却存在不足。本文将通过对一定数量的实验结果的分析指出这些不足。本文描述了四个不同的基于Java技术的软件结构支持数据库存取，报告了它们在不同的硬件平台上工作的性能测试，并对测试结果进行了比较分析。关键字：CORBA； Java；JDBC； 执行评估；可视化数据库存取1. 介绍对客户服务器数据库访问的传统解决方法是根据由一种直观语言编写的用户界面的联合的行动(即客户) 和一个标准SQL 引擎(即服务器) 。当前, 这种方法正受到一种基于新兴的Web 范例的新颖的解决办法的挑战。基于互联网的用户界面，通常用java编写，由浏览器从服务器下载并运行在虚拟浏览器上。这样的解决办法的要点是客户软件作为一个独特的副本处在服务器系统，这就好于客户软件在客户机系统里。由于集中所有这些操作在服务器站点成为可能，这就使客户软件的安装、配置和维护费用被降低。对SQL 数据库的基于互联网的访问，可以得到由很多基本组成成分组成的软件体系结构的支持。令人遗憾这样的软件体系结构，从开放性和灵活性来看似乎很好，但是给数据库接口方面带来了明显的潜在危机。图1. 软件结构1: 通过Java接口访问数据库在这篇文章里将描述四个不同的基于互联网访问SQL 数据库的软件结构，并且通过报告和比较他们的执行情况来揭示各个体系结构的潜在危机的来源。本文结构如下：首先我们描述基于Java的数据库存取的准软件体系结构(第2 部分)；然后我们提出使用的试验平台和在我们的实验过程中遵循的方法(第3 部分)；最后我们给出了结果(第4 部分)，并且讨论了软件体系结构的性能(第5 部分)；总结(第6 部分)结束本文。2. 基于Java的数据库存取的软件体系结构在这个部分我们提出四个适合我们的调查的基于java访问数据库的软件结构。每个体系结构都遵循客户机服务器体系并且由3 个主要实体组成：客户、服务器和共用组件。客户和服务器在每个体系结构里是相同的；共用组件在各个体系结构之间则起着不同的作用。客户是一个基于Java技术的浏览器, 服务器是一个接受远程网络连接和查询的SQL 数据库管理系统(DBMS)，网络协议采取TCP/IP 协议。各个软件体系结构的共用组件在结尾部分描述。2.1. 基于Java接口的连接模块结构基于Java接口的连接模块结构如图1所示。阴影部分表示软件模块，程序员必须发展它们使其余的组成部分连接起来。客户端(浏览器)从服务器端上下载一个java应用程序并且运转它。java应用程序通过Java接口模块发送查询和接收回应。服务器(DBMS)通过作为中间代理的一个软件元件与客户交换数据。这样的一个中间代理软件接受客户查询并且通过API 信息库把它们提交到数据库。在java应用程序和中间代理软件之间的连接性是基于TCP / IP协议。在客户端通信由标准Java接口API支持; 在服务器端通信由标准UNIX 插口接口支持。在java应用程序和中间代理软件之间的操作是基于支持基本数据库存取操作的一个普通协议（打开数据库，提交查询，接收回应，关闭数据库）。基于专有的数据库管理系统 JDBC驱动程序的体系结构基于专有的DBMS JDBC驱动程序的结构如图2所示。JDBC是允许java应用程序和应用软件在后台访问数据库的一个标准接口。和前面介绍的结构一样，客户机(浏览器)从服务器上下载一个java应用程序并且运转它， java应用程序通过标准JBDBC 应用编程接口 (JDBC API)访问DBMS。JDBC API 是作为标准Java开发工具包和基于Java技术的浏览器的最新版本的一部份。JDBC针对不同的DBMS也不一样，DBMS实施通信协议时必需用到具体的JDBC驱动程序。具体JDBC驱动程序由DBMS生产商或者第三方提供，并且动态地连接标准JDBC 对象。通常，JDBC驱动程序跟客户端的java应用程序一起从服务器下载。图2 基于专有的DBMS JDBC访问数据库的软件体系结构。图3 基于JDBC桥访问数据库的软件体系结构。2.3.基于JDBC桥的体系结构基于请求机制的软件体系结构如图3所示。如同前面的体系结构，java应用程序通过标准JDBC API 和具体的JDBC 驱动程序与数据库进行信息交流。与以前的体系结构不同， JDBC 驱动程序不直接访问数据库，但是它访问一个通过一份专有的协议运行在服务器上的中间对象。当java应用程序请求连接时,动态地生成二个组分: 为具体DBMS所采取的一个JDBC 代理和一个数据库代理。图4 基于CORBA的数据库访问的软件体系结构。Software componentSoftware productVendorDBMS 1BrowserJava socket DBMS JDBC driverr Request broker Database agent JDBC agent Broker JDBC Driver Client ORBServer ORB PostgreSQL 6.1.1 Navigator 4class .socket class postgresql.driver oplrqbpgr95 svjdbc svclass openlink.driverpackage org.omg. CORBAomniORB2 University of California NetscapeNetscapeUniversity of CaliforniaOpenlinkOpenlinkOpenlinkOpenlinkVisigenic/NetscapeOlivetti & Oracle Research Labs表1 作为被测试的软件体系结构的组成部分使用的软件产品2.4.基于CORBA的组成部分之间可用性的结构基于CORBA的结构如图4所示。在这种情况下java应用程序通过面向对象的API与DBMS联系。API和服务器端的数据库存取对象进行交互。后台操作由对象请求代理程序(ORBs)支持。数据库存取对象由系统集成商开发，它的API通过一种正式的规范语言IDL描述。IDL用不同的语言编写，它支持在客户机和服务器之间的可靠的操作。3. 测试和方法在这个部分我们描述我们使用的试验平台和我们随后执行实验的方法。我们在服务器(PC机, 200 MHz, 32 M RAM, Linux 操作系统)安装了DBMS，在客户机（166 MHz PC机，Linux 操作系统）安装不同的软件组件，选择的产品如表1所示。我们选择了三个对数据库的基本操作来进行测试，即打开数据库、查询、数据库关闭。我们为测试选择的查询是一个单独的选择，它从一个超过4列39 000行的表中而来，由34 byte字符串组成。为了使偶然性减到最小，对每个潜在因素的测量都重复实验超过6000次并且选择最小的结果。LocalSocketPCHPSunOpenExecClose335467376068386268386869表2 各个平台利用java插件对数据库的本地和远程的基本操作的最少时间4. 实验和结果实验能达到的标准和访问数据库的响应时间。在初步的实验里我们测试存在于4个软件体系结构的普通组成部分。在其余实验里我们测试每软件体系结构的响应时间并且确定具体的消耗时间以及这些时间消耗的原因。我们报告初步实验的结果在4.1部分和实验其余的结果在4.2部分。4.1.初步的实验这部分提出初步测试基于java的客户端软件体系结构的响应时间，即，(i)数据库本地存取时间和(ii)Java插件通讯时间。数据库本地存取时间测试，我们开发一个C 程序来执行对数据库的基本操作，并测试它的运行时间。测量数据结果以毫秒为单位，详见表2(第一栏)。我们还测试了以TCP/IP协议联系库和DBMS存取数据库的响应时间。其响应时间小于2ms，可以忽略不记。为了测量Java 插件通讯时间，我们建立了基于插件连接的模块(参阅第2.1 部分)结构。结构中的代理模块可在先前的实验里，通过TCP/IP协议用C程序连接获得。测量结构的响应时间的数据在表格2的第2栏里（每一列分别对应测试中用到不同的硬件平台）。结果显示通过Java 插件远程访问数据库的响应时间不可以忽视，即打开数据库和执行查询的时间占到10-30%。LocalJDBCJDBC/brokerCORBAPCHPSUNPCHPSUNPCHPSUNOpenExecClose33546714310151921048218106107077093800160831396672427175447878表3不同的软件体系结构和客户平台最小查询时间4.2.标准软件体系结构试验这部分提出对标准高效的体系结构进行实验评价，体系结构已在第2 部分中描述。对标准体系结构的评价是基于JDBC 和CORBA模件之间的可用性。在这个部分里我们提出对两个标准体系结构的内部响应时间进行测试，其中一个是基于JDBC 标准，一个是基于CORBA标准。4.2.1.基于专有的JDBC驱动程序的结构的效率表3的2-4列是基本的存取数据库时间数据，以毫秒为单位，那些结构的规则在第2.2 部分里描述。在开放性的操作里我们确定时间消耗有以下两个来源：(i) 每当数据库被打开时建立一个java插件连接，(ii) 通过插件读/写的对数据库连接必要的每个项目(登录，密码，数据库名字等等)。第一项来源是由JDBC 标准数据库关闭操作导致TCP/IP 连接关闭引起的。在PC平台消耗的时间是18 ms，在HP平台消耗的时间是28 ms，在SUN平台消耗的时间是37 ms。第二项来源是由为了减少在java接口上读和写的操作，JDBC对PostgreSQL DBMS不选择单个字符串信息。这一时间消耗在不同的硬件平台上变化很大（PC 10 ms, HP 22 ms ，Sun 67 ms）。4.2.2.基于JDBC桥的结构的效率表3的5-7列是基本的存取数据库时间数据，以毫秒为单位，那些结构的规则在第2.3 部分里描述。在开放性的操作里我们确定时间消耗有以下两个来源：(i)小应用程序分别向请求代理和JDBC桥建立两个网络连接打开数据库；(ii)服务器需要很长的时间来处理这两个连接。第一个时间消耗是36-74ms，它们取决于硬件平台。第二个时间消耗大约是75ms。我们是通过测试对DBMS请求建立连接到获得查询的时间间隔再减去网络延迟得到这一结果的。截止时间表示，数据库关闭是在网络连接关闭之后。截止时间仅仅包括在那些代理终止之前的必要的握手行动。4.2.3.基于CORBA的结构的效率表3的8-10列是基本的存取数据库时间数据，以毫秒为单位，那些结构的规则在第2.4部分里描述。测试结果显示，基于CORBA的结构在所有硬件工作台上直接在Java接口上所有操作的响应时间可以忽略不记（参见表2）。在基于java插件的结构里获得的关于通信协议和插件方法的几个最优化的结果是很有价值的。因此，我们实验表明利用java插件可使CORBA模件之间可用性最优化。5. 讨论实验在前面部分提出了基于java技术访问数据库的标准解决办法。假设在本地连接环境（局域网）下，网络延迟不影响其他的延迟而可以忽略不记，那么这种解决方案是可行的。在我们的实验过程中获得的Java 接口模块的工作特性是：连接和读/写操作的反应时间快，接口相对根据使用的硬件平台传输的数据类型的高可变性。Java插件的可变性影响了所有其他基于java插件的方法的执行。然而我们在进行基于JDBC和CORBA解决办法的实验时，考虑到了所有可变性的影响。一些实验揭示Java 插座接口把它的劣质的性能传播到JDBC 模件。尤其我们做的实验，java插件的执行增加了大约30到100的反应时间并且高度依赖使用的硬件平台。反之，其他实验显示CORBA没有受java插件运行的劣质性能的影响。特别是我们在客户端的java接口上测试到了接近最优的结果，而且在不同硬件平台上结果也不变。最后，我们证明CORBA标准模件是