CN101895519A - 服务处理方法和装置 - Google Patents

Abstract

本发明实施例公开了一种服务处理方法和装置，其中服务处理方法包括：公共对象请求代理结构服务端启动后，该服务端启动名字服务管理任务；在名字服务停止服务状态转换为开始服务状态后，通过所述服务管理任务将服务端的对象服务信息注册到名字服务上。公共对象请求代理结构服务端装置包括：第一任务启动模块，用于在本服务端启动后，启动名字服务管理任务；第一服务管理模块，用于在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到名字服务上。本发明实施例实现了在名字服务或通知服务出现异常时保证网络的正常运营，减少了定位失败和事件丢失。

Description

服务处理方法和装置

技术领域

本发明实施例涉及通信技术，尤其涉及一种服务处理方法和装置。

背景技术

公共对象请求代理结构(Common Object Request Broker Architecture；以下简称：CORBA)作为对象间通信的一种工业标准，使用面向对象的设计结构，允许软件对象在不同的操作***平台和应用程序中重复使用。CORBA应用是指符合CORBA规范的由任意开发语言开发的软件应用程序，通常由提供CORBA对象接口服务的服务端程序和调用CORBA对象接口服务的客户端程序构成。典型的CORBA应用包括名字服务(Naming Service)和通知服务(NotifyService)，名字服务为分散的CORBA应用提供对象注册点，服务端先将对象服务信息注册到名字服务上，客户端从名字服务上获取到对象服务信息后，直接调用对象接口服务，而无需再通过名字服务进行中转；通知服务则用来传递服务端到客户端的通知事件，服务端先在通知服务上创建事件通道，并向通知服务上报事件，由通知服务向客户端转发事件。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：CORBA应用需要在名字服务和通知服务启动后才能启动，这样为***部署带来限制和不便，造成不必要的维护和咨询成本。当名字服务在运行过程中异常重启后，由于CORBA应用未能获知该情况，服务端未向名字服务重新注册，则客户端向服务端获取对象服务时将失败。当通知服务异常重启后，由于服务端未向通知服务重新创建事件通道，则服务端在向原来的事件通道上发送事件时则导致发送失败，客户端也无法收到通知服务转发的事件。由此可见，在现有技术中，当名字服务、通知服务出现异常重启后，需要手工依次重启名字服务或通知服务、服务端应用、客户端应用才能使得***恢复正常，否则会造成定位失败和事件丢失，需要专业支持人员进行现场定位和恢复，导致成本提高，同时如果长时间脱管造成告警事件丢失，则会严重影响网络的正常运营。

发明内容

本发明实施例在于提供一种服务处理方法和装置，解决应用与服务之间的启动依赖和注册依赖问题，解除应用与名字服务或通知服务之间启动顺序的限制，实现在名字服务或通知服务出现异常时保证网络的正常运营。

为了实现上述目的，本发明实施例提供了一种服务处理方法，包括：

公共对象请求代理结构服务端启动后，该服务端启动名字服务管理任务；

在名字服务停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上。

本发明实施例还提供了另一种服务处理方法，包括：

公共对象请求代理结构服务端启动后，该服务端启动通知服务管理任务；

在通知服务停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道。

本发明实施例提供了一种公共对象请求代理结构服务端装置，包括：

第一任务启动模块，用于在服务端启动后，启动名字服务管理任务；

第一服务管理模块，用于在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到名字服务上。

本发明实施例还提供了另一种公共对象请求代理结构服务端装置，包括：

第二任务启动模块，用于在服务端启动后，启动通知服务管理任务；

第二服务管理模块，用于在通知服务由停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道。

本发明实施例提供的一种服务处理方法和装置，通过设置并启动服务管理任务，通过服务管理任务完成在名字服务异常时将服务端的对象服务信息注册到名字服务上，或在通知服务异常时创建服务端与通知服务之间的事件通道，解决了应用与名字服务或通知服务之间的启动依赖和注册依赖问题，解除了应用与名字服务或通知服务之间启动顺序的限制，实现了在名字服务或通知服务出现异常时保证网络的正常运营，同时大大降低了维护和咨询成本，减少了定位失败和事件丢失。

附图说明

图1为本发明服务处理方法一实施例的流程图；

图2为本发明服务处理方法一实施例的信令图；

图3为本发明服务处理方法另一实施例的信令图；

图4为本发明服务处理方法另一实施例的流程图；

图5为本发明服务处理方法又一实施例的信令图；

图6为本发明服务处理方法再一实施例的信令图；

图7为本发明服务处理方法还一实施例的信令图；

图8为本发明服务处理方法又另一实施例的信令图；

图9为本发明服务处理方法又再一实施例的信令图；

图10为本发明服务处理方法又还一实施例的信令图；

图11为本发明公共对象请求代理结构服务端装置一实施例的结构图；

图12为本发明公共对象请求代理结构服务端装置另一实施例的结构图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

在CORBA应用提供的众多服务中，名字服务和通知服务为最典型的两种服务。其中，CORBA应用需要通过名字服务为CORBA对象指定一个唯一的名字上下文，使用CORBA对象的名字上下文从名字服务中获取相应的CORBA对象，通过建立层次化的名字树，将名字上下文和相应的CORBA对象绑定在一起。通知服务则用来完成从服务端到客户端的通知事件的传递，通过CORBA应用的服务端在通知服务上创建事件通道，CORBA应用的客户端则由事件通道来接收服务端发送的事件。CORBA应用的服务端和客户端依赖于名字服务和通知服务，服务端应用、客户端应用的启动与名字服务、通知服务的启动之间存在顺序上的限制。本发明实施例为了消除诸如CORBA应用与名字服务、通知服务之间所存在的启动依赖性、注册依赖性，提供一种应用与服务之间的松耦合思想，使得在服务出现异常时仍能保证网络的正常运营。本发明的以下实施例将以CORBA应用以及其定义的名字服务和通知服务为例对本发明实施例的技术方案进行详细的说明，需要指出的是，本发明实施例提供的服务与应用的松耦合思想并不局限于CORBA应用，适用于其他任何存在启动依赖性或注册依赖性的应用，如对JMS存在依赖性的新兴接口技术MTOSI，以下不再赘述。

图1为本发明服务处理方法一实施例的流程图，如图1所示，本实施例提供了一种服务处理方法，具体包括如下步骤：

步骤101，CORBA服务端启动后，该服务端启动名字服务管理任务；

在本实施例中，CORBA应用的服务端启动服务端对应的一个名字服务管理任务，此处对应的含义可以理解为，该名字服务管理任务在物理形态上可以为服务端应用的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。具体地，该名字服务管理任务可以为名字服务状态检测任务，用来定期检测名字服务的服务状态的；也还可以为名字服务定期注册任务，用来定期在名字服务上注册对象服务信息。名字服务管理任务在名字服务启动之前启动，并在名字服务的整个运行期间运行。

