网络管理系统及内部通信方法、网管服务端和网管客户端

摘要

本发明公开了一种网络管理系统，包括：网管服务端、第一网管客户端和第二网管客户端；其中：第一网管客户端用于生成通知消息，并发送该通知消息至网管服务端；所述通知消息中包括通知信息和接收方信息，所述接收方信息为接收方用户和/或用户组信息；网管服务端用于接收所述通知消息，并发送该通知消息；第二网管客户端用于从网管服务端接收所述通知消息，将该通知消息中的通知信息显示；所述第二网管客户端为所述通知消息中，接收方信息对应用户所登录的网管客户端。本发明中还公开了一种网管服务端、一种网管客户端和一种网络管理系统内部通信方法。

说明书

技术领域

本发明涉及网络通信技术领域，特别涉及一种网络管理系统、一种网络管理系统内部通信方法、一种网管服务端和一种网管客户端。

背景技术

网络管理系统(NMS)是对各种电信设备进行管理的系统。随着电信网络规模的不断扩大，网管系统的复杂度也不断增长，网管系统的管理与维护模式也由最初单个人员的集中式管理演变为众多维护人员相互协作。同一网管系统中一般将用户按区域或职责划分成不同用户组。

传统网管系统大多只关注于具体的业务，没有考虑维护人员间相互协作的问题，所以维护人员相互间通知信息的传送，必须借助于第三方工具，如邮件、电话、即时消息软件等。

但是维护人员借助于第三方工具进行通知信息传送存在下述问题：

邮件不具备实时性；

电话很难实现众多维护人员间同时进行沟通与协作的需求，还会大大增加维护过程中的通信成本；

短信存在的缺点有信息录入不方便，群发功能需要依赖于具体手机功能，而且短信一般都有长度限制，一次所能发送的信息非常少。

即时消息软件由于与公共网络连接，降低了系统的安全性，且在很多网管系统中即时消息软件的端口会被禁用，另外，即时消息软件中的用户信息无法与网管系统的用户信息集成在一起，必须在第三方即时消息系统中重新维护一套用户信息，增加了额外的维护工作量。

发明内容

本发明实施例提供了一种网络管理系统、网络管理系统内部通信方法、网管服务端和网管客户端，能够及时、安全地实现网络管理系统中用户之间的沟通。

本发明实施例提供的网络管理系统，包括：网管服务端、第一网管客户端和第二网管客户端；所述第一网管客户端和第二网管客户端分别与网管服务端进行通信；其中：

第一网管客户端用于生成通知消息，并发送该通知消息至网管服务端；所述通知消息中包括通知信息和接收方信息，所述接收方信息为接收方用户和/或用户组信息；

网管服务端用于接收所述通知消息，并发送该通知消息；

第二网管客户端用于从网管服务端接收所述通知消息，将该通知消息中的通知信息提供给登录用户；所述第二网管客户端为所述通知消息中，接收方信息对应用户所登录的网管客户端。

本发明实施例提供的网管服务端包括：

接收模块，用于接收来自网管客户端的通知消息；

通知服务模块用于从所述接收模块获取所述通知消息，在通知消息中设置接收该通知消息的网管客户端地址信息，并将该通知消息传送给发送模块；

发送模块用于发送所接收的通知消息至所述地址信息对应的网管客户端。

本发明实施例提供的网管客户端包括：

通知消息生成模块用于生成通知消息，将该通知消息发送给发送模块；所述通知消息中包括通知信息和接收方信息，所述接收方信息为接收方用户和/或用户组信息；

发送模块用于发送所接收的通知消息至网管服务端；

接收模块用于从网管服务端接收通知消息，并将接收的通知消息传送给通知信息显示模块；

通知信息显示模块用于从接收模块接收通知消息，并将该通知消息中的通知信息显示。

本发明实施例提供的网络管理内部通信方法，包括：

