移动电话综合业务管理系统的关键技术研究(2)

发布: 2010-10-20 00:51 | 作者: | 来源: | 字体: 小中大

移动电话综合业务管理系统的关键技术研究(2)
2.2.2 CBD技术的特点
    CBD（Component Based Software Development）意为软件构件开发技术。它是以软件构
架为组装蓝图，以可复用的软件构件为组装预制块，支持组装式的软件复用。
    所谓软件构架（又称软件体系结构）是对系统整体设计格局的描述，它为CBD提供了构件
组装的基础和上下文。所谓软件构件（Commpoment）是指应用系统中可以明确辨识的构成成
分，而可复用构件（Beusable Component）是指具有相对独立的功能和可复用价值的构件。
使用CBD技术有利于发现不同系统的高层共性，保证灵活和正确的系统设计，对系统的整体结
构和全局属性进行规约份析、验证和管理。将构架作为系统构造和演化的基础，可以实现大
规模、系统化的软件复用，可以减少应用软件的开发周期，提高软件产品的质量，提高应用
软件的灵活性和对业务变化的适应性，是今后大规模信息系统应用软件实现技术的发展方向。
    伴随着CBD技术的出现，几乎所有的软件开发新技术和新产品，例如CORBA、MS Visual 
Studio、UML、UNIFACE、Oracle8、三层结构、JavaBean、ActiveX等等，都宣称支持CBD技术。
市场上也出现了众多的构件开发和封装工具，以及大量的面向GUI、数据库和网络的Delphi构
件、JavaBean构件VBX与ActiveX控件，以及众多的类库、DLL接口和API等。
2.2.3软件总线技术
    所谓软件总线，就是起到类似于计算机系统硬件总线的作用，只要将应用模块按总线规
范做成软插件（软件构件），插入软件总线即可集成运行，实现应用软件模块的即插即用
（P＆P）。
    目前关于软件总线还没有形成全球统一的标准，但是已有一些企业或企业联盟制定的标
准，其中以国际组织OMG（Obiect Management Group）的CORBA、微软公司的DCOM（Distrib
uted Component Obiect Model）/COM＋、SUN公司的Java Bean最有影响。目前对这三种标
准的普遍看法是：
    （1）CORBA
    不仅支持应用集成框架的建立，满足协同工作的需求，而且建立了多层次的软构件技术，
更加便于应用领域框架和构件的开发，实现集成平台的系统管理和公共服务，使系统具有良
好的开放性和扩展性。基于CORBA标准的对分布对象的透明访问，允许应用对远程对象和本
地对象使用相同的访问模式，从而屏蔽了操作平台和通信机制，使应用开发者更加专注于应
用逻辑的开发。COngA标准以其技术的开放性和灵活性赢得了900多家软硬件厂商的支持。
    （2）DCOM／COM+
    构件间的互操作基于指针进行，依赖于操作系统的API。对Windows的依赖性强，对其他
操作系统的支持相对不足。构件运行环境的提供者也仅限于微软，但支持COM规范的开发工
具比较多，例如VC++、VB、C++和Builder等。
    （3）Java Bean
    概念清晰、结构紧凑、适用于分布式计算模型，构件应用开发相当灵活，但由于它还处
于发展时期，因此其形态很难界定。
    以前在软件总线标准尚不明朗时，我们曾自己定义过企业内部的软件总线标准——CMD
BUS（命令总线），试图通过命令总线实现功能模块的即插即用，取得了一些良好的效果。
目前，在我们开发的“超越-2000移动电话综合业务管理系统”3.0版中，采用了CORBA总线
规范，开发工具使用的是 Delphi 4。在实际应用中，我们感到CORBA总线有如下一些突出特
点：
    （1）CORBA总线的核心系统ORB（Object Bequest Broker，对象请求代理器）不仅支持
标准的OMG对象模型，还具有分布进程管理和通信管理功能，取代了传统C／S结构中的相应
接口部分。
    （2）在CORBA规范中引入了代理（Broker）的概念。一个代理至少可以有三个方面的作