步骤102，在名字服务由停止服务状态转换为开始服务状态后，服务端通过名字服务管理任务将服务端的对象服务信息注册到名字服务上。

在本步骤中，在名字服务由停止服务状态转换为开始服务状态后，服务端通过启动的名字服务管理任务进行对象服务信息的注册。名字服务由停止服务状态转换为开始服务状态这一服务状态的变化可以具体为名字服务重新启动，也可以为名字服务上注册的对象服务信息丢失等。需要指出的是，名字服务重新启动可以为名字服务首次启动、正常重启或者异常重启。

在名字服务首次启动、正常重启或者异常重启之后，服务端通过该名字服务管理任务将服务端的对象服务信息注册到名字服务上。或者，在名字服务首次启动、正常重启或者异常重启之后，服务端通过名字服务管理任务以预定的时间周期，定期将服务端的对象服务信息注册到名字服务上。可以保证在名字服务运行正常时服务端自身将对象服务信息注册到名字服务上。同时也可以保证在名字服务后于服务端启动或名字服务出现异常重启的情形下，保证名字服务启动后服务端能自动检测到名字服务的状态，并自动注册对象服务信息。因此，本实施例提供的服务处理方法使得CORBA应用的服务端的启动不再依赖于名字服务的启动，而且当名字服务异常重启后，无需再手动重启CORBA应用，仍可以正常向名字服务注册对象服务信息，保证了后续客户端可以正常获取到对象服务信息，大大降低了维护和咨询成本，减少了定位失败和事件丢失。

本实施例提供了一种服务处理方法，通过设置并启动服务端对应的名字服务管理任务，通过名字服务管理任务完成在名字服务上注册对象服务信息，解决了CORBA应用与名字服务之间的启动依赖和注册依赖问题，解除了CORBA应用与名字服务之间启动顺序的限制，实现了在名字服务出现异常时保证网络的正常运营，同时大大降低了维护和咨询成本，减少了定位失败。

图2为本发明服务处理方法一实施例的信令图，如图2所示，本实施例具体为CORBA应用的服务端对名字服务的启动期松耦合方案，本实施例提供的方法具体包括如下步骤：

步骤201，CORBA服务端启动后，该服务端启动与服务端对应的名字服务状态检测任务。

在本实施例中，名字服务管理任务具体为名字服务状态检测任务。本步骤为CORBA应用的服务端在启动之后，启动名字服务状态检测任务，服务端对应的名字服务状态检测任务可以为服务端应用的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。本实施例中的服务端在名字服务启动之前启动，在服务端的启动期间，服务端不直接在名字服务上注册对象服务信息，而是先启动对应的名字服务状态检测任务，由该名字服务状态检测任务对名字服务的服务状态进行定时检测。

步骤202，服务端通过名字服务状态检测任务检测名字服务的服务状态。

服务端先于名字服务启动，并启动服务端对应的名字服务状态检测任务，通过名字服务状态检测任务，对名字服务的当前服务状态进行定期的检测，不断地检测名字服务是否已经启动，以根据名字服务的服务状态来进行后续的相应操作。

步骤203，当名字服务状态检测任务检测到名字服务首次启动时，则将服务端的对象服务信息注册到名字服务上。

本实施例中预设的触发条件为：名字服务状态检测任务对名字服务的服务状态进行检测，检测到名字服务的状态由停止服务状态转为开始服务状态，本实施例以名字服务的首次启动为例进行说明。本实施例针对的是名字服务在启动期的情况，在名字服务状态检测任务启动之前名字服务尚未启动。服务端对应的名字服务状态检测任务启动之后，对名字服务的当前服务状态进行定期的检测，不断地检测名字服务是否已经启动，当名字服务在某一时间以不生成持久化信息的方式启动时，名字服务状态检测任务检测到名字服务从停止服务状态转为开始服务状态，即名字服务首次启动时，则名字服务状态检测任务代替服务端将服务端的对象服务信息注册到名字服务上。之后，客户端便可以从名字服务上获取已注册的对象服务信息，并通过服务端调用该对象服务接口。

本实施例提供了一种服务处理方法，在本实施例中，CORBA应用的服务端先于名字服务启动，并先启动服务端对应的名字服务状态检测任务，对名字服务的服务状态进行不断地检测，一旦检测到名字服务启动，则在该名字服务上注册对象服务信息，消除了现有技术中对于CORBA应用的服务端应用和名字服务在启动顺序上的限制，使得服务端应用先于名字服务启动时，仍可以进行正常的对象服务信息的注册以及对象服务接口的调用，不影响整个网络的正常运营。本实施例解决了CORBA应用与名字服务之间的启动依赖性问题，解除了CORBA应用与名字服务之间启动顺序的限制，在启动顺序发生变化时仍能保证正常的注册，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图3为本发明服务处理方法另一实施例的信令图，如图3所示，本实施例具体为CORBA应用的服务端对名字服务的运行期松耦合方案，本实施例提供的方法具体包括如下步骤：

步骤301，CORBA服务端启动后，该服务端启动与服务端对应的名字服务状态检测任务。

本实施例针对的是名字服务在运行期的情况，名字服务状态检测任务在名字服务的启动期启动，并在名字服务的整个运行期内运行，定期对名字服务的服务状态进行检测。

步骤302，服务端通过名字服务状态检测任务检测名字服务的服务状态。

名字服务以不生成持久化信息的方式正常启动，在名字服务状态检测任务检测到名字服务的服务状态首次启动之后，将服务端的对象服务信息注册到名字服务上，而在名字服务正常运行时，此过程中名字服务状态检测任务未检测到名字服务的服务状态由停止服务状态转化为开始服务状态，则由服务端正常向该名字服务进行对象服务信息的注册，并由客户端进行后续的对象服务信息的获取以及对象服务接口的调用过程。在名字服务运行过程中，名字服务状态检测任务继续对名字服务的服务状态进行检测，例如当名字服务由于某些客观原因或人为原因在某一时刻发生异常，并且进行异常重启之后，名字服务状态检测任务即可检测到名字服务的状态由停止服务状态转化为继续服务状态。

步骤303，当名字服务状态检测任务检测到名字服务异常重启时，则将服务端的对象服务信息注册到名字服务上。