第一网管客户端生成通知消息后，发送该通知消息；所述通知消息中包括通知信息和接收方信息，所述接收方信息为接收方用户和/或用户组信息；

网管服务端从所述第一网管客户端接收所述通知消息，并发送该通知消息；

第二网管客户端从网管服务端接收所述通知消息，将该通知消息中的通知信息提供给登录用户；所述第二网管客户端为所述通知消息中，接收方信息对应用户登录的网管客户端。

在本发明提供的上述实施例中，网管客户端之间需要交互的通知信息，直接通过网管服务端转发，而无需经由外部网络，保证了通知消息传送的及时性和安全性；相对于现有的各种通知信息传送方案，提高了网络管理系统中沟通与协作的效率，也提高了网络维护工作的效率，并且可以降低维护人员之间进行远程协作的成本。

附图说明

图1为网络管理系统第一实施例的组成示意图；

图2为网管服务端第一实施例的组成示意图；

图3为网管服务端第二实施例的组成示意图；

图4为网管服务端第三实施例的组成示意图；

图5为网管服务端第四实施例的组成示意图；

图6为网管服务端第五实施例的组成示意图；

图7为网管服务端第六实施例的组成示意图；

图8为网管客户端第一实施例的组成示意图；

图9为网管客户端第二实施例的组成示意图；

图10为网管客户端第三实施例的组成示意图；

图11为网管客户端第四实施例的组成示意图；

图12为网管客户端第五实施例的组成示意图；

图13为网络管理系统内部通信方法第一实施例的流程图；

图14为网络管理系统内部通信方法第二实施例的流程图；

图15为网络管理系统内部通信方法第三实施例的流程图；

图16为网络管理系统内部通信方法第四实施例的流程图；

图17为网络管理系统内部通信方法第五实施例的流程图；

图18为网络管理系统内部通信方法第六实施例中的通知查询流程图。

具体实施方式

本发明网络管理系统的具体实施例如图1所示，包括网管服务端、第一网管客户端和第二网管客户端。其中：

第一网管客户端用于生成通知消息，并发送该通知消息至网管服务端；所述通知消息中包括通知信息和接收方信息，上述接收方信息为接收方用户和/或用户组信息。

网管服务端用于接收所述通知消息，并发送该通知消息。

第二网管客户端用于从网管服务端接收所述通知消息，将该通知消息中的通知信息显示；所述第二网管客户端为所述通知消息中，接收方信息所对应用户所登录的网管客户端。

上述接收方用户和/或用户组信息中，只包括一个用户的用户信息时，本实施例的网络管理系统中，接收通知消息的第二网管客户端的数量为一个；在包括一个或多个用户信息和一个或多个用户组信息，或者包括多个用户信息，或者包括一个或多个用户组信息时，本实施例的网络管理系统中，接收通知的第二网管客户端的数量对应为多个。

具体地，本实施例中，网管服务端和网管客户端之间可以采用CORBA协议通信。即，第一网管客户端生成通知消息后，将该通知消息转换为CORBA协议支持的格式，如转换为IDL语言格式，并采用CORBA协议的编码形式进行编码，如进行CDR编码，然后发送。网管服务端接收到来自第一网管客户端的通知消息后，采用对应的CORBA协议的解码形式进行解码，再转换为网管服务端支持的格式；此后，再在发送时，再将通知消息转换为CORBA协议支持的格式，并采用CORBA协议的编码形式进行编码，然后发送。而第二网管客户端接收到通知消息后，采用对应的CORBA协议的解码形式进行解码，再转换为该网管客户端支持的格式，此后再获取出通知消息中的通知信息，并提供给用户。

在上述网络管理系统实施例中，可以通过多种不同的网管服务端和网管客户端来实现，以下详细说明。

基于上述网络管理系统实施例，网管服务端包括如下六个实施例：

网管服务端的第一实施例如图2所示，包括接收模块、发送模块和通知服务模块。其中：

