网络管理技术及电信管理网〈计算机〉之开发

1、网络管理技术及电信管理网计算机之开发    一、网络管理技术概述网络管理已经成为计算机网络和电信网研究中最重要之内容之一。网络中采用之先进技术越多，规模越大，网络之维护和管理工作也就越复杂。计算机网络和电信网之管理技术是分别形成之，但到后来渐趋同化，差不多具有相同之管理功能和管理原理，只是在网络管理上之具体对象上有些差异。通常，一个网络由许多不同厂家之产品构成，要有效地管理这样一个网络系统，就要求各个网络产品提供统一之管理接口，即遵循标准之网络管理协议。这样，一个厂家之网络管理产品就能方便地管理其他厂家之产品，不同厂家之网络管理产品之间还能交换管理信息。

2、在简单网络管理协议SNMP（Simple Network Management Protocol）设计时，就定位在是一种易于实施之基本网络管理工具。在网管领域中，它扮演了先锋之角色，因OSI之CMIP发展缓慢同时在Internet之迅猛发展和多厂商环境下之网络管理解决方案之驱动下，而很快成为了事实上之标准。SNMP之管理结构如图1所示。它之核心思想是在每个网络节点上存放一个管理信息库MIB（Management Information Base），由节点上60代理（agent）负责维护，管理者通过应用层协议对这些代理进行轮询进而对管理信息库进行管理。SNMP最大之特点就是其简单性。它之设计原则

3、是尽量减少网络管理所带来之对系统资源之需求，尽量减少agent之复杂性。它之整个管理策略和体系结构之设计都体现了这一原则。SNMP之主要优点是：·易于实施；·成熟之标准；· CS模式对资源要求较低；·广泛适用，代价低廉。简单性是SNMP标准取得成功之主要原因。因为在大型之、多厂商产品构成之复杂网络中，管理协议之明晰是至关重要之；但同时这又是SNMP之缺陷所在为了使协议简单易行，SNMP简化了不少功能，如：·没有提供成批存取机制，对大块数据进行存取效率很低；·没有提供足够之安全机制，安全性很差；·只在TCPIP协议上运行，不支

4、持别之网络协议；·没有提供管理者与管理者之间通信之机制，只适合集中式管理，而不利于进行分布式管理；·只适于监测网络设备，不适于监测网络本身。针对这些问题，对它之改进工作一直在进行。如1991年11月，推出了RMON（Rernote Network Monitor）MIB，加强SNMP对网络本身之管理能力。它使得SNMP不仅可管理网络设备，还能监测局域网和互联网上之数据流量等信息，1992年7月，针对SNMP缺乏安全性之弱点，又公布了S-SNMP（Secure SNMP）草案。到1993年初，又推出了SNMP Version 2即SNMPv2（推出了SNMPv2以后，SNMP

5、就被称为SNMPv1）。SNM-Pv2包容了以前对SNMP之各项改进工作，并在保持了SNMP清晰性和易于实现之特点以外，吸取了CMIP之部分优点，功能更强，安全性更好，具体表现为：·提供了验证机制，加密机制，时间同步机制等，安全性大大提高；·提供了一次取回大量数据之能力，效率大大提高；·增加了管理者和管理者之间之信息交换机制，从而支持分布式管理结构，由位于中间层次（intermediate）之管理者来分担主管理者之任务，增加了远地站点之局部自主性。·可在多种网络协议上运行，如OSI、AppleTalk和IPX等，适用多协议网络环境（但它之缺省网络协议仍是

6、UDP）。·扩展了管理信息结构之很多方面。特别是对象类型之定义引入了几种新之类型。另外还规范了一种新之约定用来创建和删除管理表（management tables）中之“行”（rows）。·定义了两种新之协议数据单元PDU（Protocol Data Unit）。Get-Bulk-Request协议数据单元允许检索大数据块（large data blocks），不必象SNMP那样逐项（item by item）检索； Inform-Request协议数据单元允许在管理者之间交换陷阱（tran）信息。CMIP协议是在OSI制订之网络管理框架中提出之网络管理协议。CMIP与SN

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

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