用：完成对客户方提出的抽象服务请求的映射；自动发现和寻找服务器；自动设定路由，实
现到服务器方的执行。这样用户在编制客户程序时就可以避免了解过多的细节，而只要完整
地定义和说明客户需要完成的任务和目标。
    （3）增加了代理机制后，实现了客户方程序与服务器方程序的完全分离，这与面向过
程调用机制为基础的客户／服务器模式根本不同。
    （4）CORBA规范定义的基础是面向对象的设计思想和实现方法。把分布式计算与面向对
象的概念相结合有很多好处，能够将冗余度控制在最低的程度，一个对象既能被客户程序使
用，也能被服务器程序使用，对象实现的修改不会影响双方实现程序和提高软件重用率。
    （5）提供了软件总线的机制，使得任何应用程序、软件系统或工具只要具有与该接口
规范相符合的接口定义，就能方便地集成到CORBA系统中，而这个接口规范独立于任何实现
语言和环境。
    （6）分层的设计原则和实现方式。CORBA规范只是针对OMA体系结构中的ORB制订的工业
标准，而面向应用的对象定义则可以在OMA的应用对象或应用开发环境中逐步分层定义和实
现。
    CORBA规范充分利用了现今各种技术发展的最新成果，在分布环境下实现应用的集成，
使得基于对象的软件成员在分布异构环境中实现可重用、可移植和可互操作。目前世界上主
要的计算机厂家纷纷提出了符合CORBA标准的ORB产品，如Object Broker（Compaq／DEC公
司）、
ORB  Plus（HP公对）、DSOM（IBM公司）、Orbix（Iona公司）、Visi broker（Inprise/Bor
land公司）以及Component Broker等。
3应用系统的部分关键技术
3.1用静态数据库实现应用软件的参数驱动
    即使是采用CBD技术和软件总线结构，参数驱动仍然是不可缺少的。参数驱动的具体实
现过程是，在需求分析和系统设计阶段，尽可能多地对业务需求可能发生的变化予以充分的
考虑，并将所有与软件本身无关的业务参数进行剥离，用数据库对这些参数进行管理（我们
称之为静态数据库）。在应用软件运行时，首先将静态数据库中各种参数读入内存，依据这
些参数所反映的业务规则对各类业务数据进行处理。如果某些业务需求发生变化，只需调用
静态数据库管理子系统对相应的参数进行简单的修改即可完成应用软件的调整。
    但是参数驱动技术在具体实现过程中还有一些问题需要解决，例如：某些参数的调整要
在指定日期的指定时刻进行，如何保证参数生效的实时性；在联机实时计费处理模式中，一
般的参数修改如何不中断应用软件的正常运行；静态数据库中的参数数据如何与在主机内存
中的数据保持一致；如何对操作员输入或修改的参数进行检查，避免由于疏忽造成的错误等。
对此，我们采用了以下一些技术。
    首先，我们在静态数据库中建立了两套相同的参数表，一套表（SET A）用于数据的修
改、查询、统计等操作，另一套（SET B）用于数据处理，两套表之间采用数据复制方式保
持一致，其中SET A为“源”，SET B为“目的”。参数的修改均在SET A上进行。其次，我
们运用专家系统中的智能推理技术对修改后的各种参数表进行规则检查，检查是否有数据重
叠、冲突、超界、格式错等。例如在计费系统中，对各个本地网或移动业务区新分配的MSI
SDN号或MSIMSI号码段进行检查，看是否有号码段的重叠、复用等现象发生。该措施能够显
著减少疏忽引起的错误发生。检查无误后，使用触发器技术自动进行相关表的一致性复制，
并在复制结束后，再将内存中的参数文件进行刷新。此外，我们还在参数中增加了表示参数
何时生效的字段，程序可据此判断该参数应在何时生效或使用。例如，在费率调整时刻前后，
根据话单中的实际通话时刻以及费率参数的生效时间，选择相应的费率标准对话单进行批价
处理。