接收模块用于接收来自网管客户端的通知消息，并将通知消息传送给通知服务模块。

通知服务模块用于接收来自接收模块的通知消息，并将该通知消息转发给发送模块。

发送模块用于接收来自发送模块的通知消息。

在网管服务端的第二实施例中，网管服务端采用CORBA协议接口与网管客户端通信。具体地，本实施例的组成如图3所示。图3基于图2的结构，在接收模块中具体包括：解码模块和第一转换模块；而在发送模块中具体包括：第二转换模块和编码模块。其中：

解码模块用于接收采用CORBA协议编码格式，如CDR编码格式编码的数据包；这接收的数据包中包括通知消息，对数据包进行解码后，将解码后CORBA协议格式，如IDL语言格式的通知消息发送至第一转换模块。

第一转换模块用于将所述解码后的通知消息转换为所述网管服务端内部支持的格式，并将转换后的通知消息传送给通知服务模块。

第二转换模块用于接收来自通知服务模块的通知消息，并将该通知消息转换为CORBA协议格式，如IDL语言格式，然后传送给编码模块；

编码模块用于将来自第二转换模块的通知消息编码为CORBA协议编码格式，如CDR编码格式的数据包，并发送编码后的数据包。

网管服务端的第三实施例和第四实施例，可以基于上述网管服务端的第一或第二实施例，与该两实施例的区别仅在于通知服务模块中采用了不同的具体实现形式。

网管服务端第三实施例基于第一实施例或第二实施例，区别只是在于通知服务模块中具体包括多个转发模块，该多个转发模块与多个连接到所述网管服务端的网管客户端一一对应。图4以基于第二实施例为例，示出了本实施例的结构示意图。

则本实施例中，每个转发模块用于从接收模块接收通知消息，并将接收的通知消息通过发送模块，发送到该转发模块对应的网管客户端；转发模块可以直接或根据来自网管客户端的查询请求，发送所述通知消息。

这里，转发模块在通过发送模块发送通知消息时，有两种方式：一种是在转发模块自身中设置了对应网管客户端地址信息，包括IP地址和端口时，直接将该地址信息设置在通知消息中，则通过发送模块发送后，能够将该通知消息发送至对应的网管客户端，这种方式效率较高；另一种是，在转发模块自身中不设置对应网管客户端地址信息，则转发模块在收到通知消息时，等待来自网管客户端的查询请求，在收到该请求后，根据该请求中包括的网管客户端地址信息将通知消息发送给该网管客户端。

在本实施例中，上述多个转发模块的数量，可以是与所有连接到网管服务端的网管客户端的数量相同，则本实施例中，网管服务端将接收到的通知消息发送给所有与自身连接的网管客户端。这些网管客户端接收到通知消息后，再根据通知消息中的接收方用户信息，确定是否应该接收该通知消息，如果应该，则将通知消息中的通知信息显示或以其他方式提供给用户；否则，丢弃该消息。

网管服务端第四实施例基于网管服务端的第一实施例或第二实施例，区别只是在于通知服务模块中具体包括过滤模块和多个转发模块，该多个转发模块与多个连接到所述网管服务端的网管客户端一一对应。图5以基于第二实施例为例，示出了本实施例的结构示意图。

则本实施例中，接收模块在将通知消息传送给通知服务模块中的过滤模块。

过滤模块，解析出该通知消息中包括的接收方用户和/或用户组信息，确定与该接收方用户和/或用户组信息匹配的所有转发模块，并将所接收的通知消息发送给所确定出的所有转发模块。

转发模块，将接收到的通知消息通过发送模块，直接或根据来自网管客户端的查询请求，发送到该转发模块对应的网管客户端。

如图6所示，为网管服务端的第五实施例的组成，本实施例基于网管服务端的第四实施例。从图6可以看出，在第四实施例的基础上，网管服务端中进一步包括了安全模块；通知服务模块中进一步包括了注册服务模块。其中：

