三层体系结构的电信网监测系统

随着计算机技术，IntenetIntranet 的不断发展及企业对计算 七号信令属于公共信道信令，其信令系统独立于话音系统，信令消息完全数字化，采 用数据包方式发送数据。信令链路具有握手，检验，差错控制，拥塞控制，冗余备份等能 力。类似 TCP/IP 协议的，所不同的是移动通信网中的信令是共路信令，即信令为专用通道， 与语音电路是分离的。由于移动通信网中的呼叫流程的所有控制信息都是通过信令来传输 的，通过对信令网的监测，可以实时监测维护七号信令网，对网络的故障处理和业务分析 提供全方位现代化的解决方案。 （2）及早发现、预防威胁网络的故障； 相比信令仪，信令监测系统最大的优势在于其监测是不间断的，在有用户投诉时可以 方便的查询相关时段的记录，因用户投诉必然滞后于故障；而信令仪等仪器只能在故障出 现后再使用，监测时间也远不能与计算机系统相比，而且很多不确定故障在短时间内很难 重现。 1、 传统两层 C/S 结构的缺点 传统的两层客户/服务器模式比较适合于小规模、用户较少、单一数据库且在安全、 快速的网络环境下 (例如局域网 )运行 。但是，随着应用系统的规模不断扩大 ,复杂性越 来越高在多用户、多数据库且非安全的网络环境下(例如:Internet) ,这种两层结构的应用模 型将无法适应 。而且传统的两层结构还存在以下缺陷： (1)它是单一服务器且以局域网为中心的 ,所以难以扩展至大型企业广域网或 Intranet； (2)受限于供应商，程序的升级维护必须由供应商重新开发扩展； (3)软、硬件的组合及集成能力有限；在软件上呈现出胖客户端，用户必须在客户 端安装特定的客户端应用程序，而且企业的业务逻辑都写在客户端应用程序中，程序维护 困难，程序升级需要每个客户端都要安装新的客户端应用程序，同时，对于程序开发商来 说，程序模块的重用性差，各个模块相对独立； (4)C/S 模式很难管理大量的客户机。 基于以上原因，传统的 C/S 模式已经不能适应发展的需要，随着网络技术的普及 和用户需求的进一步提高，三层 WEB 模式应运而生。 2、 三层 WEB 结构的优点 三层客户/服务器模式 (以下简称三层模式 )在两层模式的基础上，增加了新的一 级。这种模式在逻辑上将应用功能分为三层：客户显示层、业务逻辑层、数据层。客户显 示层是为客户提供应用服务的图形界面，有助于用户理解和高效的定位应用服务。业务逻 辑层位于显示层和数据层之间，专门为实现企业的业务逻辑提供了一个明确的层次，在这 个层次封装了与系统关联的应用模型，并把用户表示层和数据库代码分开。这个层次提供 客户应用程序和数据服务之间的联系，主要功能是执行应用策略和封装应用模式，并将封 装的模式呈现给客户应用程序。数据层是三层模式中最底层，他用来定义、维护、访问和 更新数据并管理和满足应用服务对数据的请求。 三层模式的主要优点为 ： 良好的灵活性和可扩展性。对于环境和应用条件经常变动的情况，只要对应用 层实施相应的改变，就能够达到目的。 可共享性。单个应用服务器可以为处于不同平台的客户应用程序提供服务，在 很大程度上节省了开发时间和资金投入； 较好的安全性。在这种结构中，客户应用程序不能直接访问数据，应用服务器 不仅可控制哪些数据被改变和被访问，而且还可控制数据的改变和访问方式。 增强了企业对象的重复可用性。 “企业对象”是指封装了企业逻辑程序代码，能 够执行特定功能的对象。随着组件技术的发展，这种可重用的组件模式越来越为软件开发 所接受。 三层模式成为真正意义上的“瘦客户端” ，从而具备了很高的稳定性、延展性和 执行校率。 三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的 容错能力和负载平衡能力。 C/S 与 B/S 混合软件体系结构的优点是外部用户不直接访问数据库服务器，能保证 企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快。 C/S 与 B/S 混合软件体系结构的缺点是企业外部用户修改和维护数据时，速度较 慢，较烦琐，数据的动态交互性不强。 成本的不断要求，计算机应用系统由集中式向分布式计算发展。软件的体 系结构也从 CS 模式转向了多层应用体系结构。这种结构必然需要中间件 支持，而面向对象分析方法是当今软件开发的主要方法，所以，分布式对 象中间件成为一个主要的发展方向。运用这种技术，开发者可以将运行在 网络中的分布对象集成为分布式应用，面向对象分析方法中的继承和复用 技术有助于软件复用和控制系统的改动，降低维护的费用，使得系统的改 动可以快速准确的予以实现。 为了使开发者更专注于业务逻辑的实现，在分布式对象中间件的基础 上又实现了一些分布式应用所必需的服务：目录管理、安全管理、分布式 事务管理等。这就是所谓的“应用服务器” ，它极大方便了多层分布式应用 系统的开发，促进了中间件应用的发展。因而，也使得中间件技术受到人 们广泛的关注，对软件业产生了巨大的影响。基于中间件的多层分布式体 系结构，符合软件工程的化整为零的原则，同时满足方法论的要求。 1 软件构件和中间件 一个构件是一个系统中最重要的、基本上独立的、可替换的部分，在 已定义好的软件体系中执行清楚的功能，适合提供一系列接口的物理实现。 中间件是基于构件技术，处于两种或多种软件之间 (通常是在应用程 序和操作系统、网络操作系统或数据库管理系统之间)传递信息的软件；它 使用户能使用一种脚本语言来选择和连接已有的服务，从而生成简单程序 的软件开发工具。中间件涉及软件的各个领域，是供公用应用程序编程接 口的软件。中间件在操作系统、网络和数据库之上，应用软件的下层，总 的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵 活、高效地开发和集成复杂的应用软件。 中间件应具有以下的特点： (1)中间件的平台无关性。中间件是用来解决应用之间的互连性，它提 供了一个公共的应用通信机制和数据接口，以屏蔽各类通信协议之间的差 异和实现通信协议间尽可能地完全映射。除此之外，还用来控制数据传输 过程中的流量、加密、并发等问题。数据接口用来实现分布式环境中异构 系统之间数据的共享，从而做到平台无关性。 (2)中间件具有良好的可靠性。良好的可靠性是中间件技术开始以来就 追求的目标，随着技术标准的形成，中间件已经可以提供可靠的稳定性。 (3)中间件具有较高的效率。中间件的工作机制为：当客户端的应用程 序需要调用分布式环境下某个服务器的数据或服务时，中间件系统负责接 收客户端的请求，查找数据源或服务，并建立相应服务或数据同相应服务 器之间的对应关系。完成连接后，还要负责结果的返回。因此，中间件实 现了客户和服务器透明性，所以要求必须减少请求响应时间。因此中间件 提供的对服务或数据的查询效率是比较高的。 中间件技术的应用非常广泛。目前主要的分布式中间件技术标准有： Microsoft 的以 COMDCOM 为基础的 COM+，Java 的 JavaBeans 和 EJB， OMG 组织的 CORBA 等。可以说，计算机界很久以前就有用分布式构件集 成处于分布式环境中的各种应用系统的想法，但一直未能真正实现，其中 的一个主要原因是分布式中间件技术标准的缺乏。正是由于出现了以上较 为成熟的标准，才使得分布式系统通过分布式中间件开发构造由梦想走向 现实。 2 基于中间件的分布式系统开发过程 基于中间件的分布式系统开发过程隶属于基于构件的软件工程 (CBSE)范畴。 CBSE(Component-Based Software Engineering)是指用装配可重用 软件构件的方法来构造应用程序。CBSE 不仅仅是简单地应用对象要求代 理建立一个代码库，或从 Internet 上下载相关控件，还需要策略而系统地进 行全局考虑和规划。它包含了系统分析、构造、维护和扩展等各个方面。 它具有即插即用，以接口为核心及标准化等特点，CBSE 开发过程如图 1 所示。 基于中间件的分布式系统开发过程在需求分析等各个过程中有其自身 的特点，本文就这些方面予以探讨。 2.1 基于中间件的分布式系统开发过程可行性研究 相对于传统软件工程早期的可行性研究，增加了对软件工作的分布式 环境的研究、软件工作平台的配置研究以及所涉及的原有系统的改造问题， 并且逐步过渡到以体系结构为指南的可行性研究，这与 CBSE 的特点是分 不开的。 20 世纪 80 年代以来，大部分应用系统采用的是两层的 CS 模式。其 中，一个客户机负责数据的表示、采集和处理工作，而服务器负责数据的 集中存储。这种“胖客户”的 CS 体系结构只能工作在有限的环境中，但是， 当客户数目过多或未知时，该结构就无能为力了。同时，应用程序庞大， 应用逻辑无法复用。除此之外，系统修改要将所有的程序版本发给每一个 客户机，成本较高。 于是，从“胖客户”CS 结构出发，人们把部分“业务逻辑 ”转移到数据 库服务器上进行，演变成一种“胖服务器”的 CS 结构。但是，该体系结构 性能仍不能满足分布式应用程序的要求，应用逻辑的复用度也很有限。 由此可以看出，这种 CS 结构当业务规则很复杂时，系统很难管理， 业务规则的更改也将变得异常困难，甚至不得不重新开发，这是该类体系 结构不能适应大型分布式应用的主要原因。因此，人们又在客户端和服务 器中间抽象出应用逻辑层，组成三层(多层) 分布式体系结构，将企业的业 务过程实现集中在该层中。所谓的多层应用体系结构，就是将在客户机和 服务器之间增加某些应用逻辑层，将业务规则封装在这些层中。它们可能 分布在一个或多个物理服务器上，甚至客户机，使得业务规则的改变比较 容易实现。这种多层的体系结构必然要利用中间件技术，将企业的业务规 则分别实现于各个组件中，数据和实现细节予以安全隐藏，仅展示其提供 的服务接口。该体系结构如图 2 所示。 分布式系统的可行性研究主要侧重于某一种体系结构能否满足于企业 需求，这是不同于传统软件工程的。对于开发分布式应用系统而言，就是 考虑三层(多层)应用体系结构能否满足分布式需求，技术上是否可行。实 际上，也是选择分布式中间件的过程(图 3)。 2.2 基于中间件的分布式系统开发过程需求分析 对于基于中间件的分布式应用，需求分析和软件设计阶段由原来的从 头开发产品变成了体系结构的选择、中间件的选择和开发工具的选择。系 统分析员必须在系统需求和使用的分布式中间件之间进行权衡，并且作出 折中的考虑。除此之外，同时还要在体系结构和接口之间进行权衡。 一般而言，分布式应用采用面向对象分析方法。因为该方法已被软件 工程界公认为是具有发展潜力的重要的需求分析方法。而且，目前分布式 中间件技术基本上也是分布式技术与面向对象分析设计相互作用的产物。 面向对象分析是分布式系统开发过程中的问题定义阶段，输出的是对问题 域清晰和精确的定义。传统软件工程的系统分析产生一组面向过程的文档， 用于定义目标系统的功能。面向对象分析主要产生一种描述系统功能及问 题域特征的综合文档。后者在更大的问题域中考虑问题，是对现实问题更 高层的抽象。因此，在分布式环境下分析其应用，就是将问题抽象为一组 相互作用的实体和各实体之间的关系。从而，系统分析将产生一个能够控 制的方式运行的模型。 (1)识别分布式对象。即从问题抽象出分布式系统中包含的组件，遵循 如下原则：使用分布式问题域中单个名词或名词短语。分布式对象名 称必须简洁、精确，而且易于理解。尽量使用用户熟悉的标准词汇。 尽量使组件的复用度较高。 最后，可以提取类似组件间相同点，进行“泛化” 。泛化后还要寻找类 似组件间差异，即“特化” ，以提高软件复用度。需要指出的是，对分布式 对象的识别是一个主观的过程，因人而异，会产生不同的结果。但是，在 对象的物理分布上，要遵循简洁、有效和复用的原则，并不是所有的应用 逻辑组件都分布在服务器上。有时，为了更好地解决问题，一些只针对极 少数客户机的逻辑组件也可能放在客户机上，这正是多层体系结构的体现。 (2)用例设计。所谓用例(Use Case)就是用户与系统，系统内部各部分 之间相互交互、对话的场景。它描述了系统工作机制，从而揭示需要建造 的系统模型，并检验可否满足需求。对于分布式系统而言，应该从分布式 环境出发，找出系统的用例来，它对系统的功能设计及最后的测试都有很 大的意义，这方面应该请教有关应用领域的专家。 (3)对象的设计与调整。这是标志对象后更进一步的设计，对标志出的 对象(组件) 确定属性和行为，也就是数据成员和方法。这样，整个分布式 系统的运作可看成处于分布式环境中的各对象之间的相互通信及其引发的 动作。 属性是问题域中对象性质的刻画，行为为分布式对象应该展现的外部 服务之总和。可以通过提取外部服务名称及大致功能，标志分布式对象间 消息传递予以识别。最后，要通过实际运行的场景中的事件顺序对对象的 设计予以调整。 2.3 基于中间件的分布式系统开发过程的设计 三层分布式体系结构上面已经介绍，其表示层、应用逻辑层和数据存 储层是彼此分离的。其优点如下： 具有可伸缩性，这是因为它的数据库连接之类的资源可以共享，每一 个消耗资源的客户应用程序并不直接访问数据库服务器，而是由客户应用 程序与业务逻辑层进行通信。一个应用逻辑实例可以向多个客户提供服务， 降低了资源消耗，提高了伸缩性。 应用逻辑实体可以独立于任何客户应用程序来设计。这样对于很多应 用程序来说，就提供了非常的灵活性和重复使用的潜力。定义公共接口之 后的业务逻辑的封装，使得开发者可以创建可重复使用的服务的一个载体。 当然，也可以用新的应用逻辑来组合，以创建新的应用程序。此外，公共 功能也很容易更新，以适应商业规则的变化。 三层的体系结构使得现有的旧系统更容易地被集成：只需将现有系统 封装在业务逻辑中，客户程序只需关心怎样访问业务逻辑，不必关心依赖 的各种不同应用系统。 (1)表示层的设计。表示层向用户提供数据输入输出和响应用户动作并 控制用户的界面。一般而言，目前主要有两种：图形用户界面和基于 Web 的用户界面。 (2)应用逻辑层。该层主要用来实施业务规则和数据完整性规则等。它 向表示层提供服务，这些服务具有通用性，即服务适合于所有的应用程序。 只有这样设计，才能达到高效复用的目标。但是，它并不清楚数据以何种 方式存储及存储的地方，这要依赖于数据存储层。所以，应用逻辑层还要 提供数据访问服务，以执行数据的检索和存储。 (3)数据存储层。主要负责数据的存储，因此，它的设计主要是数据存 取的设计，必须确定上面分析中对象 (组件) 模型到关系模型的映射。一般 有三种策略：只把超类转换成表：超类把所有子类的属性和子类与其他 实体间的关系都收集起来，并加入一个辨别属性。这种方法便于查询所有 的子类的信息，但也会造成存储空间的浪费。只把子类转换成表：把各 个子类分别转换成互补相关的表，而超类中的属性及