9、o peer interactions）之要求。CMIP特别适合对要求提供集中式管理之树状系统，尤其是对电信网（telecommunications network）之管理。这就是下面提到之电信管理网。二、电信管理网TMN电信管理网TMN是国际电联ITU-T借鉴0SI中有关系统管理之思想及技术，为管理电信业务而定义之结构化网络体系结构，TMN基于OSI系统管理（ITU-U X.700ISO 7498-4）之概念，并在电信领域之应用中有所发展.它使得网络管理系统与电信网在标准之体系结构下，按照标准之接口和标准之信息格式交换管理信息，从而实现网络管理功能。TMN之基本原理之一就是使管理功能与电信功

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

11、U-T从三个方面定义了TMN之体系结构（Architecture），即功能体系结构（Functional Architecture），信息体系结构（Information Architecture）和物理体系结构（Physical Architecture）。它们分别体现在管理功能块之划分、信息交互之方式和网管之物理实现。我们按TMN之标准从这三个方面出发，对TMN系统之结构进行设计。功能体系结构是从逻辑上描述TMN内部之功能分布。引入了一组标准之功能块（Functional block）和可能发生信息交换之参考点（reference points）。整个TMN系统即是各种功能块之组合。信息体

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

13、层模型，ITU-T进一步在TMN中引入了逻辑分层。如图3所示：TMN之逻辑分层是将管理功能针对不同之管理对象映射到事务管理层BML（Business Management Layer），业务管理层SML（Service Management Layer），网络管理层NML（Network Management Layer）和网元管理层EML（Element Management Layer）。再加上物理存在之网元层NEL（Network Element Layer），就构成了TMN之逻辑分层体系结构。从图2-6可以看到，TMN定义之五大管理功能在每一层上都存在，但各层之侧重点不同。这与各层定义

14、之管理范围和对象有关。三、TMN开发平台和开发工具1利用TMN之开发工具开发TMN之必要性TMN之信息体系结构应用OSI系统管理之原则，引入了管理者和代理之概念，强调在面向事物处理之信息交换中采用面向对象之技术。如前所述，TMN是高度强调标准化之网络，故基于TMN标准之产品开发，其标准规范要求严格复杂，使得TMN之实施成为一项具有难度和挑战性之工作；再加上OSI系统管理专业人员之相对缺乏，因此，工具之引入有助于简化TMN之开发，提高开发效率。目前比较流行之基于TMN标准之开发平台有HPOV DM、SUN SEM、IBM TMN平台和DSET之DSG及其系列工具。这些平台可以用于开发全方位之TM

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

16、布式系统生成器DSGDSG是用于顶层TCPIP、OSI和其它协议上构筑分布式并发系统之高级对象请求代理0RB。 DSG将复杂之通信基础设施和面向对象技术相结合，提供构筑分布式计算之软件平台。通信基础设施支持分布式计算中通信域之通信要求。如图4所示，它提供了四种主要之服务：透明远程操作、远程过程调用和消息传递、抽象数据服务及命名服务。借助于并发之面向对象框架，一个复杂之应用可以分解成一组相互通信之并发对象worker，除了支持例如类和多重继承等重要之传统面向对象特征外，为了构筑新之worker类，DSG也支持分布式对象。在一个开放系统中，一个worker可以和其它worker进行通信，而不必去关

17、心它们所处之物理位置。DSG提供给用户用以开发应用之构造块（building block）称为worker。一个worker可以有自己之控制线程，也可以和别之线程共享一个控制线程，每个Worker都有自己之服务访问点SAP（Service Access Point），通过SAP与其它worker通信。Worker是事件驱动之。在Worker内部，由有限状态机FSM（Finite State Machine定义各种动作及处理例程，DSG接受外部事件并分发到相应之动作处理例程进行处理。如图5所示，独占线程之此worker有三个状态，两个SAPs，并且每个SAP之消息队列中都有两个事件。DSG环境通

18、过将这些事件送到相应之事件处理程序中来驱动worker之有限状态机。Worker是分布式之并发对象，DSG用它来支持面向对象之特点，如：类，继承等等。Worker由worker class定义。Worker可以根据需要由应用程序动态创建。在一个UNIX进程中可以创建之Worker个数仅受内存之限制。管理者工具箱由ASN.CC编译器、CMIPROSE协议和管理者代码生成器MCG构成，如图6所示。其中之CMIPROSE协议提供全套符合Q3接口选用之OSI七层协议栈实施。由于TMN在典型之电信环境中以面向对象之信息模型控制和管理物理资源，所有被管理之资源均被抽象为被管对象（M0），被管理系统中之代理