注册服务模块用于通过接收模块，接收来自网管客户端的通知注册请求，并将该通知注册请求转发给安全模块；以及用于接收安全模块返回的会话标识ID，生成一个包括该会话ID的通知接收对象，即第四实施例中所提及的转发模块。

安全模块用于接收来自注册服务模块的通知注册请求，根据该通知注册请求为对应网管客户端分配会话ID，将该会话ID返回给注册服务模块，并存储所述对应网管客户端的登录用户与所述会话ID的对应关系；

通知服务模块中的过滤模块接收通知消息后，解析出该通知消息中包括的接收方用户和/或用户组信息，并与安全模块交互，确定所述接收方用户和/或用户组信息对应的会话ID，并将所接收的通知消息发送至所有包括所确定出的会话ID的通知接收对象。

在本实施例中，通知接收对象为注册服务模块在通知服务模块中创建的一个对象，例如为C++语言中的对象，该通知接收对象中除会话ID外，具体可以再包括消息接收接口和消息发送代理等。其中，消息接收接口用于从过滤模块接收通知消息，消息发送代理用于在通知消息中设置对应网管客户端的地址信息，并将设置了地址信息的通知消息传送给发送模块。

在创建通知接收对象时，如果网管服务端与网管客户端采用推模式通信，则消息发送代理中可以设置该通知接收对象对应的网管客户端地址信息；而如果网管服务端与网管客户端之间采用拉模式通信，则消息发送代理中不设置对应的网管客户端地址信息。则对应地，通知接收对象中的消息发送代理在将通知消息发送给网管客户端时，可以主动将自身中包括的地址信息设置在通知消息中后，通过发送模块发送给网管客户端；也可以等待来自网管客户端的请求，再根据该请求中包括的网管客户端的地址信息，将该地址信息设置在通知消息中后，通过发送模块发送至网管客户端。

另外，在第三实施例中，也可以与本实施例类似地，包括安全模块和注册服务模块，并由注册服务模块在接收到通知注册请求后，为对应客户端生成通知接收对象，并由通知接收对象作为转发模块实现通知消息的转发。

网管服务端的第六实施例基于网管服务端的以上各个实施例。以基于第五实施例为例，如图7所示，网管服务端中进一步包括：通知消息存储模块和查询模块。上述网管服务端各个实施例中，通知服务模块在接收到通知消息后，进一步将该通知消息存储到通知消息存储模块中，以供查询模块查询。

查询模块用于通过接收模块，接收来自网管客户端的通知消息查询请求，该查询请求中包括网管客户端的登录用户信息，再从通知消息存储模块中查找通知消息，并将查找到的接收方用户和/或用户组信息包括所述登录用户信息的通知消息，通过发送模块返回给发起查询请求的网管客户端。

在本实施例中，通知服务模块在向通知消息存储模块中存储通知消息时，可以进一步为存储的通知消息设置时间戳；则，查询模块接收到的通知消息查询请求中可以包括：时间段参数或条数参数。

当通知消息查询请求中包括时间段参数时，查询模块从存储的通知消息中查找所述查询请求对应的通知消息包括：查询模块查找所存储的通知消息中，属于所述时间段参数，并且其中的接收方信息包括所述登录用户信息的通知消息。

当所述通知消息查询请求中包括条数参数时，查询模块从存储的通知消息中查找所述查询请求对应的通知消息包括：查询模块查找所存储的通知消息中，接收方信息包括所述登录用户信息的通知消息，并从所查找到的通知消息中根据所述条数参数选择最新的通知消息返回给客户端。

本实施例中，在通知服务模块中有过滤模块的情况下，具体可以由通知服务模块中的过滤模块进行通知消息的存储。在通知服务模块中没有过滤模块，而接收模块将接收的通知消息传送给各个转发模块的情况下，接收模块也可以将通知消息传送给通知服务模块，由其自身进行通知消息的存储。

