理方法是用户自定义的本网元对接收到的消息的处理方法，该方 法必须符合消息处理接口的规范要求；接收网元是本消息处理完成后，将要发送消息的目 标网元号，根据实际情况定义，该值是正整数；发送事件号是目标网元将要处理的事件号， 该字段如果配置为结束标志（一般用〇表示，也可以使用其他约定的数值），表示消息流程 结束。消息分发表201可以以文件、数据库等方式存储。
[0061] 消息处理接口 301，用于定义通用的消息处理规范。该接口一般由消息的接收方网 元来实现，以定制自己的消息处理方法。该接口只定义规范，以便消息监听装置401能够正 确监听到，消息分发表201中配置的每个消息处理方法都是本接口的一个具体实现。
[0062] 消息监听装置401，负责本网元消息的接收、处理和发送。其中，消息监听装置401 可以包括：消息接收器402,用于监听并接收发往本网元（即网元对应的网管服务器）的 消息；消息处理器403,用于根据消息分发表201中配置的消息处理方法来处理消息，并根 据异常分发表进行异常处理；消息发送器404,用于消息处理完成后，根据消息分发表的配 置，将消息发往下一个网元；异常分发表405用于配置遇到特定异常时的处理方式，异常分 发表包括异常码和发送事件号两个关键字段。
[0063] 在本实施例中，消息监听模块401负责监听其他网元对应的网管服务器发送到本 网元对应的网管服务器的消息，当监听到有消息过来时，本装置中的消息接收器负责接收 消息，并查找消息分发表中事件号对应的消息处理方法，然后由消息处理器执行该方法和 进行异常处理。执行完成后，根据消息分发表中配置的数据，由消息发送器将消息发送到下 一个网元。
[0064] 在本发明实施例中，异常分发表405的作用是在消息处理器处理的过程中，如果 发生某种异常，决定消息的发送方向。也就是说，在发生异常的情况下，消息分发表201配 置的发送事件号就不起作用了，由异常分发表405中配置的事件号来取代。表2是一个异 常分发表的示例。
[0065] 表 2.
[0066]
[0067] 在具体实施过程中，异常码对应的具体含义是系统内部定义的，表2所示的异常 分发表指示在处理过程中如果发送了代号为120001的异常情况，则转到事件号4001来处 理，如果遇到120006,则转到4002来处理，这里的4001和4002也必须在消息分发表中配置 并实现。
[0068] 动态加载装置501用于加载消息分发表在用户配置或修改消息分发表后，执行动 态加载装置501，从而使得消息分发表可以立即生效。在本实施例中，动态加载装置501，用 来完成消息分发表的解析和加载。用户实现或修改了消息分发列表的内容后，首先执行动 态加载装置501，即可使消息分发列表的内容生效，不影响服务器的正常运行和网元的正常 工作。通过动态加载装置，提高了数据传输的灵活性和适用范围，例如可以在用户不知情的 情况下，实现对特定网元的监听，对特定信息的收集等。
[0069] 在本发明实施例中，一次通讯过程可以由网管客户端发起，也可以由用户设定好 定时任务，由网管服务器定时发起。通讯发起后，消息监听装置401首先执行发起方的事件 号对应的处理方法，处理完成后，根据消息分发表中配置的顺序，将消息发送到下一个事件 号对应的网元继续处理。
[0070] 如果某网元需要请求其他网元的数据，可以在消息处理方法中实现，使用定制的 方法下载其他网元准备好的数据，网管服务器对请求到的数据进行处理后可以进行入库等 操作，这时，如果消息分发表中还有下一步流程，则将消息发到下一网元继续处理，如果没 有下一步流程，则本次通讯结束，传送模块102将通讯后变化的数据同步到对应网元。
[0071] 以表1所示的消息分发表为例，11号网元对应的网管服务器首先发起会话（哪 个网元侧首先发起并不在消息分发表中体现，是由客户端或定时任务等触发的），执行 【Begin】方法，然后通过消息把事件号2发给13号网元对应的网管服务器；13号网元对应 的网管服务器收到消息后，执行事件号2对应的方法【Eventl】，执行完后，把事件号100发 回11号网元对应的网管服务器；11号网元对应的网管服务器收到消息后，执行【Event2】， 完成后发101给13号网元对应的网管服务器；13号网元对应的网管服务器接收到消息，执 行【End】方法，然后发消息给11号网元对应的网管服务器，事件号是200,其中，事件号200 对应的也是【End】方法；11号网元对应的网管服务器执行【End】方法，执行到这里，接收网 元和发送事件号都是0,表示流程结束了。
[0072] 从上述示例中可以看出，在数据传输过程中，消息通道和数据通道是分离的。每个 消息中仅仅包含接收网元号和发送事件号两个整型数值，消息体非常小，这样保证了传输 的可靠和安全。
[0073] 在上述示例中并不能直接看出数据是如何传输的，数据传输是在消息处理方法中 实现的，如【Eventl】或【Event2】。用户可以定制任意的传输方式，依靠系统底层的成熟方 案进行，例如可以利用加密的sftp服务，而数据的格式本身，用户可以使用自定义的方式 进行压缩或加密，应用非常灵活。
[0074] 并且，在本发明实施例中，所有数据传输的中间过程都是在后台网管服务器上进 行的，网元毫不知情，只有在数据传输结束后，发生数据改变的情况下，才由网管的数据传 送功能（即上述传送模块）通知网元更新状态。传输过程中如果发生任何网络故障等问题， 可以安全的结束本次会话，而不影响网元的工作状态。
[0075] 通过本发明实施例提供的上述技术方案，将消息通道和数据通道分离，用户可以 安照消息处理接口的规范定制消息处理的具体方法，以后台通讯驱动网间的数据传输。因 此，具有安全、隐蔽、使用灵活、支持大数据量传输等有益效果。
[0076] 下面以图7所示的消息分发表及图8所示异常分发表来实现双归属容灾备份为 例，对本发明实施例提供的技术方案作进一步说明。其中51、52是主用网元，61是备用网 元，51网元是消息的发起方，需要把51和52网元的数据备份到61网元。
[0077] 在实施时，按照图7和图8在各个网元的对应网管服务器中配置消息分发表和异 常分发表，同时实现消息分发表中配置的消息处理方法，然后执行动态加载即可。
[0078] 图9为本实施例中执行数据备份的系统内部流程图，左边虚线框中表示的是正常 流程，右边表示异常流程，仅表示了异常码14001的处理流程，其他异常处理流程类似。正 常流程中的多个步骤都可能出现异常而转到异常流程，图中用虚线做了标示。
[0079] 如图9所示，将51和52网元的数据备份到61网元主要包括以下步骤：
[0080] 步骤901 :网元51对应的网管服务器发起双归属请求，指定事件号是1001。
[0081] 步骤902:网元51对应的网管服务器的消息监听装置收到事件号为1001的消息， 并执行该事件号对应的消息处理方法（Begin)，执行完成后，将消息发送到51和52网元对 应的网管服务器，事件号是1002。
[0082] 说明，在本实施例中，本网管服务器内发送消息也是支持的。
[0083] 步骤903 :网元51、52对应的网管服务器同时收到消息，并执行事件1002(进行主 用端的数据校验，如果校验不通过，会自动转到异常流程，下同），然后发消息到网元61对 应的网管服务器。
[0084] 步骤904 :网元61对应的网管服务器执行事件2001 (执行备用端数据校验），完成 后发消息给网元51、52对应的网管服务器。
[0085] 步骤905 :网元51、52对应的网管服务器同时执行事件1003(主用端进行数据导 出），完成后发消息给网元61对应的网管服务器。
[0086] 步骤906 :网元61对应的网管服务器执行事件2002 (从主用网元51、52获取数据， 并处理后导入），完成后发消息给网元51对应的网管服务器。说明：因为网元51对应的网 管服务器是发起方，要把执行情况告知发起方，而不需要通知网元52对应的网管服务器。
[0087] 步骤907 :网元51对应的网管服务器执行事件1004(上报进度，告知用户对方网 元已经成功获取数据），完成后发消息给网元61对应的网管服务器；
[0088] 步骤908 :网元61对应的网管服务器收到消息，执行事件2003 (传送数据，即把变 化的数据通知前台网元。因为流程中，只有61号网元的数据发生了变化，所以只有61号网 元对应的网管服务器需要传送数据），消息分发表中发送事件号是0,表示流程结束。
[0089] 步骤909 :判断异常码是否是14001，如果是，转到本异常的处理流程910,否则，转 到其他异常的处理流程（略）。在上述步骤中，如果任何一步发生异常，即转到本步骤。
[0090] 步骤910 :根据异常分发表，找到14001对应的事件号400