作者：张文麟
--------------------------------------------------------------------------------
一、概述
在过去的几年中，人们已经开发投资成千上万的客户/服务器应用。这些应用中包括一个非凡的运行在中心计算机上(也有可能是几个)的服务器软件，以及运行在应用系统各用户端的非凡客户软件。现在人们更希望能够在原有的系统中加入Internet的功能。WWW孕育了大量了WEB浏览器，对Html标准语言这些浏览器是“可编程的”。可以在浏览器开发平台上建立客户/服务器系统的用户。?
有几种访问传统客户/服务器应用的方法：?
修改现存的服务器软件“模拟”一个WEB服务器。
这只是对非常简单的应用可行。可以想象将数据库引擎搬到WEB上情形，对数据库的查询都表示为URL。对布满交互的应用采用本方法实现有困难。?
使用浏览器有关的工具。比如Mosaic的CGI和Netscape的PlugIn API为客户/服务器系统建立基于客户机的WEB浏览器。然而，使用API限制导致了平台相关和浏览器相关的客户软件的应用。?
创建一个“中间件”。
中间件在WEB浏览器和服务器之间充当路由器。在这种客户/服务器体系中，WWW浏览器作为替代客户/服务器的系统客户端软件，不仅能显示和格式化从服务器接收到信息，而且WEB浏览器能够请求中间件为服务器或客户端软件执行额外的工作。?
使用CGI程序能够实现中间件的功能。这是目前应用最多的方法。目前，每种WEB浏览器支持代理(Proxy)应用。HTTP代理通常用于在Internet防火墙之后的WEB访问、或者作为控制访问企业内部网的系统。当WEB浏览器用户请求一文件时，WEB浏览器不是直接连接到文件指定的URL处、而是先与代理联系，代理为WEB浏览器读取文件并回传给浏览器。?
HTTP服务器和HTTP代理可用来建立浏览器客户能够访问现存客户/服务器系统中服务器的中间件。这种方法使客户/服务器系统和数据迁移到WWW上的工作变得轻易。基于中间件的方法不必对现在的应用服务器代码做修改。?
二、基于CGI数据库访问的方法
??
在WEB上典型的数据库应用包含三个部分：WEB浏览器或有时称为WEB客户，带有CGI程序的HTTP服务器，数据库服务器。当用户的请求从WEB客户端(一般是HTML form)传送到HTTP服务器时数据库开始查询并初始化。根据收到的用户请求，HTTP服务器激活CGI程序，CGI把用户输入数据嵌入数据库的SQL语句，然后将其送到数据库服务器处理。查询结果由数据库服务器送到CGI程序返回，通过HTTP服务器传送到WEB客户端。由于CGI是HTTP服务器与外部程序事实上的标准界面，这种数据库访问的模式成为当今WEB世界最常见的方法。?
CGI的概念源于为HTTP服务器与用户自定义服务器应用程序之间提供界面。尽管有其简单和被广泛接收特点，基于CGI的方法存在一些共性的问题。首先，在客户与后台数据库之间的通信必须通过中间的HTTP服务器，当大量的用户同时访问时HTTP服务器很轻易成为瓶颈。对每个用户提交的查询或每一个数据库服务器的响应，HTTP服务必须将从HTML文档转换到数据或从数据转换到HTML文档。这必然为查询处理增加了大量的无效工作。?
第二个问题是基于CGI数据库访问模式缺乏效率和缺乏事务的支持。对每一通过CGI提交到后台数据库服务器的查询，甚至对同一用户提交的连续的查询，数据库也要执行相同的login和logout的过程。这个过程肯定浪费许多的时间和资源，尤其当大量用户同时访问数据库之时。这是因为CGI程序只能以批模式处理多个查询，故CGI程序很难支持在线的数据库事务，这些事务包括在交互模式下与控制函数一起执行多次查询。
这个问题是继续了HTTP的无状态性，HTTP是在WEB上客户/服务器通信的标准协议。无状态性是指服务器对客户请求的反应不依靠于前面的请求和反应的信息。象HTTP之类的无状态协议对单个查询类型的应用是合适的，但对于处理面向会话的数据库程序、当效率和事务处理作为主要焦点时就不够理想。许多的程序开发者提出了围绕HTTP无状态性的不同解决方案，但是只有当低层的协议能够支持有状态的客户/服务器通信、才能形成全功能的数据库系统。?
第三个问题是由于HTTP的无状态性缺乏用户访问控制。WEB客户以批模式传送查询数据和必需的用户ID和密码。由于请求的数据一般由WEB客户以明文的ASCII格式传送到HTTP服务器，这种做法是不安全的。出于安全考虑，一般将用户ID和密码嵌在访问后台数据库的CGI程序中，而用户的访问控制由HTTP服务器处理。HTTP服务器安全功能只能处理用户域的控制、并没有更细的访问控制功能，即在数据库层次上的各种特权功能(比如：读、写、数据库治理和数据库拥有者，等等)。在企业环境中，人们渴望使用由数据库服务器提供的、现已存在的用户访问控制功能，使得相同的安全性和访问特权能够作用于整个企业网络。 第四个问题是由于HTML的限制缺乏图形表示。HTML文档是静态的，没有动态的2D和3D图形表示。尽管VRML能够处理复杂的3D图形，但它依靠HTTP而且没有提供直接的通信接口。借助于形成GIF格式或其它图形格式的图像可以实现图形表示，由于所有的图像必须由在HTTP服务器端的CGI程序产生，这种方法速度低而且浪费空间。客户/服务器模式主要的优点之一是所有的用户非凡功能??比如查询结果的图形表示??应在客户端进行。唯一的可能是WEB客户端能够实现动态的图形功能。?
三、基于中间件访问数据库的方法
?
1?中间件访问数据库的方法优点
?
为所有的平台编写一个客户软件?
开发特定的客户软件使用户的界面具有无穷的创造性，但是这种创造性带来的是高价格，开发者必需为每种运行平台开发客户软件。在异构的网络环境中意味着为Macintosh,MS Windows,以及各种各样Unix开发客户软件。当客户使用浏览器时，系统中只有一套代码(HTML和帮助程序)需维护。当客户必需调用中间件不能模拟的功能时，可使用新的MIME和帮助应用程序。此时，由于功能的要求，必需为每一种运行的平台建立MIME帮助应用程序，但其代码长度比特定客户应用程序平台相关的代码长度短得多。?
模块化?
一旦WEB浏览器访问系统结构建立起来，修改系统变得简单。?
统一界面?
在天天有多个用户群使用多个客户/服务器应用的系统中，当系统迁移到WEB上后，不同系统的不同用户界面合并成一个统一的界面。这能带来多种好处，包括降低培训费用，系统中用户的交流变得轻易。?
2?客户/服务器系统迁移到WEB的几点基本要求?
实现现存客户/服务器系统大部分的功能?
新的基于WEB的系统必需实现现存客户/服务器系统的大部分功能。答应有少量的功能不能在WEB上实现，但是当许多原系统的功能没有实现时，往WEB的迁移是无意义的。?
现存客户/服务器系统变最小化?
迁移过程中必需的变动员不需大量修改现存的代码。现存的客户和服务器应能照常工作。迁移过程中修改代码不可能时(比如商品化软件的原代码是不可得的)，可以建立中间件以应付不能修改现存的代码。?
不修改HTTP或HTML标准?
不能修改HTTP或HTML的标准。标准的HTTP请求被创建的中间件处理，并将请求路由到现存的应用服务器上。
使用流行的浏览器软件?
为保证系统的可用性，使用流行的浏览器软件。?
3?体系结构?
这是一种三层结构模式的客户/服务器应用系统。为了将系统连接到WEB上，在基于WEB客户和现存应用服务器之间建立HTTP代理(图1)。HTTP代理设计成数据翻译为HTTP请求，并将该请求转换成传统系统的协议请求。??
HTTP代理(或中间件)可在原服务器同一台计算机上运行，也可运行、连接到服务器在LAN中的任一台计算机上。中间件不必与WEB浏览器运行在同一台计算机上，一个中间件转换系统中多个WEB浏览器用户的请求。这解决了每个基于WEB用户有一个中间件的资源问题。?
有多种创建中间件的方法：?
从零开始建立中间件?
当WEB界面加入到没有原代码的系统时(也许是商品化的软件包)、或者修改任何一小段代码都很困难时，只有从零开始建立中间件。?
基于现存系统客户的中间件?
现存的客户可改为其行为如同一个HTTP代理服务器。当新HTTP代理的代码部分收到来自WEB浏览器客户的请求时，它简单地将请求送入服务器。当客户端代码较简单时，此法只需修改少量的现存代码。?
直接修改服务器代码?
在某些情况下，为了直接与WEB浏览器交互可以修改服务器代码。这取决于服务器是否依靠于现存客户“状态”，即在多个请求之间记忆应用的状态。在这些情况下，修改系统客户代码比修改服务器代码要复杂得多。?
同时修改客户和服务器的代码?
建立在现存系统客户的中间件和将服务器修改成与新客户交互时有不同的行为，也许是可行的方法。服务器期望系统的每个客户只表现为一个用户，因为在我们的体系结构中，一个中间件响应多个基于WEB的系统用户。为了建立一对多的映射，有必要修改服务器代码或修改在服务器与新“中间件客户”之间的协议。?
有几个因素使问题复杂化。首先，HTTP协议是无状态的，然而许多现存的客户/服务器系统使用的是有状态的协议。按照现在HTTP协议说明，WEB浏览器连接到服务器、发出请求并接收响应，随后关闭连接。在多数客户/服务器系统中的特定客户打开与服务器的一个连接，并在整个会话期间保持这个连接。为了在基于WEB客户端模拟这种功能，必需：?
为基于WEB的客户维护状态信息?
中间件可以把称为“magic cookies”嵌入HTML送往WEB浏览器。cookies使中间件辨别每个独立的浏览器，保存每个浏览器的状态信息。这种方法有一个问题，即无法确定系统WEB浏览器客户是否崩溃或被重新启动。此时，中间件要为崩溃的客户放弃事物，执行中断连接或执行容错协议。由于无法确定客户是否崩溃，中间件必需使用一些确定执行信息的专横的方法，可以根据闲置时间或其它一些不完美的方法。?
将状态信息嵌入送往WEB客户的HTML中，在请求之间不保留状态信息?
此法辨别WEB客户magiccookie方法的一个扩展。Magiccookie在客户端产生并随浏览器用户对中间件执行的每个命令而变，每个对中间件的请求包含了直接嵌入的WEB客户请求状态。中间件能够从前一个请求中确定用户已经成功地完成。?
另一个是问题复杂化的因素是中间件要直接处理一些HTML文档。中间件处理的URL有可能不转换到现存的服务器的命令。例如URL提供了系统HTML用户的界面或为系统的新用户提供帮助信息。为此，中间件维护一个小型的HTML文档树。当中间件接收来自WEB客户的请求，必需确定路由到服务器还是该请求用中间件自己文档树中的文档作应答。?
此外，更为严重的问题是如何处理原来客户端为服务器处理的非凡应用功能。包括调用外部工具和使用平台相关的类库、设备或操作系统的访问服务。只使用HTML的WEB浏览器客户一般不能模拟现存系统特定应用功能。有几个解决此问题的方法：?
中间件模拟?
中间件可以为WEB浏览器客户执行一些客户的任务。在以批方式调用外部工具的情况下，只是做简单的输入和汇总输出工作，此方法是可行的。因为批工具要求在运行时不被中断。当中间件和基于WEB客户都运行在X display下时，这同样有可能调用交互工具的XWindows。中间件启动同一计算机上的工具，并在用户的X display上显示该工具的界面。?
新的MIME类型和MIME处理程序?
这里讨论的是必须在WEB客户计算机上使用外部工具和系统服务。方法是建立平台有关的MIME帮助程序，该程序响应由中间件下送到浏览器的新MIME类型。例如，可使所有WEB浏览器在收到一个“X-Foobar”MIME信息时运行一个“Foobar”程序。因为每个HTTP响应包含了一个MIME说明，中间件只是简单地通知浏览器应答是“X-Foobar”类型，浏览器就会运行“Foobar”程序。?
Mosaic CGI和Netscape PlugIn API?
浏览器生产厂商提供的不同API编写的浏览器相关的代码，较好地实现WEB浏览器与帮助程序之间的集成。例如，假如所有的基于WEB用户都使用Netscape Navigator作为他们的浏览器，设计者就能建立处理由中间件发送的、新“X-Foobar”类型的Netscape PlugIn。编好的API代码直接在浏览器窗口中运行，保持了客户/服务器系统与WEB浏览器之间的无缝集成。?
Java applets?
Java applets能够实现与上述浏览器相关API相类似的扩展。最重要的优点是浏览器和平台的无关性，可灵活地建立各种扩展。?
四、基于JAVA数据库访问的方法?
对于WEB，使用APPLET的真正潜力在于JAVA APPLET的可移植性可连接性。JAVA APPLET运行在支持JAVA的浏览器中，象本身就是一个浏览器。在JAVA中建立数据库客户最轻易的方法是使用厂商提供类库(假定这些类库由C语言编写)的包装类，编译这些类库作为动态连接库。然而，出于安全的考虑，只有独立的JAVA程序才能连接动态连接库。当JAVA APPLET在WEB浏览器中运行时是不准访问本地文件系统。APPLET访问远程服务器的唯一路径是通过JAVA的SOCKET接口。?
一般来讲，有二种构造作为远程数据库服务器客户的JAVA APPLET。一个是使用所有功能都在JAVA中实现的二层结构(图2)。另一个是使用三层结构，其中独立的JAVA服务器用作为路由器在APPLET和远程数据库服务器之间传递请求和响应信息(图3)。前者需要较高的编程能力，原因是JAVA客户必须在厂商特定类库的协议层次上实现。后者较易实现，原因是借助JAVA客户类库函数，可以建立独立的JAVA应用程序?路由服务器。当访问数据库服务器时，路由服务器作为通信服务器，与JAVA APPLET连接用用户定义的协议，在另一端是原本的客户/服务器协议。?
目前用二层结构完成的数据库客户包括：MsqlJava,MiniSQL。客户/服务结构用三层结构包括：Weblogic dbKorta/T3和由Vincent Engineering开发的OCI/JAVA Gateway。为访问包括Oracle,Sybase和Informix在内的关系数据库，前者提供了用JAVA开发客户和服务器的许多类库。后者利用(OCI(Oracle Call Interface)连接oracle数据库。?
五、结论
在本文中，我们展示了应用在WEB上的方法。与基于CGI数据库应用的方法比较，基于中间件的方法具有更多的优点，基于JAVA的方法更具灵活性、可伸缩性和强壮性。它提供了一条构造以WEB应用为目标的、使用WEB浏览器访问传统客户/服务器应用的途径。
