第三个模块对被管理资源进行实际处理。这一模块根据第二个模块中定义的网关与被管设备间的通信机制来实现，与工具没有多大联系。
四、TMN开发的关键技术
电信管理网技术蕴含了当今电信、计算机、网络通信和软件开发的最新技术，如OSI开放系统互连技术、OSI系统管理技术、计算机网络技术及分布式处理、面向对象的软件工程方法以及高速数据通信技术等。电信管理网应用系统的开发具有巨大的挑战性。
工具的引入很大程度上减轻了TMN的开发难度。留给开发人员的最艰巨工作就是接口（interface）的信息建模。尤其是Q3接日的信息建模问题。
Q3接口是TMN接口的“旗舰”，Q3接口包括通信模型和信息模型两个部分，通信模型（0SI系统管理）的规范制定的十分完善，并且工具在这方面所作的工作较多，因此，当我们设计和开发各种不同管理业务的TMN系统时，主要是采用一定的方法学，遵循一定的指导原则，针对不同电信领域的信息建模问题。
为什么说建模是TMN开发中的关键技术呢？从管理的角度而言，在那些先有国际标准（或事实上的标准），后有设备的情况下，是有可能存在一致性的信息模型的，例如目前SDH和七号信令网的TMN系统存在这样的信息模型标准。但即使这样，在这些TMN系统的实施过程，有可能由于管理需求的不同而对这些模型进行进一步的细化。在那些先有设备而后才有国际标准（或事实上的标准）的设备，而且有的电信设备就无标准而言，由于不同厂家的设备千差万别，这种一致性的信息模型的制定是非常困难的。
例如，近年来标准化组织国际电信联盟（ITU-T）、欧洲电信标准组织（ETSI）、网络管理论坛（NMF）和ATM论坛等相继颁布了一些Q3信息模型。但至今没有一个完整的稳定的交换机网元层的Q3信息模型。交换机的Q3信息模型提供了交换机网元的一个抽象的、一般的视图，它应当包含交换机的管理的各个方面。但这是不可能的。因为随着电信技术的不断发展，交换机技术也在不断的发展，交换机的类型不断增加，电信业务不断的引入。我们很难设计一个能够兼容未来交换机的信息模型。如今的交换机已不再是仅仅提供电话的窄带业务，而且也提供象ISDN这样的宽带业务。交换机趋向宽带窄带一体化发展，因此交换机的Q3信息模型是很复杂的，交换机Q3信息建模任务是很艰巨的。
五、TMN管理者和代理的开发
下面结合我们的开发工作，探讨一下TMN管理者和代理的开发。
1．管理者的开发
基于OSI管理框架的管理者的实施通常被认为是很困难的事，通常，管理者可以划分为三个部分。第一部分是位于人机之间的图形用户接口GUI（Graphical User Interfaces），接收操作人员的命令和输入并按照一种统一的格式传送到第二部分——管理功能。管理功能提供管理功能服务，例如故障管理，性能管理、配置管理、记费管理，安全管理及其它特定的管理功能。接收到来GUI的操作命令，管理功能必须调用第三部分——CMSI API来发送CMIP请求到代理。CMIS API为管理者提供公共管理信息服务支持。
大多数的网管应用是基于UNIX平台的，如Solaris，AIX and HP-UX。若GUI是用X-Window来开发的，那么GUI和管理功能之间的接口就不存在了，从实际编程的的角度看，GUI和管理功能都在同一个进程中。
上面的管理者实施方案尽管有许多优点，但也存在着不足。首先是费用昂贵。所有的管理工作站都必须是X终端，服务器必须是小型机或大型机。这种方案比采用PC机作客户端加上UNIX服务器的方案要昂贵得多。其次，扩展性不是很好，不同的管理系统的范围是不同的，用户的要求也是不一样的，不是所有的用户都希望在X终端上来行使管理职责。因此，PC机和调终端都应该向用户提供。最后由于X-Window的开发工具比在PC机上的开发工具要少得多。因此最终在我们的开发中，选择了PC机作为管理工作站，SUN Ultral作为服务器。
在实际工作中我们将管理者划分为两个部分——管理应用（management application）和管理者网关（manager gateway）。如图8所示。
管理应用向用户提供图形用户接口GUI并接受用户的命令和输入，按照定义好的消息格式送往管理者网关，由其封装成CMIP请求，调用CMIS API发往代理。同时，管理者网关还要接收来自代理的响应消息和事件报告并按照一定的消息格式送往管理应用模块。
但是这种方案也有缺点。由于管理应用和管理者网关的分离，前者位于PC机上，后者位于Ultral工作站上。它们之间的相互作用须通过网络通信来完成。它们之间的接口不再是一个参考点（Reference Point），而是一个物理上的接口，在电信管理网TMN中称为F接口。迄今为止ITU-T一直没能制定出有关F接口的标准，这一部分工作留给了TMN的开发者。鉴于此，我们制定了管理应用和管理者网关之间通信的协议。
在开发中，我们选择了PC机作为管理工作站，SUN Ultral作为我们的管理者网关。所有的管理应用都在PC机上。开发人员可以根据各自的喜好来选择不同开发工具，如Java，VC++，VB，PB等。管理者网关执行部分的管理功能并调用CMIS API来发送CMIP请求，接收来自代理的响应消息和事件报告并送往相应的管理应用。
管理者网关的数据结构是通过编译信息模型（GDMO文件和ASN.1文件）获得的。它基于DSG环境的。管理者网关必须完成下列转换：
数据类型转换：GUI中的数据类型与ASN.1描述的数据类型之间的相互转换；
消息格式转换：GUI和管理者网关之间的消息格式与CMIP格式之间的相互转换；
协议转换：TCP／IP协议与OSI协议之间的相互转换。
这意味着管理者网关接收来自管理应用的消息。将其转换为ASN.1的数据格式，并构造出CMIS的参数，调用CMIS API发送CMIP请求。反过来，管理者收到来自代理的消息，解读CMIS参数，构造消息格式，然后送往GUI。GUI和管理者网关之间的消息格式是由我们自己定义的。由于管理应用的复杂性，消息格式的制定参考了CMIS的参数定义和ASN.1的数据类型。
管理者网关是采用多线程（multi-thread）编程来实现的。
2．代理的开发
代理的结构如图9所示。
为了使代理部分的设计和实现模块化、系统化和简单化，将agent分成两大模块——通用代理模块和MO模块——进行设计和实现。如图所示，通用agent向下只与MO部分直接通信，而不能与被管资源MR直接进行通信及操作，即通用agent将manager发来的CMIP请求解析后投递给相应的M0，并从MO接收相应的应答信息及其它的事件报告消息。
代理的作用是代表管理者管理MO。利用工具的支持，采用面向对象的技术，分为八个步骤进行agent的设计和实现，这八个步骤是：