19、帮助管理者通过MO访问被管理资源，又根据ITU-T M.3010建议：管理者与代理之间通过Q3接口通信。为此管理者必须产生与代理通信之CMIP请求。管理者代码生成器读取信息模型（GDMO文件和ASN.1文件），创立代码模板来为每个被定义之MO类产生CMIP请求和CMIP响应。由于所有CMIP数据均由ASN.1符号定义，而上层管理应用可能采用CC+，故管理者应用需要包含ASN.1数据处理代码，管理者工具箱中之ASN C C+编译器提供ASN.1数据到CC+语言之映射，并采用“预处理技术“生成ASN.1数据之低级代码，可见利用DSET工具用户只需编写网管系统之信息模型和相关之抽象数据类型定义文件，

20、然后利用DSET之ASN CC+编译器，管理者代码生成器即可生成管理者部分代码框架。代理工具箱包括可砚化代理生成器VAB、CMIP翻译器、ASN.CC+ Toolkit，其结构见图7。用来开发符合管理目标定义指南GDMO和通用管理信息协议CMIP规定之代理应用.使用DSET独具特色之代理工具箱之最大之好处就是更快、更容易地进行代理应用之开发。DSET在代理应用之开发上为用户做了大量之工作。一个典型之GDMOCM1P代理应用包括三个代码模块：·代理、MIT、MIB之实施·被管理资源之接口代码·后端被管理资源代码第一个模块用于处理代理与MO实施。代理工具箱通过对过滤、

21、特性处理、MO实例之通用支持，自动构作这一个模块。DSET之这一部分做得相当完善，用户只需作少量工作即可完成本模块之创建。对于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed这些CMIP请求，第一个模块中包含有缺省之处理代码框架。这些缺省代码都假定管理者之CMIP请求只与MO打交道。为了适应不同用户之需求，DSET代理工具箱又提供在缺省处理前后调用用户程序之接入点（称为User hooks）。当某CMIP请求需与实际被管资源或数据库打交道时，用户可在相应之PRE-或POST

22、-函数中加入自己之处理代码。例如，当你需要在二层管理应用中发CMIP请求，需望获取实际被管资源之某属性，而该属性又不在相应MO中时你只需在GDMO预定义模板中为此属性定义一PRE-GET函数，并在你自己之定制文件中为此函数编写从实际被管设备取到该属性值之代码即可。DSET之Agent代码在执行每个CMIP请求前都要先检查用户是否在GDMO预定义文件中为此清求定义了PRE-函数，若是，则光执行PRE-函数，并根据返回值决定是否执行缺省处理（PRE-函数返回D-OK则需执行缺省处理，否则Agent向管理者返回正确或错误响应）。同样当Agent执行完缺省处理函数时，也会检查用户是否为该请求定义了PO

23、ST-函数，若是则继续执行POST-函数。至于Agent与MO之间具体是如何实现通信之，用户不必关心，因为DSET已为我们实现了。用户只需关心需要与设备交互之那一部分CMIP请求，为其定制PRE-POST函数即可。第二个模块实现MO与实际被管资源之通信。它之实现依赖于分布式系统生成器DSG所提供“网关处理单元”（gateway）、远程过程调用（RPC）与消息传递机制及MSL语言编译器。通信双方之接口定义由用户在简化之ROSE应用中定义，在DSG中也叫环境，该环境定义了双方之所有操作和相关参数。DSG之CTX编译器编译CTX格式之接口定义并生成接口表。DSG之MSL语言编译器用以编译分布式对象类

24、之定义并生成事件调度表。采用DSG之网关作为MO与实际被管资源间之通信桥梁，网关与MO之间通过定义接口定义文件及各自之MSL文件即可实现通信，网关与被管设备之间采用设备所支持之通信协议来进行通信，例如采用TCPIP协议及Socket机制实现通信。第三个模块对被管理资源进行实际处理。这一模块根据第二个模块中定义之网关与被管设备间之通信机制来实现，与工具没有多大联系。四、TMN开发之关键技术电信管理网技术蕴含了当今电信、计算机、网络通信和软件开发之最新技术，如OSI开放系统互连技术、OSI系统管理技术、计算机网络技术及分布式处理、面向对象之软件工程方法以及高速数据通信技术等。电信管理网应用系统之开