本实施例中预设的触发条件为：名字服务状态检测任务对名字服务的服务状态进行检测，检测到名字服务的状态由停止服务状态转为开始服务状态，本实施例以名字服务的异常重启为例进行说明。由于名字服务在初次启动时的启动方式为不生成持久化信息的方式，因此在名字服务异常重启之后，在名字服务上未对异常重启之前注册的对象服务信息进行保存，如果采用现有技术的方法，则客户端应用此时无法从名字服务上获取对象服务信息。而采用本实施例所提供的方法时，由于增设了服务端对应的名字服务状态检测任务，该名字服务状态检测任务在名字服务的运行过程中不断地对名字服务的服务状态进行检测，当名字服务状态检测任务检测到名字服务的服务状态为异常重启时，则代替服务端将服务端的对象服务信息注册到该名字服务上。

进一步地，本实施例提供的服务处理方法还可以包括如下步骤：通过名字服务状态检测任务检测名字服务的服务状态，当名字服务状态检测任务检测到名字服务上注册的对象服务信息与服务端的对象服务信息不一致时，确定名字服务由停止服务状态转换为开始服务状态，并将服务端的对象服务信息注册到名字服务上。本实施例提供的名字服务状态检测任务对名字服务的服务状态进行检测，可以检测到名字服务上注册的对象服务信息丢失。名字服务状态检测任务可以将名字服务上注册的对象服务信息与客户端获取的对象服务信息进行比较，如果二者不同，则表明对象服务信息已丢失，当名字服务状态检测任务检测到对象服务信息丢失时，确定所述名字服务由停止服务状态转换为开始服务状态，同样将服务端的对象服务信息注册到名字服务上，以保证后续操作正常化。

本实施例提供了一种服务处理方法，在本实施例中，CORBA应用的服务端通过设置并启动名字服务状态检测任务，并在名字服务的整个运行期间运行，对名字服务的状态进行不断地检测，一旦检测到名字服务的状态发生异常时，即名字服务异常重启或发生对象服务信息丢失等，则在该名字服务上重新注册对象服务信息，消除了现有技术中对于CORBA应用的服务端应用对名字服务的启动依赖性和注册依赖性，使得名字服务异常重启后，无需重启服务端，仍可以进行正常的对象服务信息的注册以及对象服务接口的调用，不影响整个网络的正常运营，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图4为本发明服务处理方法另一实施例的流程图，如图4所示，本实施例提供了另一种服务处理方法，具体包括如下步骤：

步骤401，CORBA服务端启动后，该服务端启动通知服务管理任务；

在本实施例中，CORBA应用的服务端启动服务端对应的一个通知服务管理任务，此处对应的含义可以理解为，该通知服务管理任务在物理形态上可以为服务端应用的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。具体地，该通知服务管理任务可以为通知服务状态检测任务，用来定期检测通知服务的服务状态的；也通知服务事件通道创建任务，用来定期创建服务端与通知服务之间的事件通道。通知服务管理任务在通知服务启动之前启动，并在通知服务的整个运行期间运行。

步骤402，在通知服务由停止服务状态转换为开始服务状态后，服务端通过通知服务管理任务创建服务端与通知服务的事件通道。

在本步骤中，在通知服务由停止服务状态转换为开始服务状态后，服务端通过启动的通知服务管理任务进行事件通道的创建。通知服务停止服务并重新启动这一服务状态的变化可以具体为通知服务重新启动，也可以为通知服务上创建的事件通道发生异常等。需要指出的是，通知服务由停止服务状态转换为开始服务状态可以为通知服务首次启动、正常重启或者异常重启。

在通知服务首次启动、正常重启或者异常重启之后，服务端通过该通知服务管理任务创建服务端与通知服务之间的事件通道。或者在通知服务首次启动、正常重启或者异常重启之后，服务端通过通知服务管理任务以预定的时间周期，定期创建服务端与通知服务之间的事件通道。可以保证在通知服务运行正常时创建服务端与通知服务之间的事件通道，同时也可以保证在通知服务后于服务端启动或通知服务出现异常重启的情形下，保证通知服务启动后服务端能自动检测到通知服务的状态，并自动在通知服务上创建事件通道。因此，本实施例提供的服务处理方法使得CORBA应用的服务端的启动不再依赖于通知服务的启动，而且当通知服务异常重启后，无需再手动重启CORBA应用，仍可以正常向通知服务创建事件通道，保证了后续通知服务也可以正常通过事件通道向客户端转发事件，大大降低了维护和咨询成本，减少了事件丢失。

本实施例提供了一种服务处理方法，通过设置并启动服务端对应的通知服务管理任务，通过通知服务管理任务完成在通知服务上创建事件通道，解决了CORBA应用与通知服务之间的启动依赖和注册依赖问题，解除了CORBA应用与通知服务之间启动顺序的限制，实现了在名字服务、通知服务出现异常时保证网络的正常运营，同时大大降低了维护和咨询成本，减少了事件丢失。

图5为本发明服务处理方法又一实施例的信令图，如图5所示，本实施例具体为CORBA应用的服务端对通知服务的启动期松耦合方案，本实施例提供的方法具体包括如下步骤：

步骤501，CORBA服务端启动后，该服务端启动对应的通知服务状态检测任务。

在本实施例中，服务管理任务具体为通知服务状态检测任务，通知服务状态检测任务可以为服务端的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。服务端先于通知服务启动，并启动服务端对应的通知服务状态检测任务，而不直接在通知服务上创建事件通道。

步骤502，服务端通过通知服务状态检测任务检测通知服务的服务状态。

服务端先于通知服务启动，并启动对应的通知服务状态检测任务，通过通知服务状态检测任务对通知服务的服务状态进行定期检测，不断地检测通知服务是否已经启动，以根据通知服务的服务状态来进行后续的相应操作。

步骤503，当通知服务状态检测任务检测到通知服务首次启动时，则创建服务端与通知服务之间的事件通道。

本实施例中预设的触发条件为：通知服务状态检测任务对通知服务的服务状态进行检测，检测到通知服务的状态由停止服务状态转为开始服务状态，本实施例以通知服务的首次启动为例进行说明。通知服务状态检测任务对通知服务的服务状态进行定期检测，当通知服务在某一时间以不生成持久化信息的方式启动，通知服务状态检测任务检测到通知服务的服务状态从停止服务状态转化为开始服务状态，即检测到通知服务首次启动时，通知服务状态检测任务代替服务端创建该服务端与通知服务之间的事件通道。

步骤504，通知服务状态检测任务向服务端发送事件通道可用消息，指示服务端上报事件。

步骤505，服务端通过事件通道将事件上报到通知服务上。

在通知服务状态检测任务将服务端与通知服务之间的事件通道创建成功之后，向服务端发送事件通道可用消息，由该事件通道可用消息指示服务端上报事件。当服务端接收到事件通道可用消息，获知事件通道可用后，通过该事件通道向通知服务进行事件的上报，此后，通知服务可以向客户端转发服务端应用发送的事件，客户端便可以通过创建的事件通道正常接收其感兴趣的事件。

