第四讲 常用的体系结构模式 刘玮 2017/2/26

经典模式的横向比较 模式名称 组件 连接器 应用 管道/过滤器 过滤器 管道 Unix Shell、编译器 分层 用户系统、基本工具、核心层 请求服务 操作系统、网络体系结构 数据抽象 对象 过程调用 面向对象的体系结构 仓库 中心数据、 外围组件 操作 面向知识的体系结构 C2 软构件 软构件之间通讯协议 面向构件的体系结构 事件的隐式调用 类 事件 界面编辑监听事件

大纲 目前常用的体系结构模式 客户端/服务器模式 三层C/S模式 浏览器/服务器模式 C/S与B/S的混合模式 系统案例背景介绍

客户端/服务器模式体系结构 C/S软件体系结构是基于资源不对等，且为实现共享而提出来的 一种胖客户机，瘦服务器的体系结构 服务器的主要任务 数据库安全性的要求； 数据库访问并发性的控制； 数据库的备份与恢复。 客户应用程序 提供用户与数据库交互的界面； 向数据库服务器提交用户请求并接收来自数据库服务器的信息；

优点和缺点 优点 缺点 具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。 系统中的功能组件充分隔离 开发成本较高 客户应用程序的开发集中于数据的显示和分析 数据库服务器的开发则集中于数据的管理 缺点 开发成本较高 客户端程序设计复杂 用户界面风格不一，使用繁杂，不利于推广使用 软件移植困难 软件维护和升级困难 2.系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性。 3.不必在每一个新的应用程序中都要对一个DBMS进行编码。

大纲 目前常用的体系结构模式 客户端/服务器模式 三层C/S模式 浏览器/服务器模式 C/S与B/S的混合模式 系统案例背景介绍

三层C/S模式体系结构对比 不仅数据可以共享，操作（应用逻辑）也能共享 增加了一个应用服务器，将应用逻辑驻留在应用服务器上， 在客户机上只留下表示层，称为“瘦客户端” 分离应用逻辑 三层C/S 两层C/S

三层C/S模式应用功能分层 存取数据库数据 业务处理逻辑 数据从表示层和 数据层获得 接受、检查输入 显示应用输出

三层C/S模式三种设计 服务器之间传送数据 灵活性高 系统规模越大优点越显著 程序可维护性好 负荷太重，业务处理所需数据从服务器到客户机

优点 在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。 应用的各层可以并行开发，可以选择各自最适合的开发语言。 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。

问题 三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。

大纲 目前常用的体系结构模式 客户端/服务器模式 三层C/S模式 浏览器/服务器模式 C/S与B/S的混合模式 系统案例背景介绍

浏览器/服务器（B/S）模式 B／S结构与C／S结构的分析比较 特征 B／S C／S 硬件环境不同 广域网 局域网 结构 三层 两层或三层 处理模式 网络协议软件、浏览器 客户端软件 构件重用 构件相对独立、重用性高 整体、重用性低 系统维护 系统的无缝升级 整体考察并处理 安全的要求 Intemet的开放性协议（ TCP／IP） 局域网 、固定的用户群=>高度机密的信息系统 速度 慢 快、处理大量数据 交互性 有限 强

大纲 目前常用的体系结构模式 客户端/服务器模式 三层C/S模式 浏览器/服务器模式 C/S与B/S的混合模式 系统案例背景介绍

C/S与B/S的混合模式 内部用户 外部用户

案例：武汉市制造业信息化软构件库管理平台 目前，软件开发正处于软件生产方式变革和软件产业结构分工调整的重要时期 在新形势下，软件供应商面临着一系列的挑战 如何应用软件开发新技术（如基于构件的软件开发方法）来提高开发效率、缩短开发周期、降低开发成本 软件产业化所需软件基础设施（易重用、可互操作的软构件库）的建设 软构件库作为影响整个软件产业发展的关键共性软件基础设施应该优先、着重发展（国务院下发的第47号文件） 进一步强调加强软件资源库体系建设（“十一五”软件产业发展规划）

