五、TMN管理者和代理的开发

　　下面结合我们的开发工作，探讨一下TMN管理者和代理的开发。

　　1.管理者的开发

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

　　大多数的网管应用是基于UNIX平台的，如Solaris，AIXandHP-UX。若GUI是用X-Window来开发的，那么GUI和管理功能之间的接口就不存在了，从实际编程的的角度看，GUI和管理功能都在同一个进程中。

　　上面的管理者实施方案尽管有许多优点，但也存在着不足。首先是费用昂贵。所有的管理工作站都必须是X终端，服务器必须是小型机或大型机。这种方案比采用PC机作客户端加上UNIX服务器的方案要昂贵得多。其次，扩展性不是很好，不同的`管理系统的范围是不同的，用户的要求也是不一样的，不是所有的用户都希望在X终端上来行使管理职责。因此，PC机和调终端都应该向用户提供。最后由于X-Window的开发工具比在PC机上的开发工具要少得多。因此最终在我们的开发中，选择了PC机作为管理工作站，SUNUltral作为服务器。

　　在实际工作中我们将管理者划分为两个部分——管理应用(managementapplication)和管理者网关(managergateway)。如图8所示。

　　管理应用向用户提供图形用户接口GUI并接受用户的命令和输入，按照定义好的消息格式送往管理者网关，由其封装成CMIP请求，调用CMISAPI发往代理。同时，管理者网关还要接收来自代理的响应消息和事件报告并按照一定的消息格式送往管理应用模块。

　　但是这种方案也有缺点。由于管理应用和管理者网关的分离，前者位于PC机上，后者位于Ultral工作站上。它们之间的相互作用须通过网络通信来完成。它们之间的接口不再是一个参考点(ReferencePoint)，而是一个物理上的接口，在电信管理网TMN中称为F接口。迄今为止ITU-T一直没能制定出有关F接口的标准，这一部分工作留给了TMN的开发者。鉴于此，我们制定了管理应用和管理者网关之间通信的协议。

　　在开发中，我们选择了PC机作为管理工作站，SUNUltral作为我们的管理者网关。所有的管理应用都在PC机上。开发人员可以根据各自的喜好来选择不同开发工具，如Java，VC++，VB，PB等。管理者网关执行部分的管理功能并调用CMISAPI来发送CMIP请求，接收来自代理的响应消息和事件报告并送往相应的管理应用。

　　管理者网关的数据结构是通过编译信息模型(GDMO文件和ASN.1文件)获得的。它基于DSG环境的。管理者网关必须完成下列转换：

　　数据类型转换：GUI中的数据类型与ASN.1描述的数据类型之间的相互转换;

　　消息格式转换：GUI和管理者网关之间的消息格式与CMIP格式之间的相互转换;

　　协议转换：TCP/IP协议与OSI协议之间的相互转换。

　　这意味着管理者网关接收来自管理应用的消息。将其转换为ASN.1的数据格式，并构造出CMIS的参数，调用CMISAPI发送CMIP请求。反过来，管理者收到来自代理的消息，解读CMIS参数，构造消息格式，然后送往GUI。GUI和管理者网关之间的消息格式是由我们自己定义的。由于管理应用的复杂性，消息格式的制定参考了CMIS的参数定义和ASN.1的数据类型。

　　管理者网关是采用多线程(multi-thread)编程来实现的。

　　2.代理的开发

　　代理的结构如图9所示。

　　为了使代理部分的设计和实现模块化、系统化和简单化，将agent分成两大模块——通用代理模块和MO模块——进行设计和实现。如图所示，通用agent向下只与MO部分直接通信，而不能与被管资源MR直接进行通信及操作，即通用agent将manager发来的CMIP请求解析后投递给相应的M0，并从MO接收相应的应答信息及其它的事件报告消息。

　　代理的作用是代表管理者管理MO。利用工具的支持，采用面向对象的技术，分为八个步骤进行agent的设计和实现，这八个步骤是：