进一步地，在步骤504之前，还可以包括：通知服务状态检测任务在检测到通知服务处于停止服务状态时，向服务端发送事件通道不可用消息，指示述服务端在接收到事件通道可用消息前将需要上报的事件进行本地缓存处理；通知服务状态检测任务检测到服务从停止服务状态转为开始服务状态并创建与通知服务之间的事件通道后，向服务端发送事件通道可用消息，指示服务端将所缓存的事件通过事件通道发送给通知服务。在服务端启动之后，通知服务启动之前，通知服务状态检测任务检测到的通知服务的服务状态为停止服务状态，在此过程中实际上有事件发生，但由于未创建事件通道，因此在这段时间发生的事件均不直接进行上报，而是进行本地缓存处理。此处所指的本地缓存处理可以采用以下方式中的任意一种：第一种方式为丢弃未上报事件，这种方式为将事件通道创建之前所发生的未上报事件直接丢弃，不再进行后续的上报操作。第二种方式为缓存未上报事件到文件或数据库中，这种方式未丢弃未上报事件，而是将其进行持久化缓存，即缓存在特定的文件或者数据库中，当通知服务状态检测任务检测到通知服务的服务状态从停止服务状态转为开始服务状态，并已成功创建服务端与通知服务之间的事件通道之后，通知服务状态检测任务向服务端发送事件通道可用消息，通过该事件通道可用消息指示服务端将缓存在特定的文件或者数据库中的事件通过该事件通道发送到通知服务，这种方式可以保证未上报事件均不丢失。第三种方式为缓存未上报事件到额定存储空间的内存中，这种方式未将未上报事件直接丢弃，也未将其直接缓存在特定的文件或数据库中，而是将其缓存在具有额定存储空间的内存中。此处所指的内存可以为具有额定存储空间的内存队列，也可以为具有额定存储空间的文件或数据库等形式的缓存。这种方式中所指的内存具有额定存储空间，即设定内存的最大容量，在进行未上报事件的缓存时，并不是对未上报事件进行无限量缓存，而对其数量进行了限制，当达到内存最大容量时，按照先入先出的方式丢弃最早缓存的未上报事件。当通知服务状态检测任务检测到通知服务的服务状态从停止服务状态转为开始服务状态，并已成功创建服务端与通知服务之间的事件通道之后，通知服务状态检测任务向服务端发送事件通道可用消息，通过该事件通道可用消息指示服务端将缓存在该内存的事件通过该事件通道发送到通知服务。可见，这种方式可以保证最新发生的一定数量的未上报事件不会丢失。

本实施例提供了一种服务处理方法，在本实施例中，CORBA应用的服务端先于通知服务启动，并先启动对应的通知服务状态检测任务，而不是直接向通知服务创建事件通道，通过通知服务状态检测任务对通知服务的服务状态进行不断地检测，一旦检测到通知服务启动后，则在该通知服务上创建事件通道，随后即通过该事件通道进行事件上报，且将事件通道创建成功之前发生的事件进行缓存，在事件通道创建成功后也进行上报。通过本实施例提供的方法消除了现有技术中对CORBA应用的服务端和通知服务在启动顺序上的限制，使得服务端在先于通知服务启动时，仍可以进行正常的事件通道创建以及事件的上报，不影响整个网络的正常运营。本实施例解决了CORBA应用与通知服务之间的启动依赖性问题，解除了CORBA应用与通知服务之间启动顺序的限制，当启动顺序发生变化时，仍能保证正常的定位，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图6为本发明服务处理方法再一实施例的信令图，如图6所示，本实施例具体为CORBA应用的服务端对通知服务的运行期松耦合方案，本实施例提供的方法具体包括如下步骤：

步骤601，CORBA服务端启动后，启动对应的通知服务状态检测任务。

本实施例针对的是通知服务在运行期的情况，通知服务状态检测任务在通知服务的启动期启动，并在通知服务的整个运行期内运行，定期对通知服务的状态进行检测。

步骤602，服务端通过通知服务状态检测任务检测通知服务的服务状态。

通知服务以不生成持久化信息的方式正常启动，在通知服务状态检测任务检测到通知服务的服务状态首次启动之后，代替服务端创建与通知服务之间的事件通道，而在通知服务正常运行时，此过程中通知服务状态检测任务未检测到通知服务的服务状态由停止服务状态转化为开始服务状态，则由服务端自身正常向该通知服务进行事件通道的创建，并向通知服务正常上报事件。在通知服务运行过程中，通知服务状态检测任务继续对通知服务的服务状态进行检测，例如当通知服务由于某些客观原因或人为原因在某一时刻发生异常，并且进行异常重启之后，通知服务状态检测任务即可检测到通知服务的状态由停止服务状态转化为继续服务状态。

步骤603，当通知服务状态检测任务检测到通知服务异常启动时，则创建服务端与通知服务之间的事件通道。

本实施例中预设的触发条件为：通知服务状态检测任务对通知服务的服务状态进行检测，检测到通知服务的状态由停止服务状态转为开始服务状态，本实施例以通知服务的异常重启为例进行说明。通知服务以不生成持久化信息的方式正常启动后，在该通知服务上正常创建事件通道并上报事件。在运行过程中，通知服务由于某些客观原因或人为原因在某一时刻发生异常，并且进行异常重启时，通知服务状态检测任务即检测到通知服务异常启动，则通知服务状态检测任务代替服务端创建该服务端与通知服务之间的事件通道。

步骤604，通知服务状态检测任务向服务端发送事件通道可用消息，指示服务端上报事件。

步骤605，服务端通过事件通道将事件上报到通知服务上。

在通知服务状态检测任务将服务端与通知服务之间的事件通道创建成功之后，向服务端发送事件通道可用消息，由该事件通道可用消息指示服务端上报事件。当服务端接收到事件通道可用消息，获知事件通道可用后，通过该事件通道向通知服务进行事件的上报，此后，通知服务可以向客户端转发服务端应用发送的事件，客户端便可以通过创建的事件通道正常接收其感兴趣的事件。

