网络管理技术及电信管理网的开发-模板

1、网络管理技术及电信管理网的开发摘 要：络管理已经成为计算机络和电信研究中最重要的内容之一。本文首先介绍当前几种络管理技术和TMN基本概念，然后讨论了 TMN开发中的关键技术 及TMN开发工具引入的必要性，并结合自己的开发实践讨论了 TMNt理者和代理 的开发，最后对电信管理的未来发展趋势进行了展望。、络管理技术概述络管理已经成为计算机络和电信研究中最重要的内容之一。络中采用的先 进技术越多，规模越大，络的维护和管理工作也就越复杂。 计算机络和电信的管 理技术是分别形成的，但到后来渐趋同化，差不多具有相同的管理功能和管理原 理，只是在络管理上的具体对象上有些差异。通常，一个络由许多不同厂家的产品

2、构成，要有效地管理这样一个络系 统，就要求各个络产品提供统一的管理接口，即遵循标准的络管理协议。这样， 一个厂家的络管理产品就能方便地管理其他厂家的产品， 不同厂家的络管理产品 之间还能交换管理信息。在简单络管理协议 SNM(Simpie Network ManagementProtocol )设计时, 就定位在是一种易于实施的基本络管理工具。 在管领域中，它扮演了先锋的角色， 因OSI的CMIP发展缓慢同时在In ternet的迅猛发展和多厂商环境下的络管理解 决方案的驱动下，而很快成为了事实上的标准。SNMP勺管理结构如图1所示。它的核心思想是在每个络节点上存放一个管理信息库 MIB (M

3、an ageme nt In formation Base ),由节点上 60 代理(age nt )负 责维护，管理者通过应用层协议对这些代理进行轮询进而对管理信息库进行管 理。SNMP!大的特点就是其简单性。它的设计原则是尽量减少络管理所带来的 对系统资源的需求，尽量减少age nt的复杂性。它的整个管理策略和体系结构的设计都体现了这一原则。SNMP勺主要优点是:-易于实施;-成熟的标准;-C/S模式对资源要求较低;-广泛适用，代价低廉。简单性是SNM标准取得成功的主要原因。因为在大型的、多厂商产品构成 的复杂络中，管理协议的明晰是至关重要的；但同时这又是SNM的缺陷所在一 为了使协议简单