25、发具有巨大之挑战性。工具之引入很大程度上减轻了TMN之开发难度。留给开发人员之最艰巨工作就是接口（interface）之信息建模。尤其是Q3接日之信息建模问题。Q3接口是TMN接口之“旗舰”，Q3接口包括通信模型和信息模型两个部分，通信模型（0SI系统管理）之规范制定之十分完善，并且工具在这方面所作之工作较多，因此，当我们设计和开发各种不同管理业务之TMN系统时，主要是采用一定之方法学，遵循一定之指导原则，针对不同电信领域之信息建模问题。为什么说建模是TMN开发中之关键技术呢？从管理之角度而言，在那些先有国际标准（或事实上之标准），后有设备之情况下，是有可能存在一致性之信息模型之，例如目前SD

26、H和七号信令网之TMN系统存在这样之信息模型标准。但即使这样，在这些TMN系统之实施过程，有可能由于管理需求之不同而对这些模型进行进一步之细化。在那些先有设备而后才有国际标准（或事实上之标准）之设备，而且有之电信设备就无标准而言，由于不同厂家之设备千差万别，这种一致性之信息模型之制定是非常困难之。例如，近年来标准化组织国际电信联盟（ITU-T）、欧洲电信标准组织（ETSI）、网络管理论坛（NMF）和ATM论坛等相继颁布了一些Q3信息模型。但至今没有一个完整之稳定之交换机网元层之Q3信息模型。交换机之Q3信息模型提供了交换机网元之一个抽象之、一般之视图，它应当包含交换机之管理之各个方面。但这是不

27、可能之。因为随着电信技术之不断发展，交换机技术也在不断之发展，交换机之类型不断增加，电信业务不断之引入。我们很难设计一个能够兼容未来交换机之信息模型。如今之交换机已不再是仅仅提供电话之窄带业务，而且也提供象ISDN这样之宽带业务。交换机趋向宽带窄带一体化发展，因此交换机之Q3信息模型是很复杂之，交换机Q3信息建模任务是很艰巨之。五、TMN管理者和代理之开发下面结合我们之开发工作，探讨一下TMN管理者和代理之开发。1管理者之开发基于OSI管理框架之管理者之实施通常被认为是很困难之事，通常，管理者可以划分为三个部分。第一部分是位于人机之间之图形用户接口GUI（Graphical User Inte

28、rfaces），接收操作人员之命令和输入并按照一种统一之格式传送到第二部分管理功能。管理功能提供管理功能服务，例如故障管理，性能管理、配置管理、记费管理，安全管理及其它特定之管理功能。接收到来GUI之操作命令，管理功能必须调用第三部分CMSI API来发送CMIP请求到代理。CMIS API为管理者提供公共管理信息服务支持。大多数之网管应用是基于UNIX平台之，如Solaris，AIX and HP-UX。若GUI是用X-Window来开发之，那么GUI和管理功能之间之接口就不存在了，从实际编程之之角度看，GUI和管理功能都在同一个进程中。上面之管理者实施方案尽管有许多优点，但也存在着不足。首

29、先是费用昂贵。所有之管理工作站都必须是X终端，服务器必须是小型机或大型机。这种方案比采用PC机作客户端加上UNIX服务器之方案要昂贵得多。其次，扩展性不是很好，不同之管理系统之范围是不同之，用户之要求也是不一样之，不是所有之用户都希望在X终端上来行使管理职责。因此，PC机和调终端都应该向用户提供。最后由于X-Window之开发工具比在PC机上之开发工具要少得多。因此最终在我们之开发中，选择了PC机作为管理工作站，SUN Ultral作为服务器。在实际工作中我们将管理者划分为两个部分管理应用（management application）和管理者网关（manager gateway）。如图8所示