进一步地，在步骤604之前，还可以包括：通知服务状态检测任务在检测到通知服务处于停止服务状态时，向服务端发送事件通道不可用消息，指示述服务端在接收到事件通道可用消息前将需要上报的事件进行本地缓存处理；通知服务状态检测任务检测到服务从停止服务状态转为开始服务状态并创建与通知服务之间的事件通道后，向服务端发送事件通道可用消息，指示服务端将所缓存的事件通过事件通道发送给通知服务。在通知服务异常终止之后，通知服务状态检测任务检测到的通知服务的服务状态为停止服务状态，在通知服务重启之前所发生的事件均不直接进行上报，而是对未上报事件进行本地缓存处理。此处所指的本地缓存处理可以采用以下方式中的任意一种：第一种方式为丢弃未上报事件，这种方式为将事件通道创建之前所发生的未上报事件直接丢弃，不再进行后续的上报操作。第二种方式为缓存未上报事件到文件或数据库中，这种方式未丢弃未上报事件，而是将其进行持久化缓存，即缓存在特定的文件或者数据库中，当通知服务状态检测任务检测到通知服务的服务状态从停止服务状态转为开始服务状态，并已成功创建服务端与通知服务之间的事件通道之后，通知服务状态检测任务向服务端发送事件通道可用消息，通过该事件通道可用消息指示服务端将缓存在特定的文件或者数据库中的事件通过该事件通道发送到通知服务，这种方式可以保证未上报事件均不丢失。第三种方式为缓存未上报事件到额定存储空间的内存中，这种方式未将未上报事件直接丢弃，也未将其直接缓存在特定的文件或数据库中，而是将其缓存在具有额定存储空间的内存中。此处所指的内存可以为具有额定存储空间的内存队列，也可以为具有额定存储空间的文件或数据库等形式的缓存。这种方式中所指的内存具有额定存储空间，即设定内存的最大容量，在进行未上报事件的缓存时，并不是对未上报事件进行无限量缓存，而对其数量进行了限制，当达到内存最大容量时，按照先入先出的方式丢弃最早缓存的未上报事件。通知服务状态检测任务检测到通知服务的服务状态从停止服务状态转为开始服务状态，并已成功创建服务端与通知服务之间的事件通道之后，通知服务状态检测任务向服务端发送事件通道可用消息，通过该事件通道可用消息指示服务端将缓存在该内存的事件通过该事件通道发送到通知服务。可见，这种方式可以保证最新发生地一定数量的未上报事件不会丢失。

进一步地，本实施例提供的服务处理方法还可以包括如下步骤：若通知服务状态检测任务检测到通知服务上创建的事件通道发生异常，则确定名字服务由停止服务状态转换为开始服务状态，通知服务状态检测任务创建服务端与通知服务之间的事件通道。本实施例提供的通知服务状态检测任务对通知服务的服务状态进行检测，检测的通知服务的服务状态除包括通知服务异常重启外，还可以包括通知服务的其他异常状况，如通知服务上的事件通道异常。通知服务状态检测任务对通知服务上的事件通道的状态进行检测，当检测到事件通道异常时，通知服务状态检测任务代替服务端向通知服务重新创建事件通道，以保证后续操作正常化。

本实施例提供了一种服务处理方法，在本实施例中，CORBA应用的服务端通过设置并启动通知服务状态检测任务，并在通知服务的整个运行期间运行，对通知服务的状态进行不断地检测，一旦检测到通知服务的状态发生异常时，即通知服务异常重启或发生事件通道异常等，则在该通知服务上重新创建事件通道，消除了现有技术中对于CORBA应用的服务端应用对通知服务的启动依赖性和注册依赖性，使得通知服务异常重启后，无需重启服务端，仍可以进行正常的事件通道的创建以及事件的上报，不影响整个网络的正常运营，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图7为本发明服务处理方法还一实施例的信令图，如图7所示，本实施例提供了另一种服务处理方法，本实施例针对CORBA应用的服务端应用与名字服务在启动期和运行期的松耦合方案，具体包括如下步骤：

步骤701，CORBA服务端启动后，该服务端启动服务端对应的名字服务定期注册任务。

步骤702，服务端通过名字服务定期注册任务以预定的时间周期将服务端的对象服务信息注册到名字服务上。

本实施例采用的方法为与上述图2-图3所示的方法不同，本实施例为对上述实施例的一种简化，在本实施例中设置的名字服务管理任务为服务端对应的名字服务定期注册任务，而不是名字服务状态检测任务，名字服务定期注册任务可以为服务端的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。此处所指的预定的时间周期为名字服务定期注册任务执行注册动作的时间间隔，该时间间隔由用户根据名字服务在运行过程中的实际情况而设定的，如考虑名字服务可能出现异常的频率，以及事件发生的频率等实际情况，使得名字服务由停止服务状态转换为开始服务状态的时间位于该预定的时间周期内。当然，设定的时间周期越短越能减少因名字服务异常而导致的网络运营异常的概率，但同时名字服务定期注册任务的高频率运行也导致***资源的占用率提高，影响***运行的效率，因此，用户在设定任务运行的间隔时间时，需要进行以上方面的权衡考虑。

名字服务定期注册任务在名字服务的启动期即启动，不管名字服务的状态如何，均定期向名字服务进行对象服务信息的注册。如上述步骤中，当名字服务出现异常重启之后，名字服务定期注册任务会将服务端的对象服务信息注册到名字服务上，因此客户端应用仍可以从名字服务上正常获取对象服务信息，不会影响网络的正常运营。而且采用本实施例提供的方法时，由于名字服务定期注册任务不断地在名字服务上注册对象服务信息，服务端应用也可以在名字服务启动之前启动，解除了服务端应用对于名字服务的启动依赖性。本实施例提供的方法为对上述实施例的一种简化，无需定期检测名字服务的状态，因此降低了CORBA应用的服务端的实现复杂度，同时还可以保证对象服务信息的注册可靠性，但CORBA应用的客户端在获取其感兴趣的事件时，由于其不能确定当前的事件通道是否可用，需要侦听通知服务上的所有事件通道。

本实施例提供了一种服务处理方法，通过设置名字服务定期注册任务，不管名字服务的状态如何，定期向名字服务注册对象服务信息，消除了现有技术中对于CORBA应用的服务端对名字服务的启动依赖性和注册依赖性，使得服务端先于名字服务启动时，仍可以进行正常的对象服务信息的注册以及对象服务接口的调用，而且当名字服务异常重启后，无需重启服务端，仍可以进行正常的对象服务信息的注册以及对象服务接口的调用，不影响整个网络的正常运营，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图8为本发明服务处理方法又另一实施例的信令图，如图8所示，本实施例提供的服务处理方法包括如下步骤：

步骤801，服务端启动对应的配置信息变更检测任务。

步骤802，服务端通过配置信息变更检测任务定期检测名字服务的配置信息的状态。

步骤803，当配置信息变更检测任务检测到名字服务的配置信息发生更新，则确定名字服务由停止服务状态转换为开始服务状态，并通过配置信息变更检测任务将服务端的对象服务信息注册到新的名字服务上。

