1.2.2 客户端/服务器（两层）体系结构

作者: Kevin Mukhar Chris Zelenak James L.Weaver Jim Cru. 出处:机械工业出版社　 (  ) 砖  (  ) 好  评论 ( ) 条 　进入论坛

更新时间：2007-05-14 10:37
关 键 词：客户端  服务器（两层）体系  结构  指南  Java EE 5 开发指南
阅读提示：《Java EE 5 开发指南》第1.2.2节“客户端/服务器（两层）体系结构”主要介绍客户端/服务器（两层）体系结构的一些具体问题和操作， 供大家参考！

有一些应用软件可能用到了数据库服务器，并且通过发送SQL命令到数据库服务器存取数据。这种情况下，数据库是在应用程序之外运行的另一个进程，甚至它和应用程序不在同一台机器上运行。如图1ˉ2所示，数据访问的逻辑组件是和应用程序的其他逻辑分开的。采用这种方法的好处是把数据集中起来，允许多个用户同时访问同一个数据库，而且采用集中的数据库服务器还可以分担一些应用软件的运行负载。这种体系结构通常称为“客户端/服务器”结构，无论服务器提供的是数据访问或者其他什么服务，只要存在客户端和服务器的通信，都属于这一体系结构范畴。

图1ˉ2 在客户端/服务器体系结构中，一个应用程序客户端从另一个进程获取数据服务来完成它的工作

图1ˉ3 分层图所示为客户端/服务器结构

直观地把职责抽象划分为层是有意义的。图1ˉ3所示为两层客户端/服务器软件体系结构。两层体系结构的缺点之一是把管理数据，以及使用与数据相关的应用逻辑都集中于应用程序自身中。当多个应用程序共享一个数据库时，问题就出现了。例如，一个数据库存储了客户的信息，包括订单、开发票、出货和常用的客户资料管理。这样每一个应用程序都需要建立一套用于操作和访问客户数据的逻辑和规则。例如，公司内有一个规定，对逾期90天未付款的账号要进行信用冻结。在每个应用程序中，建立这个规则来访问客户数据似乎是非常简单的，但是当策略变为60天进行信用冻结时，那么相应修改每个应用程序将会很麻烦。

我们可以通过封装业务规则建立可复用的库来试图解决这个问题。当这些规则发生变化时，可以只替换掉这些库，然后重新编译应用程序，再重新发布到那些正在运行这些应用的计算机上。但是，这个方法也会带来一些基本的问题。首先，这个方法假定了所有这些应用都是用同一种语言创建的，并且在同一个平台上运行，而且至少这个类库和平台是有相关性的。第二，应用程序需要用新的库重新编译或者重新汇编。另外，即使在不需要重新编译，只需要替换库就可以的情况下，要确保每个应用程序同时都安装的是正确的库（也就是不同的应用程序同时不能产生业务规则的冲突），也是一件非常痛苦的事情。

为了摆脱这种困境，合理地把业务规则从正在运行应用程序的计算机上分离出来，可以另外设一台业务规则服务器，这样每次更新业务规则也只需要实施一次，而不需要更新每台运行着这个应用程序的计算机。

回书目   上一节   下一节

滚动新闻　术语词典　问题悬赏

我也说两句