30、。管理应用向用户提供图形用户接口GUI并接受用户之命令和输入，按照定义好之消息格式送往管理者网关，由其封装成CMIP请求，调用CMIS API发往代理。同时，管理者网关还要接收来自代理之响应消息和事件报告并按照一定之消息格式送往管理应用模块。但是这种方案也有缺点。由于管理应用和管理者网关之分离，前者位于PC机上，后者位于Ultral工作站上。它们之间之相互作用须通过网络通信来完成。它们之间之接口不再是一个参考点（Reference Point），而是一个物理上之接口，在电信管理网TMN中称为F接口。迄今为止ITU-T一直没能制定出有关F接口之标准，这一部分工作留给了TMN之开发者。鉴于此，我们

31、制定了管理应用和管理者网关之间通信之协议。在开发中，我们选择了PC机作为管理工作站，SUN Ultral作为我们之管理者网关。所有之管理应用都在PC机上。开发人员可以根据各自之喜好来选择不同开发工具，如Java，VC+，VB，PB等。管理者网关执行部分之管理功能并调用CMIS API来发送CMIP请求，接收来自代理之响应消息和事件报告并送往相应之管理应用。管理者网关之数据结构是通过编译信息模型（GDMO文件和ASN.1文件）获得之。它基于DSG环境之。管理者网关必须完成下列转换：数据类型转换：GUI中之数据类型与ASN.1描述之数据类型之间之相互转换；消息格式转换：GUI和管理者网关之间之消息

32、格式与CMIP格式之间之相互转换；协议转换：TCPIP协议与OSI协议之间之相互转换。这意味着管理者网关接收来自管理应用之消息。将其转换为ASN.1之数据格式，并构造出CMIS之参数，调用CMIS API发送CMIP请求。反过来，管理者收到来自代理之消息，解读CMIS参数，构造消息格式，然后送往GUI。GUI和管理者网关之间之消息格式是由我们自己定义之。由于管理应用之复杂性，消息格式之制定参考了CMIS之参数定义和ASN.1之数据类型。管理者网关是采用多线程（multi-thread）编程来实现之。2代理之开发代理之结构如图9所示。为了使代理部分之设计和实现模块化、系统化和简单化，将agent

33、分成两大模块通用代理模块和MO模块进行设计和实现。如图所示，通用agent向下只与MO部分直接通信，而不能与被管资源MR直接进行通信及操作，即通用agent将manager发来之CMIP请求解析后投递给相应之M0，并从MO接收相应之应答信息及其它之事件报告消息。代理之作用是代表管理者管理MO。利用工具之支持，采用面向对象之技术，分为八个步骤进行agent之设计和实现，这八个步骤是：第一步：对信息模型既GDMO文件和ASN.1文件之理解，信息模型是TMN系统开发之基础和关键。特别是对信息模型中对象类和其中各种属性清晰之认识和理解，对于实际之TMN系统来说，其信息模型可能很复杂，其中对象类在数量上

34、可能很多。也就是说，在设计和实现agent之前，必须作到对MO心中有数。第二步：被管对象MO之定制。这一部分是agent设计和实现中之关键部分，工具对这方面之支持也不是很多，特别是涉及到MO与MR之间之通信，更为复杂，故将MO专门作为一个模块进行设计和实现MO和MR之间之通信以及数据和消息格式之转换问题，利用网关原理设计一个网关来解决。第三步：创建内置之M0。所谓内置MO就是指在系统运行时，已经存在之物理实体之抽象。为了保证能对这些物理实体进行管理，必须将这些被管对象之各种固有之属性值和操作预先加以定义。第四步：创建外部服务访问点SAP。如前所述，TMN系统中各个基于分布式处理之worker之

35、间通过SAP进行通信，所以要为agent与管理者manager之间、agent与网关之间创建SAP。第五步：SAP同内置MO之捆绑注册。由于在TMN系统中，agent之所有操作是针对MO之，即所有之CMIP请求经解析后必须送到相应之M0，而基于DSG平台之worker之间之通信是通过SAP来实现之。因而，在系统处理过程中，当进行信息之传输时，必须知道相应MO之SAP，所以，在agent之设计过程中，必须为内置MO注册某一个SAP。第六步：agent配置。对agent中有些参数必须加以配置和说明。如队列长度、流量控制门限值、agent处理单元组中worker之最大最小数目。报告之处理方式、同步通

