随着现代企业的分支机构越来越多，应用系统的负载和数据量也日趋庞大。应用系统经过了主机/终端和客户/服务器结构的历程，现在正由客户/服务器方式转向三层结构方式。所谓三层结构是指在客户/服务器两层结构基础上加入中间层，中间层叫应用服务器或中间件，结构如图1所示。
图1 应用系统三层结构
CORBA和EJB在技术上日趋成熟，三层结构的技术标准也日益完善，与客户/服务器方式相比，三层结构有很多优点：
(1) 可实现应用级和数据库级的全面分布。应用分为用户界面和业务逻辑，业务逻辑以组件的形式分布在应用服务器上。服务器根据需要分布在整个网络的任何节点上，尽管整个应用在物理上是分布式的，但逻辑上却是一个整体。当前的分布式数据库技术已经非常成熟，能保证分布数据的完整性和一致性。
(2) 实现大用户量、大吞吐量下的负载平衡。随着Internet的迅速发展，在Web上需要实现很多关键业务（如网上购物、订票等），这些应用的最大特点是并发用户量大，三层结构比以前的结构更能承担大业务量。三层结构将应用纵向均匀分布在客户端、应用服务器和数据库服务器上，横向分布在多个应用服务器和数据库服务器上，应用的分布实现了负载的平衡。因此，在大用户量、大吞吐量情况下，仍能迅速响应每个客户端的需求。
(3) 如果使用Java技术，可实现应用的跨平台。Java是一种跨平台的语言，不论是在客户端，还是在应用服务器上使用Java技术，都可使应用在一个操作系统上编写，并能无缝移植到其他操作系统上。
(4) 能实现组件级的开发。应用服务器的组件既能用于传统的客户端，也能应用于Web，提高了代码的重用率。
(5)中间层的存在，大大提高了数据的安全性。Web或其他客户端不直接访问数据库，从而加强了数据的安全性。
基于以上优点，分布式的体系结构目前已被众多的应用系统所采用。
总体结构和技术平台
1. 总体结构
为了更好地说明应用服务器的功能以及应用和数据的分布，需要用一个实例描述，因此我们构造了一个虚拟的应用——分布式呼叫中心标准管理系统。与传统的呼叫中心不同，这是一个全国范围的呼叫中心，数据、应用和座席需要分布在全国各个节点。各节点的受理员可受理全国各地的客户，并且能访问全网内任何节点的数据，其系统结构如图2所示。
图2 分布式呼叫中心系统结构
可以看出：我们把数据库建在省受理中心（内部数据库）或其他业务部门（外部数据库），根据各地的需求，一个应用服务器可对应一个或多个数据库服务器。应用服务器细分为业务逻辑和数据逻辑，业务逻辑响应客户端的请求，从客户端获得参数，返回结果，业务逻辑的组件将整个业务封装，业务逻辑调用数据逻辑，实现对不同地点异构数据库的访问。
受理席可以是中心内部的受理席或远程外包受理席；客户端为普通Windows应用，浏览器为动态HTML（CGI、ASP、JSP）和Java Applet。它们都是瘦客户端，仅有用户界面，可访问应用服务器的业务逻辑; 业务可由插件的方式改变，这些都可通过应用服务器的业务逻辑改变来实现。 整个系统网络连接由TCP/IP上层协议CORBA、Http、Socket实现。
2. 技术平台
各个关键模块都采用了当前流行和通用的技术平台。中间件采用EJB(Enterprise Java Beans)技术实现分布式应用技术; Java使应用具有跨平台特性，即在一个操作系统平台上编写的程序移植到其他操作系统平台上时，不用修改源代码。
利用中间件中的数据逻辑，使应用无需改变客户端即可访问其他节点的数据。应用分布式数据库可实现整个系统数据的完整性和一致性。
客户端可用普通Windows应用、JSP/ASP/CGI、Java等实现，通过IIOP协议访问应用服务器的业务逻辑。异地的受理席之间语音传输用VoIP实现。
分布带来的问题和解决办法
1. 应用和数据分布产生的问题
(1) 应用分布产生的问题
由于整个网络内的客户端和应用服务器众多，有以下3个问题需要解决：客户端该如何确定请求哪个应用服务器；客户端如何调用远程应用服务器的组件; 各应用服务器之间如何协调工作。
(2) 数据分布产生的问题
由于客户端的数据可能同时取自多个点，所以任何一个客户端都可能要同时访问异地数据库，并且需要访问IP地址经常变化的数据库。因此，若需要新增一个节点时，需考虑系统的应用和数据如何划分，客户端如何使正在处理中的业务实现平稳过渡。
2. 解决的方法
(1) 应用分布问题的解决
应用分布问题可通过设计客户端和应用服务器的访问规则来解决。访问应遵循以下规则: 每一客户端有且只有一个应用服务器为之服务，一般是该客户端本地的应用服务器；客户端需要访问远程服务器时应该通过为之服务的应用服务器; 每个应用服务器都运行所有业务逻辑组件和它访问的数据库的数据逻辑组件，在业务量大的中心可做群集（Cluster）。
(2) 数据分布问题的解决
解决数据分布的问题稍为复杂，首先要确定数据存放原则和数据访问规则。
数据存放的原则：采用分布式数据库，对业务性数据采取就近分布存储的策略，而对于控制性数据则利用事务日志来保持各点数据的一致性。系统应用同时支持数据的远程访问，支持大吞吐量的联机事务处理，支持灾难恢复。 数据访问的规则: 每个客户端有且只有一个连接的应用服务器，每一数据库有且只有一个连接的应用服务器。而每个应用服务器可有多个客户端，也可连接多个数据库服务器。通过建立多个连接缓存的方法，实现不同节点和异构数据库的访问。如图3所示。
图3 数据访问
为了实现远程的访问，需要在每一节点有应用服务器与数据库对照表和远程调用的方法。应用服务器与数据库对照表记录的是被使用的应用服务器和数据库连接缓存的关系。
对每一个客户端访问数据的请求，由远程调用方法确定客户端调用的数据是本地的还是远程的。若是本地，可通过本地应用服务器的数据逻辑直接访问; 若为远程，查询对照表确定调用哪个远程应用服务器，再通过本地应用服务器访问该远程服务器，实现数据访问。远程数据访问过程如图4所示。
图4 远程数据访问过程
在图4中，访问顺序为：
A点客户端→A点应用服务器→B点应用服务器→B点数据库。这一调用程序说明了，客户端是如何同时通过应用服务器访问本地和远程数据库。
当增减应用服务器节点时，需要增减对照表记录，各节点对照表的一致性通过数据库日志来保持。当增加数据库节点时，将旧数据库中的数据根据数据存放原则转入新数据库(无论是处理完成或正在处理的的业务数据都转入)，在旧数据库中做数据移动的日志，同时修改应用服务器和数据库对照表。
维护工作量的评估
1. 新增节点工作量的评估
新增节点可分为3个层次：只需客户端、需应用服务器和需数据库服务器。
只需客户端: 只需安装客户端软件，并将其连接到应用服务器上。
需应用服务器: 需在新节点安装应用服务器，同时需修改各应用服务器和数据库对照表。
需数据库服务器: 需在新节点安装数据库服务器，将其连接到应用服务器，增加应用服务器的数据库连接缓存; 还需分离原节点中的数据到新节点，同时记录转移日志。
2. 平台移植工作量评估
操作系统平台的移植: 支持所有主流Unix平台和NT平台，移植到不同平台上。由于代码是由Java编写，所以改变操作系统平台时无需改变代码。
数据库平台：支持ODBC、JDBC和其他专用数据库专用接口。对以上接口的支持，保证了对主流数据库平台的支持。数据库平台的改变只需改变数据逻辑，而无需更改业务逻辑和客户端。
3. 客户端或应用服务器代码改变
应用服务器数量有限，客户端却数量众多，为减少工作量，应尽可能将修改工作放在应用服务器端。
在三层结构中，客户端为瘦客户端，只有用户界面。因此只有用户界面发生变化时，才需改变客户端; 若是业务发生变化时，则只需改变应用服务器的组件。
4. 安装和日常管理工作量
安装: 对于只进行业务处理的部门和只需受理客户端软件的部门，可从统一网址下载软件，安装即可使用。对于需要应用服务器和数据库服务器的部门，需技术人员现场安装。
维护: 对于应用服务器组件的升级，技术人员可远程操作。客户端软件的升级需用户从网上下载，重新安装。
摘自计算机世界网