基于上述网络管理系统实施例，网管客户端包括如下实施例：

网管客户端的第一实施例如图8所示，包括通知消息生成模块、发送模块、接收模块和通知信息显示模块。其中：

通知消息生成模块用于生成通知消息，将该通知消息发送给发送模块。该通知消息中包括通知信息和接收方信息，具体地，接收方信息为接收方用户和/或用户组信息。

发送模块用于将来自通知消息生成模块的通知消息发送给网管服务端。

接收模块用于从网管服务端接收通知消息，并将接收的通知消息传送给通知信息显示模块。

通知信息显示模块用于从接收模块接收通知消息，并将该通知消息中的通知信息提供给登录用户。

网管客户端的第二实施例如图9所示，其基于网管客户端的第一实施例，具体区别在于，发送模块中包括：第一转换模块和编码模块；接收模块包括：解码模块和第二转换模块。其中：

第一转换模块用于接收来自通知消息生成模块的通知消息，并将该通知消息转换为CORBA协议格式，如IDL语言格式，然后传送给编码模块。

所述编码模块用于将来自第一转换模块的通知消息编码为CORBA协议编码格式，如CDR编码格式的数据包，并发送所述编码后的数据包至网管服务端。

所述解码模块用于从网管服务端接收采用CORBA协议编码格式编码的数据包，所述数据包中包括通知消息，对所述数据包进行解码后，将解码出的CORBA协议格式的通知消息发送至第二转换模块。

所述第二转换模块用于接收所述CORBA协议格式的通知消息，将该通知消息转换为所述网管客户端内部支持的格式，并将转换后的通知消息传送给通知信息显示模块。

在上述第一实施例和第二实施例的基础上，网管客户端的第三实施例中进一步可以包括：过滤模块。以基于第二实施例为例，第三实施例如图10所示。其中，过滤模块用于接收上述接收模块发送给通知信息显示模块的通知消息，如果识别出该通知消息中的接收方用户和/或用户组信息包括当前登录用户信息，将该通知消息发送给通知信息显示模块；否则，丢弃该通知消息，不将该通知消息发送给通知信息显示模块。

在上述第一、二、三实施例的基础上，网管客户端的第四实施例中进一步可以包括：安全模块。以基于第三实施例为例，第四实施例如图11所示。其中，安全模块用于存储所述网管客户端所在的网络管理系统中的用户和用户组信息。

则在生成通知消息前，通知消息生成模块从所述安全模块中获取用户和用户组信息，并提供给用户，供用户从中选择通知消息的接收方用户和/或用户组信息，然后获取用户选择的接收方用户和/或用户组信息，将其设置在通知消息中作为接收方信息。

在上述四个实施例的基础上，网管客户端的第五实施例中进一步可以包括：框架模块。以基于第四实施例为例，第五实施例如图12所示。其中：

框架模块用于存储网管客户端所在的网络管理系统的功能界面列表。

在生成通知消息前，通知消息生成模块从框架模块中获取功能界面列表，并提供给用户，供用户从中选择关联功能界面，并获取用户选择的关联功能界面的信息，将该信息设置在生成的通知消息中。

则通知信息显示模块根据接收的通知消息中的关联功能界面信息，生成关联到对应功能界面的链接，并将该链接显示给用户，用户点击该链接后，则可以出现对应的功能界面。

以上是对网络管理系统、网管服务端和网管客户端具体实施例的分别说明，下面再对网络管理系统内部通信方法的具体实施例进行详细阐述：

如图13所示，网络管理系统内部通信方法第一实施例的主要流程包括：

步骤1301、第一网管客户端生成通知消息后，发送该通知消息；所述通知消息中包括通知信息和接收方信息，所述接收方信息为接收方用户和/或用户组信息。

步骤1302、网管服务端从所述第一网管客户端接收所述通知消息，并发送该通知消息。