4、易行，SNM简化了不少功能，如：没有提供成批存取机制，对大块数据进行存取效率很低;没有提供足够的安全机制，安全性很差;-只在TCpzIP协议上运行，不支持别的络协议;没有提供管理者与管理者之间通信的机制，只适合集中式管理，而不利 于进行分布式管理；-只适于监测络设备，不适于监测络本身。针对这些问题，对它的改进工作一直在进行。如1991年11月，推出了 RMON (Remote Network Monitor ) MIB,加强SNMI对络本身的管理能力。它使得SNMP 不仅可管理络设备，还能监测局域和互联上的数据流量等信息，1992年7月，针对SNM缺乏安全性的弱点，又公布了 S-SNM( Se

5、cure SNMP草案。到1993 年初，又推出了 SNMP Version 2即SNMPv(推出了 SNMPv以后，SNMP就被称 为SNMPV1。SNM-Pv2包容了以前对 SNMP勺各项改进工作，并在保持了 SNMP# 晰性和易于实现的特点以外，吸取了 CMIP的部分优点，功能更强，安全性更好，具体表现为:提供了验证机制，加密机制，时间同步机制等，安全性大大提高;提供了一次取回大量数据的能力，效率大大提高;增加了管理者和管理者之间的信息交换机制，从而支持分布式管理结构， 由位于中间层次(intermediate )的管理者来分担主管理者的任务， 增加了远地 站点的局部自主性。可在多种络协

6、议上运行，如 OSI、AppleTalk和IPX等，适用多协议络环 境(但它的缺省络协议仍是UDP。扩展了管理信息结构的很多方面。特别是对象类型的定义引入了几种新 的类型。另外还规范了一种新的约定用来创建和删除管理表( man ageme nt tables )中的“行”(rows)。定义了两种新的协议数据单元PDU(Protocol Data Unit )。Get-Bulk-Request协议数据单元允许检索大数据块(large data blocks )，不 必象SNM那样逐项(item by item )检索；Inform-Request 协议数据单元允 许在管理者之间交换陷阱(tran

7、 )信息。CMIP协议是在OSI制订的络管理框架中提出的络管理协议。CMIP与 SNMP一样，也是由管理者、代理、管理协议与管理信息库组成。CMIP是基于面向对象的管理模型的。这个管理模型表示了封装的资源并标 准化了它们所提供的接口。如图2所示了四个主要的元素：系统管理应用进程是在担负管理功能的设备(服务器或路由器等中运 行的软件：-管理信息库MIB是一组从各个接点收集来的与络管理有关的数据;系统管理应用实体(system management application entities) 负责 络管理工作站间的管理信息的交换，以及与络中其它接点之间的信息交换;层管理实体(layer manag

8、ement entities)表示在OSI体系结构设计中必要的逻辑。CMIP模型也是基于C/S结构的。客户端是管理系统，也称管理者，发起操 作并接收通知；服务器是被管系统，也称代理，接收管理指令，执行命令并上报 事件通知。一个CMIP操作台(console )可以和一个设备建立一个会话，并用一 个命令就可以下载许多不同的信息。 例如，可以得到一个设备在一段特定时间内 所有差错统计信息。CMIP采用基于事件而不是基于轮询的方法来获得络组件的相关数据。CMIP已经得到主要厂商，包括IBM、HP及AT&T的支持。用户和厂商已经认 识到CMIP在级络管理领域是一个比较好的选择。它能够满足级管对

9、横跨多个管 理域的对等相互作用(peer to peer interactions)的要求。CMIP特别适合对要求提供集中式管理的树状系统，尤其是对电信(telemu ni catio ns network ) 的管理。这就是下面提到的电信管理。、电信管理TMN电信管理TMN是国际电联ITU-T借鉴0SI中有关系统管理的思想及技术， 为管理电信业务而定义的结构化络体系结构，TMNS于OSI系统管理(ITU-U /ISO 7498-4 )的概念，并在电信领域的应用中有所发展.它使得络管理系统与电 信在标准的体系结构下，按照标准的接口和标准的信息格式交换管理信息，从而实现络管理功能。TMN勺基本原

10、理之一就是使管理功能与电信功能分离。络管理 者可以从有限的几个管理节点管理电信络中分布的电信设备。国际电信联盟(ITU)在建议中指出，电信管理的基本概念是提供一个有组 织的络结构，以取得各种类型的操作系统(OSS之间、操作系统与电信设备之 间的互连。它采用商定的具有标准协议和信息的接口进行管理信息交换的体系结 构。提出TMN体系结构的目的是支撑电信和电信业务的规划、配置、安装、操作 及组织。电信管理TMN勺目的是提供一组标准接口，使得对络的操作、管理和维护 及对络单元的管理变得容易实现，所以，TMN勺提出很大程度上是为了满足管各 部分之间的互连性的要求。集中式的管理和分布式的处理是TMN勺突出

11、特点。ITU-T从三个方面定义了 TMN勺体系结构(Architecture )，即功能体系结 构(Functional Architecture )，信息体系结构(Information Architecture ) 和物理体系结构(Physical Architecture )。它们分别体现在管理功能块的划分、 信息交互的方式和管的物理实现。我们按TMN勺标准从这三个方面出发，对 TMN系统的结构进行设计。功能体系结构是从逻辑上描述 TMN内部的功能分布。弓I入了一组标准的功能块(Functional block )和可能发生信息交换的参考点(referenee points )。整个TM

12、N系统即是各种功能块的组合。信息体系结构包括两个方面：管理信息模型和管理信息交换。管理信息模 型是对络资源及其所支持的管理活动的抽象表示， 络管理功能即是在信息模型的 基础上实现的。管理信息交换主要涉及到 TMN勺数据通信功能和消息传递功能， 即各物理实体和功能实体之间的通信。物理体系结构是为实现TMN勺功能所需的各种物理实体的组织结构。TMN 功能的实现依赖于具体的物理体系结构，从功能体系结构到物理体系结构存在着 映射关系。物理体系结构随具体情况的不同而千差万别。在物理体系结构和功能 体系结构之间有一定的映射关系。物理体系结构中的一个物理块实现了功能体系 结构中的一个或多个功能块，一个接口实

13、现了功能体系结构中的一组参考点。仿照OSI络分层模型，ITU-T进一步在TMh中引入了逻辑分层。如图3所示:TMN的逻辑分层是将管理功能针对不同的管理对象映射到事务管理层BML(Busin ess Man ageme ntLayer)，业务管理层 SML( Service Man ageme ntLayer)， 络管理层 NML Network ManagemenLayer)和元管理层 EM(Element Management Layer )。再加上物理存在的元层 NEL( Network Element Layer )，就构成了 TMN 的逻辑分层体系结构。从图2-6可以看到，TMN定义的

14、五大管理功能在每一层上 都存在，但各层的侧重点不同。这与各层定义的管理范围和对象有关。三、TMN开发平台和开发工具1 .利用TMN勺开发工具开发TMN勺必要性TMN勺信息体系结构应用OSI系统管理的原则，引入了管理者和代理的概 念，强调在面向事物处理的信息交换中采用面向对象的技术。如前所述，TMN!高度强调标准化的络，故基于 TMN标准的产品开发，其标准规范要求严格复杂， 使得TMN的实施成为一项具有难度和挑战性的工作；再加上OSI系统管理专业人 员的相对缺乏，因此，工具的引入有助于简化 TMN勺开发，提高开发效率。目前 比较流行的基于 TM际准的开发平台有 HPONDM SUNSEM IBM

15、 TMNP台和DSET 的DSG及其系列工具。这些平台可以用于开发全方位的 TMNt理者和代理应用， 大大降低TM/Q3应用系统的编程复杂性，并且使之符合开放系统互连(OSI) 络管理标准，这些标准包括高级信息模型定义语言 GDM0OSI标准信息传输协议 CMIP以及抽象数据类型定义语言。其中 DSET的DSG及工具系列除了具备以上 功能外，还具有独立于硬件平台的优点。下面将比较详细论述DSET的TMN开发工具及其在TMN开发中的作用。2. DSET的TMN开发工具的基本组成DSET的TMN开发工具从功能上来讲可以构成一个平台和两大工具箱。一个 平台：分布式系统生成器 DSG( Distrib

16、uted System Generator)；两个工具箱:管理者工具箱和代理工具箱。分布式系统生成器DSGDSG是用于顶层TCP/ IP、OSI和其它协议上构筑分布式并发系统的高级对 象请求代理ORB DSG将复杂的通信基础设施和面向对象技术相结合，提供构筑 分布式计算的软件平台。通信基础设施支持分布式计算中通信域的通信要求。如 图4所示，它提供了四种主要的服务：透明远程操作、远程过程调用和消息传递、 抽象数据服务及命名服务。借助于并发的面向对象框架，一个复杂的应用可以分 解成一组相互通信的并发对象worker，除了支持例如类和多重继承等重要的传 统面向对象特征外，为了构筑新的 worker类

17、，DSG也支持分布式对象。在一个 开放系统中，一个worker可以和其它worker进行通信，而不必去关心它们所处 的物理位置。DSG提供给用户用以开发应用的构造块(building block)称为worker。一个worker可以有自己的控制线程，也可以和别的线程共享一个控制线程，每 个Worker都有自己的服务访问点 SAP(Service Access Point )，通过SAP与其 它worker通信。Worker是事件驱动的。在Worker内部，由有限状态机FSMFinite State Machine定义各种动作及处理例程，DS聚受外部事件并分发到相应的 动作处理例程进行处理。如

18、图5所示，独占线程的此worker有三个状态，两个 SAPs并且每个SAP的消息队列中都有两个事件。DSG环境通过将这些事件送到 相应的事件处理程序中来驱动 worker的有限状态机。Worker是分布式的并发对象，DSG用它来支持面向对象的特点，如：类，继承等等。Worker由worker class定义。Worker可以根据需要由应用程序动态创建。在一个UNIX进程中可以创建的 Worker个数仅受内存的限制。管理者工具箱由/ C+编译器、CMIPZROS协议和管理者代码生成器MCG 构成，如图6所示。其中的CMIP/ROS协议提供全套符合Q3接口选用的OSI七层协议栈实施。 由于TMN在

19、典型的电信环境中以面向对象的信息模型控制和管理物理资源，所有被管理的资源均被抽象为被管对象(MO,被管理系统中的代理帮助管理者通过 MC访问被管理资源，又根据ITU-T建议：管理者与代理之间通过 Q3接口通信。 为此管理者必须产生与代理通信的 CMIP请求。管理者代码生成器读取信息模型 (GDM文件和文件)，创立代码模板来为每个被定义的 MO类产生CMIP请求和 CMIP响应。由于所有CMIP数据均由符号定义，而上层管理应用可能采用C/C+, 故管理者应用需要包含数据处理代码，管理者工具箱中的ASNC/ C+编译器提供数据到C/C+语言的映射，并采用“预处理技术“生成数据的低级代码，可 见利用

20、DSETX具用户只需编写管系统的信息模型和相关的抽象数据类型定义文 件，然后利用DSET勺ASNC/C+S译器，管理者代码生成器即可生成管理者部 分代码框架。代理工具箱包括可砚化代理生成器 VAB CMIP翻译器、/ C+Toolkit，其 结构见图7。用来开发符合管理目标定义指南 GDM和通用管理信息协议CMIP规 定的代理应用.使用DSET独具特色的代理工具箱的最大的好处就是更快、 更容易 地进行代理应用的开发。DSET在代理应用的开发上为用户做了大量的工作。一个典型的GDM0CM1R代理应用包括三个代码模块:代理、MIT、MIB的实施 -被管理资源的接口代码 -后端被管理资源代码第一个模

21、块用于处理代理与 MO实施。代理工具箱通过对过滤、特性处理、 MO实例的通用支持，自动构作这一个模块。DSET的这一部分做得相当完善，用mcreate、m-delete户只需作少量工作即可完成本模块的创建。对于mcreate、m-delete、m-get、m-ca ncel-get、m-set、m-set-c on firmed 、m-actio n、m-acti on-con firmed 这 些CMIP请求，第一个模块中包含有缺省的处理代码框架。这些缺省代码都假定 管理者的CMIP请求只与MO丁交道。为了适应不同用户的需求，DSET代理工具箱又提供在缺省处理前后调用用户程序的接入点（称为U

22、ser hooks）。当某CMIP请求需与实际被管资源或数据库打交道时，用户可在相应的PRE或POST函数中 加入自己的处理代码。例如，当你需要在二层管理应用中发CMIP请求，需望获取实际被管资源的某属性，而该属性又不在相应MO中时你只需在GDM预定义模 板中为此属性定义一 PRE-GETS数，并在你自己的定制文件中为此函数编写从实 际被管设备取到该属性值的代码即可。DSET的 Age nt代码在执行每个CMIP请求 前都要先检查用户是否在 GDM预定义文件中为此清求定义了 P RE-函数，若是， 则光执行PRE函数，并根据返回值决定是否执行缺省处理（PRE函数返回D-OK 则需执行缺省处理，

23、否则 Age nt向管理者返回正确或错误响应）。同样当Age nt 执行完缺省处理函数时，也会检查用户是否为该请求定义了P OST函数，若是则继续执行POST函数。至于Age nt与MO之间具体是如何实现通信的，用户不必 关心，因为DSET已为我们实现了。用户只需关心需要与设备交互的那一部分 CMIP 请求，为其定制PRE-/POST函数即可。第二个模块实现MOT实际被管资源的通信。它的实现依赖于分布式系统生 成器DSG所提供“关处理单元” （gateway）、远程过程调用（RPC与消息传递 机制及MSL语言编译器。通信双方的接口定义由用户在简化的 ROS前用中定义， 在DSG也叫环境，该环境

24、定义了双方的所有操作和相关参数。DSG的 CTX编译器编译CTX格式的接口定义并生成接口表。DSG的 MSL语言编译器用以编译分布 式对象类的定义并生成事件调度表。采用 DSG勺关作为MO与实际被管资源间的 通信桥梁，关与MC之间通过定义接口定义文件及各自的 MSL文件即可实现通信, 关与被管设备之间采用设备所支持的通信协议来进行通信，例如采用 TCP IP 协议及Socket机制实现通信。第三个模块对被管理资源进行实际处理。这一模块根据第二个模块中定义 的关与被管设备间的通信机制来实现，与工具没有多大。四、TMN开发的关键技术电信管理技术蕴含了当今电信、计算机、络通信和软件开发的最新技术，如

25、OSI开放系统互连技术、OSI系统管理技术、计算机络技术及分布式处理、面 向对象的软件工程方法以及高速数据通信技术等。电信管理应用系统的开发具有巨大的挑战性。工具的引入很大程度上减轻了 TMN勺开发难度。留给开发人员的最艰巨工 作就是接口（ in terface 、的信息建模。尤其是Q3接日的信息建模问题。Q3接口是TMh接口的“旗舰”，Q3接口包括通信模型和信息模型两个部分， 通信模型（OSI系统管理）的规范制定的十分完善，并且工具在这方面所作的工 作较多，因此，当我们设计和开发各种不同管理业务的 TMN系统时，主要是采用 一定的方法学，遵循一定的指导原则，针对不同电信领域的信息建模问题。为

26、什么说建模是TMN发中的关键技术呢？从管理的角度而言，在那些先 有国际标准（或事实上的标准），后有设备的情况下，是有可能存在一致性的信 息模型的，例如目前SDH和七号信令的TMNS统存在这样的信息模型标准。但即 使这样，在这些TMNS统的实施过程，有可能由于管理需求的不同而对这些模型 进行进一步的细化。在那些先有设备而后才有国际标准 （或事实上的标准）的设 备，而且有的电信设备就无标准而言， 由于不同厂家的设备千差万别， 这种一致 性的信息模型的制定是非常困难的。例如，近年来标准化组织国际电信联盟（ITU-T）、欧洲电信标准组织（ETSI）、 络管理论坛（NMF和ATM论坛等相继颁布了一些 Q

27、3信息模型。但至今没有一个 完整的稳定的交换机元层的Q3信息模型。交换机的Q3信息模型提供了交换机元的一个抽象的、一般的视图，它应当包含交换机的管理的各个方面。 但这是不可 能的。因为随着电信技术的不断发展，交换机技术也在不断的发展，交换机的类 型不断增加，电信业务不断的引入。我们很难设计一个能够兼容未来交换机的信 息模型。如今的交换机已不再是仅仅提供的窄带业务，而且也提供象ISDN这样的宽带业务。交换机趋向宽带窄带一体化发展，因此交换机的Q3信息模型是很复杂的，交换机Q3信息建模任务是很艰巨的。五、TMNt理者和代理的开发F面结合我们的开发工作，探讨一下 TMNt理者和代理的开发。1管理者的

28、开发基于OSI管理框架的管理者的实施通常被认为是很困难的事，通常，管理 者可以划分为三个部分。第一部分是位于人机之间的图形用户接口GUI(Grap hical User In terfaces )，接收操作人员的命令和输入并按照一种统一的 格式传送到第二部分一一管理功能。管理功能提供管理功能服务，例如故障管理， 性能管理、配置管理、记费管理，安全管理及其它特定的管理功能。接收到来 GUI的操作命令，管理功能必须调用第三部分一一 CMSI API来发送CMIP请求到 代理。CMIS API为管理者提供公共管理信息服务支持。大多数的管应用是基于 UNIX平台的，女口 Solaris , AIX a

29、nd HP-UX。若GUI 是用X-Window来开发的，那么GUI和管理功能之间的接口就不存在了，从实际 编程的的角度看，GUI和管理功能都在同一个进程中。上面的管理者实施方案尽管有许多优点，但也存在着不足。首先是费用昂 贵。所有的管理工作站都必须是 X终端，服务器必须是小型机或大型机。 这种方 案比采用PC机作客户端加上UNIX服务器的方案要昂贵得多。其次，扩展性不是 很好，不同的管理系统的范围是不同的， 用户的要求也是不一样的，不是所有的 用户都希望在X终端上来行使管理职责。因此，PC机和调终端都应该向用户提 供。最后由于X-Window的开发工具比在PC机上的开发工具要少得多。因此最终

30、 在我们的开发中，选择了 PC机作为管理工作站，SUN Ultral作为服务器。在实际工作中我们将管理者划分为两个部分管理应用(man ageme ntapplication )和管理者关(manager gateway )。女口图 8 所示。管理应用向用户提供图形用户接口 GUI并接受用户的命令和输入，按照定 义好的消息格式送往管理者关，由其封装成CMIP请求，调用CMISAPI发往代理。 同时，管理者关还要接收来自代理的响应消息和事件报告并按照一定的消息格式 送往管理应用模块。但是这种方案也有缺点。由于管理应用和管理者关的分离，前者位于PC机上，后者位于Ultral工作站上。它们之间的相互

31、作用须通过络通信来完成。它 们之间的接口不再是一个参考点(Reference Point )，而是一个物理上的接口， 在电信管理TMN中称为F接口。迄今为止ITU-T 一直没能制定出有关F接口的标 准，这一部分工作留给了 TMN勺开发者。鉴于此，我们制定了管理应用和管理者 关之间通信的协议。在开发中，我们选择了 PC机作为管理工作站，SUNJltral作为我们的管理 者关。所有的管理应用都在 PC机上。开发人员可以根据各自的喜好来选择不同 开发工具，如Java, VC+ VB, PB等。管理者关执行部分的管理功能并调用 CMIS API来发送CMIP请求，接收来自代理的响应消息和事件报告并送往

32、相应的管理 应用。管理者关的数据结构是通过编译信息模型(GDM文件和文件)获得的。它 基于DSG环境的。管理者关必须完成下列转换：数据类型转换：GUI中的数据类型与描述的数据类型之间的相互转换;消息格式转换：GUI和管理者关之间的消息格式与 CMIP格式之间的相互转换；协议转换：TCp/IP协议与OSI协议之间的相互转换。这意味着管理者关接收来自管理应用的消息。将其转换为的数据格式，并 构造出CMIS的参数，调用CMIS API发送CMIP请求。反过来，管理者收到来自 代理的消息，解读CMIS参数，构造消息格式，然后送往 GUI。GUI和管理者关之 间的消息格式是由我们自己定义的。由于管理应用

33、的复杂性，消息格式的制定参考了 CMIS的参数定义和的数据类型。管理者关是采用多线程(multi-thread)编程来实现的。2代理的开发代理的结构如图9所示。为了使代理部分的设计和实现模块化、系统化和简单化，将 age nt分成两 大模块一一通用代理模块和MO模块一一进行设计和实现。如图所示，通用age nt 向下只与MC部分直接通信，而不能与被管资源MRft接进行通信及操作，即通用 age nt将man ager发来的CMlP青求解析后投递给相应的 M0并从MO接收相应的 应答信息及其它的事件报告消息。代理的作用是代表管理者管理 MO利用工具的支持，采用面向对象的技术, 分为八个步骤进行a

34、ge nt的设计和实现，这八个步骤是：第一步：对信息模型既GDM文件和文件的理解，信息模型是 TMN系统开发 的基础和关键。特别是对信息模型中对象类和其中各种属性清晰的认识和理解， 对于实际的TMN系统来说，其信息模型可能很复杂，其中对象类在数量上可能很 多。也就是说，在设计和实现 age nt之前，必须作到对MO心中有数。第二步：被管对象MO的定制。这一部分是age nt设计和实现中的关键部分， 工具对这方面的支持也不是很多，特别是涉及到MO与MF之间的通信，更为复杂, 故将MO专门作为一个模块进行设计和实现 MOW MR之间的通信以及数据和消息 格式的转换问题，利用关原理设计一个关来解决。

35、第三步：创建内置的M0所谓内置MO就是指在系统运行时，已经存在的物 理实体的抽象。为了保证能对这些物理实体进行管理，必须将这些被管对象的各 种固有的属性值和操作预先加以定义。第四步：创建外部服务访问点 SAP如前所述，TMN系统中各个基于分布式 处理的worker之间通过SAP进行通信，所以要为age nt与管理者man ager之间、 age nt与关之间创建SAP第五步：SAP同内置MO的捆绑注册。由于在TMN系统中，age nt的所有操 作是针对MO勺，即所有的CMIP请求经解析后必须送到相应的 M0而基于DSG 平台的worker之间的通信是通过SAP来实现的。因而，在系统处理过程中，

36、当 进行信息的传输时，必须知道相应 MOW SAP所以，在age nt的设计过程中， 必须为内置MO注册某一个SAP第六步：age nt配置。对age nt中有些参数必须加以配置和说明。 如队列长 度、流量控制门限值、age nt处理单元组中worker的最大/最小数目。报告的 处理方式、同步通信方式中超时门限等。第七步：age nt用户函数的编写，女口 age nt worker初始化函数、子代理函 数等的编写。第八步：将所有函数编译，连接生成可运行的age nt。MO模块是age nt设计中的一个重要而又复杂的部分。这是由于，一方面工 具对该部分的支持不是很多：另一方面，用户的大部分处理函

37、数位于这一部分； 最主要的还在于它与被管资源要跨平台，在不同的环境下进行通信。MO模块的设计思想是在MOW MF之间设计一个关(gateway)，来实现两者之间的消息、数 据、协议等转换。MO部分的主要功能是解析，执行来自管理者的 CMIP请求，维持各MO勺属 性值同被管资源的一致性，生成 CMIP请求结果，并上报通用age nt模块，同时 与MR通信，接收和处理来自MR的事件报告信息，并转发给通用 age nt。MO部分有大量的用户定制工作。工具只能完成其中一半的工作，而另一半 工作都需要用户自己去定制。用户定制分为两大类；第一类是P RE/ POST函数。P RE/ POST函数的主要功能

38、是在 age nt正式 处理CMIP请求之前/之后与被管资源打交道，传送数据到MR或从MR获取数据并做一些简单的处理。通过对这些 P RE/ POST函数的执行，可以确保代理能够 真实地反映出被管资源的运行状态。P RE/ POST函数分为两个层次：MO级别和 属性级别。MO级别层次较高，所有对该对象类的 CMIP操作都会调用MO级别的PRE-/POST函数。属性级别层次低，只有对该属性的CMIP操作才会调用这些函 数。DSET工具只提供了 PRE-ZPOST函数的人口参数和返回值，具体的代码需要 完全由用户自己编写。由于age nt与被管资源有两种不同的通信方式，不同的方 式会导致不同的编程

39、结构和运行效率， 如果是同步方式，编程较为简单，但会阻 塞被管资源，适合于由大量数据返回的情况。异步方式不会阻塞被管资源，但编 程需要作特殊处理，根据不同的返回值做不同的处理，适合于数据不多的情况， 在选择通信方式时还要根据 MO勺实现方式来确定。比如，MO若采用Doer来实 现，则只能用同步方式。第二类是动作、事件报告和通知的处理，动作的处理相对比较容易，只需考虑其通信方式采用同步还是异步方式。对事件报告和通知的处理比较复杂。 首由哪一个事先，需要对事件进行分类，对不同类别的事件采用不同的处理方法，件前向鉴别器EFD(Event Forwarding Discriminator)来处理等等。

40、比如，告警事件的处理就可以单独成为一类。其次，对每一类事件需要确定相应的EFD的条件是什么，哪些需要上报管理应用，哪些不需要。是否需要记入日志，这些 日志记录的维护策略等等。除了这两类定制外，MO也存在着优化问题。比如 MC用worker还是Doer 来实现，通信方式采用同步还是异步，面向连接还是无连接等等，都会影响整个 代理的性能。如果MOS永久存储，我们采用文件方式。因为目前 DSET的工具只支持 Versa nt、ODI这两种面向对象数据库管理系统 OODBMS对于Oracle ，Sybase 等数据库的接口还需要用户自己实现。MC定制的工作量完全由信息模型的规模和复杂程度决定，一个信息

41、模型的对象类越多，对象之间的关系越复杂(比如一 个对象类中的属性改变会影响别的类)，会导致定制工作的工作量和复杂程度大 大增加。代理者age nt在执行管理者发来的CMIP青求时必须保持与被管资源 MRS 行通信，将manager传送来的消息和数据转发给 MR并要从MR获取必要的数据 来完成其操作，同时，它还要接收来自 MR的事件报告，并将这些事件上报给 man ager。由上述可知，代理与被管资源MR之间的通信接口实际上是指 MM MF之间的通信接口。大部分MC是对实际被管资源的模拟，这些 MC要与被管资源通信。 若让这些MC直接与被管资源通信，则存在以下几个方面的弊端：由于MC莫块本身不具备错误信息检测功能（当然也可在此设计该项功能， 但增加了 MC莫块的复杂性），如果将上向发来的所有信息（包括某些不恰当的信 息）全部转发给MR不仅无此必要，而且增加了数据通信量；同理 MF上发的信 息也无必要全部发送给MC每当有消息进看是否