36、信方式中超时门限等。第七步：agent用户函数之编写，如agent worker初始化函数、子代理函数等之编写。第八步：将所有函数编译，连接生成可运行之agent。MO模块是agent设计中之一个重要而又复杂之部分。这是由于，一方面工具对该部分之支持不是很多：另一方面，用户之大部分处理函数位于这一部分；最主要之还在于它与被管资源要跨平台，在不同之环境下进行通信。MO模块之设计思想是在MO和MR之间设计一个网关（gateway），来实现两者之间之消息、数据、协议等转换。MO部分之主要功能是解析，执行来自管理者之CMIP请求，维持各MO之属性值同被管资源之一致性，生成CMIP请求结果，并上报通用a

37、gent模块，同时与MR通信，接收和处理来自MR之事件报告信息，并转发给通用agent。MO部分有大量之用户定制工作。工具只能完成其中一半之工作，而另一半工作都需要用户自己去定制。用户定制分为两大类；第一类是PRE-POST-函数。PRE-POST-函数之主要功能是在agent正式处理CMIP请求之前之后与被管资源打交道，传送数据到MR或从MR获取数据并做一些简单之处理。通过对这些PRE-POST-函数之执行，可以确保代理能够真实地反映出被管资源之运行状态。PRE-POST-函数分为两个层次：MO级别和属性级别。MO级别层次较高，所有对该对象类之CMIP操作都会调用MO级别之PRE-POST-

38、函数。属性级别层次低，只有对该属性之CMIP操作才会调用这些函数。DSET工具只提供了PRE-POST-函数之人口参数和返回值，具体之代码需要完全由用户自己编写。由于agent与被管资源有两种不同之通信方式，不同之方式会导致不同之编程结构和运行效率，如果是同步方式，编程较为简单，但会阻塞被管资源，适合于由大量数据返回之情况。异步方式不会阻塞被管资源，但编程需要作特殊处理，根据不同之返回值做不同之处理，适合于数据不多之情况，在选择通信方式时还要根据MO之实现方式来确定。比如，MO若采用Doer来实现，则只能用同步方式。第二类是动作、事件报告和通知之处理，动作之处理相对比较容易，只需考虑其通信方式

39、采用同步还是异步方式。对事件报告和通知之处理比较复杂。首先，需要对事件进行分类，对不同类别之事件采用不同之处理方法，由哪一个事件前向鉴别器EFD（Event Forwarding Discriminator）来处理等等。比如，告警事件之处理就可以单独成为一类。其次，对每一类事件需要确定相应之EFD之条件是什么，哪些需要上报管理应用，哪些不需要。是否需要记入日志，这些日志记录之维护策略等等。除了这两类定制外，MO也存在着优化问题。比如MO用worker还是Doer来实现，通信方式采用同步还是异步，面向连接还是无连接等等，都会影响整个代理之性能。如果MO要永久存储，我们采用文件方式。因为目前DSE

40、T之工具只支持Versant、ODI这两种面向对象数据库管理系统OODBMS，对于0racle，Sybase等数据库之接口还需要用户自己实现。MO定制之工作量完全由信息模型之规模和复杂程度决定，一个信息模型之对象类越多，对象之间之关系越复杂（比如一个对象类中之属性改变会影响别之类），会导致定制工作之工作量和复杂程度大大增加。代理者agent在执行管理者发来之CMIP请求时必须保持与被管资源MR进行通信，将manager传送来之消息和数据转发给MR，并要从MR获取必要之数据来完成其操作，同时，它还要接收来自MR之事件报告，并将这些事件上报给manager。由上述可知，代理与被管资源MR之间之通信接口实际上是指MO与MR之间之通信接口。大部分MO是对实际被管资源之模拟，这些MO要与被管资源通信。若让这些MO直接与被管资源通信，则存在以下几个方面之弊端：·由于MO模块本身不具备错误信息检测功能（当然也可在此设计该项功能，但增加了MO模块之复杂性），如果将上向发来之所有信息（包括某些不恰当之信息）全部转发给MR，不仅无此必要，而且增加了数据通信量；同理MR上发之信息也无必要全部发送给MO。·当被管资源向MO发消息时，由于MIT对