步骤1303、第二网管客户端从网管服务端接收所述通知消息，将该通知消息中的通知信息提供给登录用户；所述第二网管客户端为所述通知消息中，接收方信息对应用户登录的网管客户端。

具体地，第一网管客户端与网管服务端之间采用CORBA协议通信；和/或，网管服务端与所述第二网管客户端之间采用CORBA协议通信。以第一网管客户端与网管服务端之间，网管服务端与第二网管客户端之间均采用CORBA协议通信为例，上述方法的第二实施例如图14所示，具体包括：

步骤1401、第一网管客户端生成通知消息，该通知消息中包括通知信息和接收方信息，接收方信息为接收方用户和/或用户组信息。

步骤1402、第一网管客户端将生成的通知消息转换为CORBA协议格式，如IDL格式，并将IDL格式的通知消息编码为CORBA协议编码格式，如CDR格式的数据包，然后发送所编码的CDR格式的数据包至网管服务端。以下CORBA协议格式为IDL格式，CORBA协议编码格式为CDR格式为例进行说明。

步骤1403、网管服务端从所述第一网管客户端接收上述包括通知消息的数据包后，对该数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为接收方内部支持的格式进行识别和处理。

步骤1404、网管服务端将该通知消息转换为IDL格式，再编码为CDR格式的数据包后，发送包括该通知消息的数据包。

步骤1405、第二网管客户端从网管服务端接收上述数据包后，对该数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为第二网管客户端内部支持的格式，然后将该通知消息中的通知信息提供给登录用户。接收通知消息的第二网管客户端，为上述网管服务端发送的通知消息中，接收方信息对应用户登录的网管客户端。

网络管理系统内部通信方法具体实施例中，可以由网络服务端对通知消息进行过滤，以使通知消息仅能够发送到接收方用户所登录的网管客户端，从而仅接收方用户能够获取通知消息；也可以由接收通知消息的网络客户端对通知消息进行过滤，对发送给自身登录用户的通知消息，才提供给登录用户，否则丢弃该通知消息，以保证仅接收方用户能够获取通知信息。以下分别通过第三、第四实施例进行详细阐述。

网络管理系统内部通信方法第三实施例可以基于上述第一或第二实施例，以基于第二实施例为例，如图15所示，具体包括如下步骤：

步骤1501、第一网管客户端生成通知消息，该通知消息中包括通知信息和接收方信息，接收方信息为接收方用户和/或用户组信息。

具体地，本步骤中，第一网管客户端生成通知消息可以包括：第一网管客户端将自身中存储的网络管理系统用户和用户组信息，提供给用户，供用户从中选择通知消息的接收方用户和/或用户组信息；将自身中存储的网络管理系统的功能界面列表显示给用户，供用户从中选择该通知消息关联的功能界面；并获取用户输入的通知信息；最终生成包括上述接收方用户和/或用户组信息、关联功能界面信息和通知信息的通知消息。

步骤1502、第一网管客户端将生成的通知消息转换为CORBA协议格式，如IDL格式，并将IDL格式的通知消息编码为CORBA协议编码格式，如CDR格式的数据包，然后发送所编码的CDR格式的数据包至网管服务端。以下CORBA协议格式为IDL格式，CORBA协议编码格式为CDR格式为例进行说明。

步骤1503、网管服务端从所述第一网管客户端接收上述包括通知消息的数据包后，对该数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为接收方内部支持的格式。

步骤1504、网管服务端从接收的通知消息中，解析出接收方用户和/或用户组信息，并确定接收方用户和/或用户组信息对应的第二网管客户端，然后将该通知消息转换为IDL格式，再编码为CDR格式的数据包后，发送包括该通知消息的数据包至上述确定出的第二网管客户端。