在本实施例中，名字服务的相关信息可以通过配置信息进行定制，而非固定在可执行代码中，即名字服务是可以根据配置信息而改变的，配置信息发生变更时，名字服务也变为另一种新的名字服务。服务端可以在其启动期即启动对应的配置信息变更检测任务，通过配置信息变更检测任务定期检测名字服务的配置信息的状态。当配置信息变更检测任务检测到名字服务的配置信息发生变更时，则表明名字服务变更为新的名字服务，确定名字服务由停止服务状态转换为开始服务状态，配置信息变更检测任务将所述服务端的对象服务信息注册到配置信息更新后的名字服务上。同时，配置信息变更检测任务向服务端发送配置信息更新消息，由该配置信息更新消息指示名字服务的配置信息发生变化，在将对象服务信息注册到新的名字服务注册上后，客户端后续便可从新的名字服务上获取对象服务信息。

本实施例提供了一种服务处理方法，通过设置并启动配置信息变更检测任务，检测名字服务的配置信息的状态，当检测到名字服务的配置信息发生变化时，则服务端向新的名字服务注册对象服务信息，实现了在名字服务发生变化时无需重启服务端，自动进行对象服务信息的注册，不影响整个网络的正常运营，从而解除了CORBA应用与名字服务的启动依赖性，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图9为本发明服务处理方法又再一实施例的信令图，如图9所示，本实施例提供了另一种服务处理方法，本实施例针对CORBA应用的服务端应用与通知服务在启动期和运行期的松耦合方案，具体包括如下步骤：

步骤901，CORBA服务端启动后，该服务端启动通知服务定期创建任务。

步骤902，服务端通过通知服务定期创建任务，以预定的时间周期定期在通知服务上创建事件通道。

本实施例采用的方法为与上述图5-图6所示的方法不同，本实施例为对上述实施例的一种简化，在本实施例中设置的通知服务管理任务为服务端对应的通知服务定期创建任务，而不是通知服务状态检测任务，通知服务定期创建任务可以为服务端的一个线程或者一个定时任务，也可以为一个独立的进程或进程组。此处所指的预定的时间周期为通知服务定期创建任务执行通道创建动作的时间间隔，该时间间隔由用户根据通知服务在运行过程中的实际情况而设定的，如考虑通知服务可能出现异常的频率，以及事件发生的频率等实际情况，使得该通知服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内。当然，设定的时间周期越短越能减少因通知服务异常而导致的网络运营异常的概率，但同时通知服务定期创建任务的高频率运行也导致***资源的占用率提高，影响***运行的效率，因此，用户在设定任务运行的间隔周期时，需要进行以上方面的权衡考虑。

通知服务定期创建任务在通知服务的启动期即启动，不管通知服务的状态如何，均定期在通知服务上销毁原有事件通道，并创建新的事件通道。如上述步骤中，当通知服务出现异常重启之后，通知服务定期创建任务会代替服务端创建与通知服务之间的事件通道，因此服务端仍可以将后续事件通过事件通道上报到通知服务，客户端仍可以通过通知服务接收转发的事件，不会影响网络的正常运营。而且采用本实施例提供的方法时，由于通知服务定期创建任务不断地在通知服务上创建事件通道，服务端也可以在通知服务启动之前启动，解除了服务端对于通知服务的启动依赖性。本实施例提供的方法为对上述实施例的一种简化，无需定期检测通知服务的状态，因此降低了CORBA应用的服务端的实现复杂度，同时还可以保证事件通道创建的可靠性。

本实施例提供了一种服务处理方法，通过设置通知服务定期创建任务，不管通知服务的状态如何，定期在通知服务上创建事件通道，消除了现有技术中对于CORBA应用的服务端对通知服务的启动依赖性和注册依赖性，使得服务端先于通知服务启动时，仍可以进行正常的事件通道的创建以及事件的上报，而且当通知服务异常重启后，无需重启服务端应用，仍可以进行正常的事件通道的创建以及事件的上报，不影响整个网络的正常运营，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图10为本发明服务处理方法又还一实施例的信令图，如图10所示，本实施例提供的服务处理方法包括如下步骤：

步骤1001，CORBA服务端启动之后，该服务端启动对应的配置信息变更检测任务。

步骤1002，服务端通过配置信息变更检测任务定期检测通知服务的配置信息的状态。

步骤1003，当配置信息变更检测任务检测到通知服务的配置信息发生更新时，则确定通知服务由停止服务状态转换为开始服务状态，通过配置信息变更检测任务创建服务端与新的通知服务之间的事件通道。

在本实施例中，通知服务的相关信息可以通过配置信息进行定制，而非固定在可执行代码中，即通知服务是可以根据配置信息而改变的，配置信息发生变更时，通知服务也变为另一种新的通知服务。服务端可以在其启动期即启动对应的配置信息变更检测任务，通过配置信息变更检测任务定期检测通知服务的配置信息的状态。当配置信息变更检测任务检测到通知服务的配置信息发生变更时，则表明通知服务变更为新的通知服务，确定通知服务由停止服务状态转换为开始服务状态，配置信息变更检测任务创建服务端与新的通知服务之间的事件通道。同时，配置信息变更检测任务向服务端发送配置信息更新消息，由该配置信息更新消息指示服务端通知服务的配置信息发生变化，在新的事件通道创建成功后，服务端通过新的事件通道将事件上报到通知服务，客户端后续便可通过新的通知服务上获取感兴趣的事件。

本实施例提供了一种服务处理方法，通过设置并启动配置信息变更检测任务，检测通知服务的配置信息的变状态，当检测到通知服务的配置信息发生变化时，则创建服务端与新的通知服务之间的事件通道，实现了在通知服务发生变化时无需重启服务端，自动进行事件通道的创建，不影响整个网络的正常运营，从而解除了CORBA应用与通知服务的启动依赖性，直接降低了CORBA接口在网络部署上的难度，提高了接口的可靠性，大大降低了出现问题的几率和维护成本。

图11为本发明公共对象请求代理结构服务端装置一实施例的结构图，如图11所示，本发明实施例提供的一种公共对象请求代理结构服务端装置包括第一任务启动模块1101和第一服务管理模块1102。其中，第一任务启动模块1101用于在本服务端启动后，启动名字服务管理任务。第一服务管理模块1102用于在名字服务由停止服务状态转换为开始服务状态后，通过名字服务管理任务将服务端的对象服务信息注册到名字服务上。名字服务管理任务在物理形态上可以为服务端的一个子模块，也可以为一个独立的模块。第一服务管理模块1102在名字服务启动之前启动，并在名字服务的整个运行期间运行。第一服务管理模块1102可以在名字服务运行正常时向名字服务注册对象服务信息，也可以在名字服务运行异常时仍然向名字服务注册对象服务信息。本实施例提供的服务端装置使得CORBA应用的服务端的启动不再依赖于名字服务的启动，当名字服务异常重启后，无需再手动重启CORBA应用，服务端应用仍正常向名字服务注册对象服务信息，保证了后续客户端可以正常获取到对象服务信息，大大降低了维护和咨询成本，减少了定位失败。