平台与同类产品比较 上海构件库 北大青鸟构件库 武汉构件库平台 构件分类方法 功能分类 构件刻面分类 构件属性本体分类 国际标准 无 ISO/IEC 19763 ；与其它国际标准如UDDI、ISO11179 (MDR)和 ebXML/OASIS等具有互操作性 查询方式 Web查询 Client/Server查询 Client/Server查询，SOAP编程接口 运行平台 ASP+SQL Server VC+Oracle8i Tomcat + PostgreSQL 发布方式 自由发布 局域网授权用户发布 因特网/局域网授权用户发布 存贮方式 基于文件名的存储 关系型数据库存储 基于本体元模型的数据库存储 构件数目 3000多个 1000多个 1200多个 分类方法 基于基本属性的分类方法，如按照操作系统和构件模型来分类 基于刻面属性的分类方法 基于软构件属性本体的分类方法，可以对复杂属性信息进行组合查询、精确查询。分类方式可以动态添加与修改，具有可扩充、互操作性特点。 查询方法 关键字查询，如按照构件类型、构件功能、构件操作系统、构件使用容器和构件应用环境来查询 按软构件刻面属性进行查询，无动态属性组合查询功能 按软构件属性本体进行语义查询，如分类查询、推理查询、关键字查询、组合查询。可以通过自定义本体分类体系来涵盖上海构件库的查询方式。 服务技术特点 Web服务 C/S服务 语义Web服务

软构件库平台体系结构 如图所示,平台由客户层,互联网,服务器层和存储层构成; 平台功能流程如图,首先通过Web服务接口获取用户需要,根据软件属性本体和领域本体优化查询需求,进而在构件库精确地找到相应构件.

大纲 目前常用的体系结构模式 客户端/服务器模式 三层C/S模式 浏览器/服务器模式 C/S与B/S的混合模式 系统案例背景介绍

案例系统介绍 武汉市旅游出行系统 随着交通建设的快速发展，交通网络日益完善，交通出行频率明显加快。利用现代计算机技术和通讯技术，建立一个先进公众出行服务系统，能够为公众提供路况、交通量、路径查询、气象等出行服务信息。武汉市旅游出行信息服务平台以互联网为载体，整合武汉市的“景区、导游、旅行社、交通、宾馆、休闲、购物”等旅游服务要素，建立的标准旅游信息数据库，在此基础上根据武汉旅游的特点，形成人网交互的服务平台。

系统模块 系统拟包括订房服务、订票服务、公交出行、交通天气查询和旅游行程推荐五个主要模块。

订房服务模块 根据区域、与目标的距离、星级、价格等因素查询酒店； 订单查询：可依照订房者姓名、订单编号、下订单日期、住房时间等即时查阅网络订房情形； 客户资料库：订单自动完整保存，可依照订房者姓名、订单编号、下订单日期、住房时间查询以前的订单； 设定相关人员使用管理系统的权限。

订票服务模块 根据旅客提出的终点站名输入下列信息：车次、车站名； 根据客户提出的要求查询该车次票额的情况，若尚有余票，则为客户办理订票手续，输出座位号；若已满员或余票额少于订票额，则需重新查询客户要求，若需要可登记排队候补。 根据客户提供的情况（车次、时间、座位号）为客户办理退票手续，然后查询该车次是否有人排队候补，首先询问排在第一的客户，若所退票额能满足他的要求，则为他办理订票手续，否则依次询问其他排队候补的客户。

公交出行模块 全面考虑武汉公交汽车、轮渡、轻轨等，根据出发地和目的地，推荐搭乘线路； 根据用户的不同需求，如经济出行、舒适度、观光线路，推荐搭乘线路； 计算出行费用； IC卡充值点查询。

交通天气查询模块 提供气象信息发布功能； 可以滚动显示武汉市周边各高速公路路段的气象信息； 天气信息对出行的影响。

本讲任务 1.确认各小组负责的系统模块； 2.参照教材“办公自动化系统”的需求及产品特性总体描述，描述系统模块的相关内容，行程功能模块分析图（见P80）； 3.分析该体统采取哪一种体系结构模式，绘制体系结构图。

面向服务体系架构 服务提供者： 服务使用者： 服务注册中心： 一个可通过网络寻址的实体，它接受和执行来自使用者的请求。 它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。 服务使用者： 一个应用程序、一个软件模块或需要一个服务的另一个服务。 它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。 服务使用者根据接口契约来执行服务。 服务注册中心： 服务发现的支持者； 它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。

面向服务体系架构 面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种（或多种）。 面向服务的体系结构中的操作包括： 发布(Publish)：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。 发现(Find)：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。 绑定(Bind)和调用(invoke)：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。