本步骤中所确定出的网管客户端的数量可以是一个或多个，当上述接收方用户和/或用户组信息中，只包括一个用户的用户信息时，所确定出的第二网管客户端的数量为一个；在上述接收方用户和/或用户组信息中，包括一个或多个用户信息和一个或多个用户组信息，或者包括多个用户信息，或者包括一个或多个用户组信息时，所确定出的接收通知的第二网管客户端的数量对应为多个。

这里，网管服务端可以主动或者根据网管客户端的请求，将通知消息进行格式转换、编码和发送给第二网管客户端。

步骤1505、接收到上述数据包的第二网管客户端，对所接收的数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为第二网管客户端内部支持的格式，然后将该通知消息中的通知信息通过显示或其他方式提供给登录用户；并根据通知消息中的关联功能界面信息，生成关联到对应功能界面的链接，并将该链接显示给用户。

网络管理系统内部通信方法第四实施例可以基于上述第一或第二实施例，以基于第二实施例为例，如图16所示，具体包括如下步骤：

步骤1601、第一网管客户端生成通知消息，该通知消息中包括通知信息和接收方信息，接收方信息为接收方用户和/或用户组信息。

步骤1602、第一网管客户端将生成的通知消息转换为CORBA协议格式，如IDL格式，并将IDL格式的通知消息编码为CORBA协议编码格式，如CDR格式的数据包，然后发送所编码的CDR格式的数据包至网管服务端。以下CORBA协议格式为IDL格式，CORBA协议编码格式为CDR格式为例进行说明。

步骤1603、网管服务端从所述第一网管客户端接收上述包括通知消息的数据包后，对该数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为接收方内部支持的格式。

步骤1604、网管服务端将该通知消息转换为IDL格式，再编码为CDR格式的数据包后，发送包括该通知消息的数据包至所有与自身连接的网管客户端。

这里，网管服务端可以主动或者根据网管客户端的请求，将通知消息进行格式转换、编码和发送。

步骤1605、网管客户端接收到数据包后，对所接收的数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为该网管客户端内部支持的格式，然后执行步骤1606。

步骤1606、网管客户端获取该通知消息中的接收方用户和/或用户组信息，并判断该信息是否包括该网管客户端的登录用户信息，如果是执行步骤1607，获取该通知消息中的通知信息并提供给登录用户；否则，在步骤1608，丢弃该通知信消息。

网络管理系统内部通信方法第五实施例的流程如图17所示，该实施例提供了网管服务端过滤通知消息的一种较佳实施方式，具体包括如下步骤：

步骤1701、在网络管理系统中，与网管服务端连接的每个网管客户端在启动时，向网管服务端发送通知注册请求，该通知注册请求中包括网管客户端的登录用户信息。

步骤1702、网管服务端接收到网管客户端的通知注册请求后，为对应网管客户端分配会话ID，获取通知注册请求中的登录用户信息，存储该登录用户信息与所分配的会话ID的对应关系，并生成用于向该网管客户端发送通知消息的通知接收对象，该通知接收对象中包括上述分配的会话ID。

当然，在上述步骤1702中，网管客户端在发送通知注册请求时，也通过与第三实施例中发送通知消息类似的转换和编码步骤进行；同样地，网管服务端在接收通知注册请求时，也通过与第三实施例中接收通知消息类似的编码和转换步骤进行，这里不再详述。

步骤1703、第一网管客户端生成通知消息，该通知消息中包括通知信息和接收方信息，接收方信息为接收方用户和/或用户组信息。

步骤1704、第一网管客户端将生成的通知消息转换为CORBA协议格式，如IDL格式，并将IDL格式的通知消息编码为CORBA协议编码格式，如CDR格式的数据包，然后发送所编码的CDR格式的数据包至网管服务端。以下CORBA协议格式为IDL格式，CORBA协议编码格式为CDR格式为例进行说明。

步骤1705、网管服务端从所述第一网管客户端接收上述包括通知消息的数据包后，对该数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为接收方内部支持的格式的通知消息。