具体地，名字服务管理任务可以具体为名字服务状态检测任务，则第一服务管理模块1102可以包括第一名字服务状态检测子模块和第一信息注册子模块。其中，第一名字服务状态检测子模块用于通过名字服务状态检测任务检测名字服务的服务状态；第一信息注册子模块用于当检测到所述名字服务从停止服务状态转为开始服务状态时，通过名字服务状态检测任务将服务端的对象服务信息注册到名字服务上。具体地，在名字服务状态检测任务检测到名字服务从停止服务状态转为开始服务状态时，包括检测到名字服务首次启动、正常重启以及异常重启的状态，第一信息注册子模块代替服务端将服务端的对象服务信息注册到名字服务上，使得在名字服务后于服务端启动时，或者在名字服务出现异常重启之后，仍可以正常向名字服务注册对象服务信息，而客户端可以正常从名字服务上获取对象服务信息，不影响整个网络的正常运营。

或者，名字服务管理任务具体为名字服务状态检测任务，第一服务管理模块1102可以包括第二名字服务状态检测子模块和第二信息注册子模块。其中，第二名字服务状态检测子模块用于通过名字服务状态检测任务检测名字服务的服务状态；第二信息注册子模块用于当检测到名字服务上注册的对象服务信息与客户端获取的对象服务信息不一致时，确定名字服务由停止服务状态转换为开始服务状态，并通过名字服务状态检测任务将服务端的对象服务信息注册到名字服务上。

或者，名字服务管理服务具体为名字服务定期注册任务，第一服务管理模块1102可以包括信息定期注册子模块。信息定期注册子模块用于通过名字服务定期注册任务以预定的时间周期将服务端的对象服务信息注册到名字服务上，该名字服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内。不管名字服务的状态如何，均通过名字服务定期注册任务定期向名字服务进行对象服务信息的注册，当名字服务出现异常重启之后，名字服务定期注册任务会将服务端的对象服务信息注册到名字服务上，因此客户端应用仍可以从名字服务上正常获取对象服务信息，不会影响网络的正常运营。

或者，名字服务管理服务具体为配置信息变更检测任务，第一服务管理模块1102可以包括配置信息检测子模块和第三信息注册子模块。其中该配置信息检测子模块用于检测名字服务的配置信息，当检测到名字服务的配置信息发生更新时，则确定名字服务由停止服务状态转换为开始服务状态；第三信息注册子模块用于通过配置信息变更检测任务将服务端的对象服务信息注册到配置信息更新后的名字服务上。

本实施例提供了一种CORBA服务端装置，通过第一任务启动模块和第一服务管理模块，完成在名字服务发生异常时向名字服务上注册对象服务信息，解决了CORBA应用与名字服务之间的启动依赖和注册依赖问题，解除了CORBA应用与名字服务之间启动顺序的限制，实现了在名字服务出现异常时保证网络的正常运营，同时大大降低了维护和咨询成本，减少了定位失败。

图12为本发明公共对象请求代理结构服务端装置另一实施例的结构图，如图12所示，本发明实施例提供的一种公共对象请求代理结构服务端装置包括第二任务启动模块1201和第二服务管理模块1202。其中，第二任务启动模块1201用于在本服务端启动后，启动通知服务管理任务。第二服务管理模块1202用于在通知服务由停止服务状态转换为开始服务状态后，通过通知服务管理任务创建服务端与通知服务的事件通道。通知服务管理任务在物理形态上可以为服务端的一个子模块，也可以为一个独立的模块。通知服务管理任务在通知服务启动之前启动，并在通知服务的整个运行期间运行。第二服务管理模块1202可以在通知服务运行正常时向通知服务创建事件通道，也可以在通知服务运行异常时仍然向通知服务创建事件通道。本实施例提供的服务端装置使得CORBA应用的服务端的启动不再依赖于通知服务的启动，当通知服务异常重启后，无需再手动重启CORBA应用，服务端应用仍正常向通知服务创建事件通道，保证了后续通知服务也可以正常通过事件通道向客户端转发事件，大大降低了维护和咨询成本，减少了事件丢失。

具体地，通知服务管理任务可以具体为通知服务状态检测任务，则第二服务管理模块1202可以包括：第一通知服务状态检测子模块和第一通道创建子模块。其中，第一通知服务状态检测子模块用于通过通知服务状态检测任务检测通知服务的服务状态；第一通道创建子模块用于当检测到所述通知服务从停止服务状态转为开始服务状态时，通过通知服务状态检测任务创建服务端与通知服务之间的事件通道。

或者，通知服务管理任务具体为通知服务状态检测任务，则第二服务管理模块1202包括第二通知服务状态检测子模块和第二通道创建子模块。其中，第二通知服务状态检测子模块用于通过通知服务状态检测任务检测通知服务的服务状态；第二通道创建子模块用于当检测到通知服务上创建的事件通道发生异常时，确定通知服务由停止服务状态转换为开始服务状态，并通过通知服务状态检测任务创建服务端与通知服务之间的事件通道。

或者，通知服务管理任务可以具体为通知服务定期创建任务，则第二服务管理模块1202包括通道定期创建子模块。该通道定期创建子模块用于通过通知服务定期创建任务以预定的时间周期创建服务端与通知服务之间的事件通道，该通知服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内。无论通知服务的状态如何，第三通知服务子模块定期销毁原事件通道，向通知服务创建新的事件通道，因此，在通知服务出现异常重启之后，不会因为未重新启动服务端装置，未在通知服务上创建事件通道，而使得后续上报事件失败，客户端获取不到感兴趣的事件。

或者，通知服务管理任务具体为配置信息变更检测任务，则第二服务管理模块1202包括配置信息检测子模块和第三通道创建子模块。其中，配置信息检测子模块用于通过配置信息变更检测任务检测通知服务的配置信息，当检测到通知服务的配置信息发生更新，确定通知服务由停止服务状态转换为开始服务状态。第三通道创建子模块用于通过该配置信息变更检测任务创建服务端与新的通知服务之间的事件通道。

本实施例提供了一种CORBA服务端装置，通过第二任务启动模块和第二服务管理模块，完成在通知服务发生异常时在通知服务上创建事件通道，解决了CORBA应用与通知服务之间的启动依赖和注册依赖问题，解除了CORBA应用与通知服务之间启动顺序的限制，实现了在通知服务出现异常时保证网络的正常运营，同时大大降低了维护和咨询成本，减少了事件丢失。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。

Claims (12)

1.一种服务处理方法，其特征在于，包括：

公共对象请求代理结构服务端启动后，该服务端启动名字服务管理任务；

在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上。

2.根据权利要求1所述的服务处理方法，其特征在于，所述名字服务管理任务具体为名字服务状态检测任务；所述在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上包括：

