基于TMN／TOM模型的架构

　　图给出了基于TMN观点的架构模型。在对架构进行实现之前，首先必须清楚下一代网络管理的需求，也必须解决那些为客户带来更快更多利润的业务是如何通过相关业务执行、业务保证和计费得到支持的问题，同时还必须解决如何整合传统系统和其他资产的问题，以及传统运营机制如何向新的机制演变的问题。

　　图 基于TMN观点的架构

　　（1）管理门户

　　自顾的管理门户可能构建于内部，并通过合作的方式得到。管理解决方案供应商并不希望通过销售这种门户来赚钱，但如果没有这个门户，可能就会造成经济上的损失，因为门户看起来更像是为昨天的技术准各的。实际上，自顾的管理门户是用户进入OSS／BSS解决方案的通道。

　　门户首先通过轻量级目录接人协议（LDAP）对用户进行认证和授权，而且LDAP能够将指针指向其他管理应用，客户，业务，或者允许用户访问的网络数据。大多数的数据本身也许并不驻留在目录中，而是驻留在DBMS中。只有那些选择性较强，很少改动且被频繁访问的数据才暂留缓存在目录内，否则，目录包含的仅仅是指向真实数据的指针。

　　通过一个装有Java应用程序的网页浏览器可以访问门户，因为这些Java应用程序对于表示层是必需的。而且，通过XML技术建立的表示抽象总线允许与其他技术进行灵活的接口。因此，门户不仅可以作为设置和修改命令的通道，同时也能根据用户的授权允许用户检查业务的可用性，性能状态，业务水平，故障上报及已预定业务的计费报告等。

　　（2）应用事务处理总线

　　基于企业应用整合技术的应用事务处理总线，能够提供一种高度灵活和高度可伸缩的应用平台。许多中间件供应商具有一些固化的工作流程引擎。另外，也可以通过其他供应商的工具来开发相应的总线。然而，另外一种可能的解决方案将会使用供应商已经习惯的中间件和工作流程引擎，并可能需要建立一种包含未来管理应用的EJB总线。而且，使用基于Java的体系结构将向供应商提供一种高度灵活的，高度可伸缩的应用平台。通过EJB技术建立的应用事务处理总线支持各种与业务相关的应用的即插即用，其中的一些应用还可能访问客户和业务数据。

　　使用开放数据库互联或Java数据库互联适配器支持的对象，并通过相同的应用事务处理总线就可以访问数据。这里，数据与应用的完全分离显得非常重要，它保证了新应用对数据的访问和使用并不依赖于其他应用，从而能够将多个应用合并为一个整体的解决方案并支持应用的单独部署；而且，数据与应用的分离也帮助生产机构明确了哪些产品需要新建，哪些产品仅需要重用即可。因此，数据模型的实现将通过重用的方式进行，而应用必须具有足够的独立性。

　　（3）网络和信息技术基础设施的管理

　　在目前所描述的层次下面是经典的故障、配置、记账、性能和安全系统，也即元素管理器和网络管理器。这些管理器是系统级的，反映了物理元素所组成的网络的真实情况。信息包括用于预测额外容量的信息，用于为用法进行计费的信息或用于提供数据的信息。

　　除了现有的元素以外，网络中不断出现一些新的元素，其中一些还具有新的管理行为。大多数的元素或网络管理系统都有非常明确的目标。通常，因为元素的特性迫使其选择特定的实现方式，所以这些元素或网络管理系统能很好地服务于特定的组仵。然而，元素或网络管理系统需要有一个背向的接口，从而更加合乎标准，也将意味着接口的改变不会非常频繁，运行非常可靠并接近于实时要求。特别是对于网络管理软件供应商而言，这是一个支持业务／应用与网络和元素管理应用进行对话的内部接口.通过该接口就可以呈送特定的供给参数，收集定义完善的告警信号，性能报告和用法统计，或者是文件中收集的数据指针。

　　（4）数据模型

　　有三种主要的数据模型：客户信息模型、业务信息模型和网络信息模型。

　　①客户信息模型。客户信息模型包括与特定客户信息进行接口的数据和处理行为，如业务提供商提供的任何业务的任何用户所要捕获的所有信息，用户认证和授权信息，指向每一个客户的业务激活指针等。所有与客户相关的信息都将以逻辑数据模型的形式被保存，且能够被任何需要访问该信息的应用所访问。定义完善且容易实现的客户信息模型应该能够被所有的集成管理方案所重用，也应该只能由一个开发组织来设计和构建。

　　②业务信息模型。业务信息模型包括业务提供商提供的所有业务的定义。对特定的用户来说，需要对所有使用中的业务库和它们的当前状态进行随时的更新。每一个定义的业务都应该携带一个业务界面，以便支持SLA级别的选择。而且，业务信息模型必须考虑将SLA规格映射到QoS级别的灵活性，以及QoS级别类型和SLA规格的可扩展性。业务定义则需要考虑业务的继承性，与其他业务侧面关联性，以及创建新业务的行为支持。