步骤1706、网管服务端从上述转换出的通知消息中，解析出接收方用户和/或用户组信息，并查询自身中存储的登录用户信息与会话ID的对应关系，获取所述接收方用户和/或用户组信息对应的所有会话ID，根据这些会话ID，将通知消息转发给对应的通知接收对象。

步骤1707、将通知消息转换为IDL格式，再编码为CDR格式的数据包后，将编码后的数据包发送到通知接收对象对应的网管客户端。

步骤1708、网管客户端接收到数据包后，对所接收的数据包进行解码，并将解码后的CORBA协议格式的通知消息转换为该网管客户端内部支持的格式，然后获取该通知消息中的通知信息并提供给登录用户。

基于网络管理系统内部通信方法的上述各个实施例，在该方法的第六实施例中，向用户提供了查询通知消息的功能。该实施例在上述六个实施例的基础上，增加了查询流程，另外，在上述各个实施例中，网管服务端在接收到通知消息后，均对通知消息进行存储，并可以在存储的通知消息中设置时间戳。上述查询流程如图18所示，包括如下步骤：

步骤1801、网管客户端向网管服务端发送通知消息查询请求，该请求中包括该网管客户端的登录用户信息，并可以进一步包括时间段参数或条数参数。

步骤1802、网管服务端接收来自网管客户端的通知消息查询请求后，根据该查询请求中包括的登录用户信息，从存储的通知消息中查找接收方信息包括登录用户信息的通知消息，并将查找到的通知消息返回给发起查询请求的所述网管客户端。

本步骤中，当通知消息查询请求中包括时间段参数时，从存储的通知消息中查找通知消息时，查找所存储的通知消息中，属于所述时间段参数，并且其中的接收方信息包括所述登录用户信息的通知消息；

当通知消息查询请求中包括条数参数时，从存储的通知消息中查找所述查询请求对应的通知消息时，查找所存储的通知消息中，接收方信息包括所述登录用户信息的通知消息，并从所查找到的通知消息中根据所述条数参数选择最新的通知消息返回给客户端。

在本发明提供的上述实施例中，网管客户端之间需要交互的通知信息，直接通过网管服务端转发，而无需经由外部网络，保证了通知消息传送的及时性和安全性；相对于现有的各种通知传送方案，提高了网络管理系统中沟通与协作的效率，也提高了网络维护工作的效率，并且可以降低维护人员之间进行远程协作的成本；此外，将通知消息的接收用户信息与网络管理系统的用户信息集成在一起，无需重新维护一套用户信息，降低了网络关系系统的负担。

进而，本发明提供的实施例中，可以在通知消息中携带关联功能界面信息，从而接收到通知消息的用户，可以更加便利地获取到通知消息相关的功能界面，进一步提高了网络管理系统中沟通与协作的效率，也进一步提高了网络维护工作的效率，并且进一步降低维护人员之间进行远程协作的成本。

本发明提供的实施例中，可以在网管服务端对通知消息进行过滤，使得网管服务端在转发所接收到的通知消息时，只发送给接收方用户登录的网管客户端，降低了网络中的信息流量。

本发明提供的实施例中，还可以在网管客户端对通知消息进行过滤，对于发送给自身登录用户的通知消息，才将通知信息提供给用户，而对于不是发送给自身登录用户的通知消息，直接丢弃，从而无需在网管服务端对通知消息进行接收方的确认，降低了网管服务端的负担。

此外，以上各个实施例中，网管客户端和网管服务端之间可以采用CORBA协议进行通信，由于CORBA协议通信的安全性较高，进一步提高了通知消息传送的安全性。

本领域普通技术人员可以理解实现上述实施例方法中在同一设备中的步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于该设备的可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如：ROM/RAM、磁碟、光盘等。

以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本发明的具体实施方式只是起示范作用，并不用以限制本发明的保护范围。