通过所述名字服务状态检测任务检测名字服务的服务状态；

当检测到所述名字服务从停止服务状态转为开始服务状态时，通过所述名字服务状态检测任务将服务端的对象服务信息注册到名字服务上；

或者：

通过所述名字服务状态检测任务检测名字服务的服务状态；

当检测到所述名字服务上注册的对象服务信息与客户端获取的对象服务信息不一致时，确定所述名字服务由停止服务状态转换为开始服务状态；

通过所述名字服务状态检测任务将所述服务端的对象服务信息注册到名字服务上。

3.根据权利要求1所述的服务处理方法，其特征在于，所述名字服务管理任务具体为名字服务定期注册任务，所述在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上包括：

通过所述名字服务定期注册任务以预定的时间周期将服务端的对象服务信息注册到所述名字服务上，该名字服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内。

4.根据权利要求1所述的服务处理方法，其特征在于，所述名字服务管理任务具体为配置信息变更检测任务；所述在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上包括：

通过配置信息变更检测任务检测所述名字服务的配置信息，当检测到所述名字服务的配置信息发生更新时，确定所述名字服务由停止服务状态转换为开始服务状态；

通过所述配置信息变更检测任务将所述服务端的对象服务信息注册到配置信息更新后的名字服务上。

5.一种服务处理方法，其特征在于，包括：

公共对象请求代理结构服务端启动后，该服务端启动通知服务管理任务；

在通知服务由停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道。

6.根据权利要求5所述的服务处理方法，其特征在于，所述通知服务管理任务具体为通知服务状态检测任务；所述在通知服务由停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道包括：

通过所述通知服务状态检测任务检测通知服务的服务状态；

当检测到所述通知服务从停止服务状态转为开始服务状态时，通过所述通知服务状态检测任务创建服务端与通知服务之间的事件通道；

或者：

通过所述通知服务状态检测任务检测通知服务的服务状态；

当检测到所述通知服务上创建的事件通道发生异常时，确定所述通知服务由停止服务状态转换为开始服务状态；

通过所述通知服务状态检测任务创建所述服务端与通知服务之间的事件通道。

7.根据权利要求5所述的服务处理方法，其特征在于，所述通知服务管理任务具体为通知服务定期创建任务，所述在通知服务停止服务转化为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道包括：

通过所述通知服务定期创建任务以预定的时间周期创建服务端与通知服务之间的事件通道，该通知服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内。

8.根据权利要求5所述的服务处理方法，其特征在于，所述通知服务管理任务具体为配置信息变更检测任务；所述在通知服务由停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道包括：

通过配置信息变更检测任务检测所述通知服务的配置信息，当检测到所述通知服务的配置信息发生更新，确定所述通知服务由停止服务状态转换为开始服务状态；

通过所述配置信息变更检测任务创建所述服务端与配置信息更新后的通知服务之间的事件通道。

9.一种公共对象请求代理结构服务端装置，其特征在于，包括：

第一任务启动模块，用于在服务端启动后，启动名字服务管理任务；

第一服务管理模块，用于在名字服务由停止服务状态转换为开始服务状态后，通过所述名字服务管理任务将服务端的对象服务信息注册到所述名字服务上。

10.根据权利要求9所述的装置，其特征在于，

所述名字服务管理任务具体为名字服务状态检测任务；所述第一服务管理模块包括：

第一名字服务状态检测子模块，用于通过所述名字服务状态检测任务检测名字服务的服务状态；

第一信息注册子模块，用于当检测到所述名字服务从停止服务状态转为开始服务状态时，通过所述名字服务状态检测任务将服务端的对象服务信息注册到名字服务上；

或者，所述名字服务管理任务具体为名字服务状态检测任务，所述第一服务管理模块包括：

第二名字服务状态检测子模块，用于通过所述名字服务状态检测任务检测名字服务的服务状态；

第二信息注册子模块，用于当检测到所述名字服务上注册的对象服务信息与客户端获取的对象服务信息不一致时，确定所述名字服务由停止服务状态转换为开始服务状态，并通过所述名字服务状态检测任务将所述服务端的对象服务信息注册到名字服务上；

或者，所述名字服务管理服务具体为名字服务定期注册任务，所述第一服务管理模块包括：

信息定期注册子模块，用于通过所述名字服务定期注册任务以预定的时间周期将服务端的对象服务信息注册到名字服务上，该名字服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内；

或者，所述名字服务管理服务具体为配置信息变更检测任务，所述第一服务管理模块包括：

配置信息检测子模块，用于检测所述名字服务的配置信息，当检测到所述名字服务的配置信息发生更新时，确定所述名字服务由停止服务状态转换为开始服务状态；

第三名字服务信息注册子模块，用于通过所述配置信息变更检测任务将所述服务端的对象服务信息注册到配置信息更新后的名字服务上。

11.一种公共对象请求代理结构服务端装置，其特征在于，包括：

第二任务启动模块，用于在服务端启动后，启动通知服务管理任务；

第二服务管理模块，用于在通知服务由停止服务状态转换为开始服务状态后，通过所述通知服务管理任务创建服务端与通知服务的事件通道。

12.根据权利要求11所述的装置，其特征在于，

所述通知服务管理任务具体为通知服务状态检测任务；所述第二服务管理模块包括：

第一通知服务状态检测子模块，用于通过所述通知服务状态检测任务检测通知服务的服务状态；

第一通道创建子模块，用于当检测到所述通知服务从停止服务状态转为开始服务状态时，通过所述通知服务状态检测任务创建服务端与通知服务之间的事件通道；

或者，所述通知服务管理任务具体为通知服务状态检测任务；所述第二服务管理模块包括：

第二通知服务状态检测子模块，用于通过所述通知服务状态检测任务检测通知服务的服务状态；

第二通道创建子模块，用于当检测到所述通知服务上创建的事件通道发生异常时，确定所述通知服务由停止服务状态转换为开始服务状态，并通过所述通知服务状态检测任务创建所述服务端与通知服务之间的事件通道；

或者，所述通知服务管理任务具体为通知服务定期创建任务；所述第二服务管理模块包括：

通道定期创建子模块，用于通过所述通知服务定期创建任务以预定的时间周期创建服务端与通知服务之间的事件通道，该通知服务由停止服务状态转换为开始服务状态的时间位于预定的时间周期内；

或者，所述通知服务管理任务具体为配置信息变更检测任务；所述第二服务管理模块包括：

配置信息检测子模块，用于通过所述配置信息变更检测任务检测所述通知服务的配置信息，当检测到所述通知服务的配置信息发生更新，确定所述通知服务由停止服务状态转换为开始服务状态；

第三通道创建子模块，用于通过所述配置信息变更检测任务创建所述服务端与更新后的通知服务之间的事件通道。

Images