CN1419188A

CN1419188A - 外部事件处理器系统和方法

Info

Publication number: CN1419188A
Application number: CN02130110.7A
Authority: CN
Inventors: 保罗·A.·约翰逊
Original assignee: Alcatel NV
Current assignee: Alcatel CIT SA; Alcatel Lucent SAS; Alcatel Lucent NV
Priority date: 2001-09-12
Filing date: 2002-08-21
Publication date: 2003-05-21
Anticipated expiration: 2022-08-21
Also published as: US20030050983A1; EP1293900A2; CN1285032C; EP1293900A3

Abstract

本发明涉及网络和分布式部件管理系统。公开一种包含允许重新格式化接收的事件，并且把这些事件传送给先前登记的事件用户的独立软件组件的外部事件处理器(EEP)系统和方法。本发明教导了在单独的软件进程内运行的应付事件处理和传送的独立软件组件的产生。该独立软件进程具有由网络管理应用软件用于以事件的最基本形式向外部事件处理器(EEP)发送事件的远程接口。随后，EEP执行把提供的事件转换成外部事件用户所需的恰当形式和类型必需的所有其它子例程。另外，EEP向事件提供外部用户所需的服务质量(QoS)性能。

Description

外部事件处理器系统和方法

技术领域

本发明涉及网络和分布式部件管理系统(EMS)，以及可用于使响应网络协议的变化和/或新的/修改的网络部件(NE)的加入时，EMS的维护开销降至最小的软件技术。

概述(0100)

如图1(0100)中所示，本发明适用于存在通过事件通道(0120)与目标事件用户/接收器(0130)通信的一个或多个事件供给者/源(0110)的情况。许多分布式软件解决方案借助事件交换大量的数据。必须从初始事件供给者(0110)高效地把这些事件传送给最终的事件用户(0130)。在复杂系统中，传送机构通常是一组事件通道(0120)。通道的数目和事件内容取决于应用。为了完成事件传送体系结构，初始事件供给者(0110)和事件用户(0130)必须和事件通道(0120)相连。

本发明具体涉及如同在外部事件处理器(EEP)(0140)中实现的事件处理的变换和接口管理方面。所述EEP组件提供可直接与网络部件(0111、0112)和/或主应用软件(0150)通信的外部接口，从而协调事件源(0110)和事件接收器(0130)之间通过一个或多个事件通道(0120)的事件通信。

例证应用(0200)

如图2中所示，本发明可应用于存在一个或多个电信网络(0210、0220)的情形，所述电信网络(0210、0220)可包括来自不同卖主的设备，也可不包括来自不同卖主的设备。这些网络内使用的网络设备部件(NE)(0215、0216、0225、0226)可采取多种形式，包括(但不限于)交换传动装置(switch gear)、多路复用器等。这些网络部件(0215、0216、0225、0226)通常由一个或多个计算机系统(0211、0221)控制，所述一个或多个计算机系统(0211、0221)由可保存在各种存储介质上的计算机软件(0212、0222)控制。该计算机软件通常采取控制并监控网络部件(0215、0216、0225、0226)的一个或多个网络部件管理器(0213、0214、0223、0224)的形式，所述网络部件(0215、0216、0225、0226)包括电信网络(0210、0220)的组成组件。在这些情况下，本发明可特别涉及事件传送体系结构(ETA)的实现，因为它和一个或多个电信网络(0210、0220)的环境内的各种网络部件(0215、0216、0225、0226)的整体控制和监控相关。

背景技术

为了把事件从网络部件传送给外部软件组件，网络管理软件通常必须满足多个有时相互冲突的要求。不同的事件类型和格式、登记事件并且它们的流程的不同接口和不同的服务质量(QoS)要求都是不同种类的软件组件所需要的。每个组件希望接收关于网络部件的事件，但是希望按照它们自己的条件接收事件。在网络管理软件的生命期内，要求新的软件版本和软件的现有安装的现场改变中，这些要求也会发生变化。

服务于多个事件用户的这些不同事件传送需要是一项困难的任务。一种典型的方法是在单个应用程序组件中满足这些要求，所述单个应用程序组件还用于管理其它基本(但是和事件无关的)子例程(function)。这种“一体化”方法导致应付需求变化方面较高的开发费用、较高的维护费用和较低的灵活性。这是因为所有事件传送权能与其它所有子例程耦合在一起，所有权能在一个组件中的缘故。

由于在事件传送子例程组和其它子例程组之间必定是封闭、连续并且高度集成的开发，因此软件开发费用较高。为了满足事件传送要求，软件设计通常影响组件的外部接口，其持久机构，其内部配置，组件中线程的应用以及实现技术的选择。这些选择中的每一种都会和由与事件无关的子例程驱动的其它组件设计决策冲突。为了调和这些(可能冲突的)选择，必须进行更多的工作。这导致费用更高。另外还导致与事件传送相关的设计决策和其它各个子例程的设计决策之间的高度耦合。

由于初始软件设计的复杂性，任意变化将导致和较简单设计相比更高的维护费用。更坏的是，由于过度耦合的缘故，即使事件传送要求方面的细微变化都需要改写与事件无关的其它组件设计选择。

最后，使事件传送子例程和所有其它子例程耦合在一起的整个复合组件极不易于改变。假定新的客户程序希望接收事件，但是需要使用不同于其它客户程序的外部接口。在初始的封闭的耦合设计的条件下，这种新要求甚至不可实现。如果这样，则仅仅对于这种新的事件传送特征，就必须产生初始软件组件的新版本软件组件。随后，必须替换该组件的各种安装版本，以便该新特征可用。通常这要求停止正在运行的组件并重启新版本的软件组件。不幸的是，仅仅为了改变事件传送特征，就必须停止所有其它子例程。在服务于任务关键性业务需要(mission-critical business needs)的大型系统中，这是极不可取的。

从根本上来说，问题是如何以把必需的事件传送特征和所有其它网络管理子例程分离的方式，在软件内最好地实现必需的事件传送特征。

现有的针对该问题的最佳解决方案是在单独的软件包中隔离事件传送软件实现。软件包是独立文件或一组文件中的成组专用软件功能。主应用程序通过应用编程接口(API)访问该软件包。通过把事件传送特征封装到单独的软件包中，减少了这些子例程和主应用程序的其它子例程之间的耦合。

对于现有解决方案来说，事件传送的驱动要求需要事件传送软件包中的关键设计决策，所述关键设计决策影响使用事件传送软件包的主应用软件。现有解决方案要求主应用软件和事件传送软件包在相同的软件过程中。从而，事件传送软件包中影响该过程的决策也会影响主应用软件。关于持久存储、控制的穿线(threading)，外部接口，其它第三方产品的使用，其它程序库或软件包的使用的决策会整体影响该单个软件过程。事件传送软件包的这许多决策不得不和主应用软件的那些决策结合起来，否则该单个软件过程将不能正确地工作。

此外，如果事件传送方面的新要求改变了软件包，则不得不修改所有这些设计决策。一旦完成新的设计，则必须产生新版本的主应用软件。随后必须利用该新版本的主应用软件替换现有的已安装的应用程序。这种方法不能克服必须停止并且随后重启主应用程序的问题。

某些软件组装技术足够复杂，这里可独立于使用软件包的应用程序调度软件包。但是只有当软件包与主应用软件的耦合较弱时，才可使用这种独立调度。由于上述耦合原因的缘故，对于提供事件传送特征的软件来说，这种情况较罕见。

发明内容

因此，本发明的目的是克服现有技术的缺点并实现下述目标：

(1)降低与事件处理系统相关的软件维护开销。

(2)减少事件传送和主应用软件之间的耦合。

(3)允许在不需要软件系统重启和/或应用程序系统中断的情况下更新事件传送机构。

(4)降低大型复杂和/或任务关键系统应用程序中的调度复杂性。

(5)把事件处理功能分成单独的软件组件，所述单独的软件组件封装逻辑上紧密结合在一起的一组必要事件传送功能。

(6)把关于事件的所有策略封装到单一软件组件中。对这些策略的后续改变只会影响该单一组件。

(7)允许独立于其它框架组件，开发并测试涉及事件的功能。这一特征使得能够并行形成类属部件管理(GEM)框架和后续测试。

(8)在不必改变其它GEM组件的情况下增加新的与事件相关的接口。

这些目的不应被理解为对本发明的限制，一般而言，这些目的部分或者完全由下述各节中说明的公开发明实现。本领域的技术人员毫无疑问能够选择所公开的本发明的各个方面，实现上述目的的任意组合。

本发明与现有技术的不同之处在于不是把事件传送特征封装到单独的软件包中，而是把事件传送执行过程放入单独的软件过程中。这打破了事件传送特征和主应用程序软件中那些特征之间的执行设计耦合。通过备有单独的过程，与事件传送相关的任意设计决策不会影响主软件过程；只会影响事件传送组件的过程。从而新组件封装与事件传送相关的所有执行设计决策。

提供与该新组件的外部接口，从而主应用软件可发送来自于网络部件的基本事件。新组件负责把接收的事件转换成客户程序事件用户所需的格式和所要求的类型。新组件向客户程序提供所需的外部接口，以便登记接收事件。

通过把所有事件传送特征放入在其自身的软件过程中运行的独立组件，消除了所有直接耦合。可完全独立于主应用程序实现独立组件。避免了与现有技术产生的直接耦合相关的所有问题。

本发明避免了现有解决方案的问题以及它们的相关费用。可计量的费用随着具体的事件传送要求而变化。在要求极小的某些情况下，这些费用很小，本发明的成本效率并不高。当需要具有不同接口和基本不同接口要求的多种事件用户时，本发明的成本效率将很高。

此外，作为单独的软件过程，可在不影响其它网络管理子例程的情况下现场更新本发明。实际上，可在几乎不影响对于事件用户的事件传送的情况下，停止并以其新形式重新启动本发明。

本发明的唯一缺陷在于要求开发并使用单独的软件组件。新软件组件的开发费用和开发单独软件包的费用大体相当，开发单独软件包是关于所解决的事件传送问题的一种现有解决方案。但是这种解决方案的开发费用高于单独的软件组件的开发费用。必须以任意其它应用软件的形式在其运行期环境中管理并控制软件组件。但是这些费用仅仅是递增的，因为也必须把这些能力提供给主应用程序。

附图说明

为了更充分地理解本发明的优点，应结合附图参考下述详细说明，其中：

图1图解说明本发明的通用系统概述；

图2图解说明本发明如何通过软件控制，连接到包括计算机监控、配置等的集成的多卖主网络管理系统的例证体系结构；

图3图解说明利用本发明的通用系统应用程序；

图4图解说明本发明的优选实施例的内部功能结构，并且图解说明例证应用程序如何连接事件调度程序、事件转换程序和事件监听程序，以便按照恰当的格式把接收的事件传送给客户程序；

图5举例说明应用程序包中公共可见的主要类程；

图6举例说明调度模块中公共可见的主要类程；

图7举例说明ECOM客户程序模块中公共可见的主要类程；

图8举例说明GEM客户程序模块中公共可见的主要类程；

图9举例说明转换模块中公共可见的主要类程；

图10举例说明传送模块中公共可见的主要类程；

图11图解说明例证应用程序的功能行为的概述；

图12图解说明例证应用程序如何读取其配置文件并初始化其内部权能；

图13图解说明例证应用程序如何初始化其内部事件转换权能并使之与内部事件传送机构相连；

图14图解说明例证应用程序如何初始化内部事件传送结构；

图15图解说明例证应用程序如何处理客户程序登记，以便接收事件；

图16图解说明例证应用程序如何接收事件、处理事件并且把事件发送给登记的客户程序。

具体实施方式

虽然本发明具有多种不同形式的实施例，附图中所示及这里将详细说明的本发明的优选实施例表示本公开文献应被看作对本发明原理的举例说明，而不是打算把本发明的范围局限于举例说明的实施例。

下面将参考优选实施例说明本申请的许多创新教导，其中这些创新教导被应用于分布式外部事件处理系统和方法的特定问题。但是，应明白本实施例只是创新教导的众多有利应用的一个例子。一般说来，本申请说明书中作出的陈述并不必然限定所要求的各项发明中的任意一项发明。此外，某些陈述可应用于某些发明特征，但是不能应用于其它发明特征。

定义

在本文献的讨论中，采用下述定义：

系统方框/程序步骤

可利用例证的系统方框图和程序流程图适当地说明本发明。虽然这些内容足以向本领域的普通技术人员说明本发明的教导，但是它们不应被严格地理解为限定本发明的范围。本领域的技术人员将意识到在不损失通用性的情况下可组合和重新排列系统方框图，可以增加或减去程序步骤，并且可对程序步骤重新排列，获得相同的效果而不丧失通用性。从而应明白在所附的例证系统方框图和程序流程图中说明的本发明只是出于讲授目的，根据预期的应用目的，本领域的技术人员可改写本发明。

个人计算机

在这里的说明中，将利用个人计算机(PC)技术来举例说明本发明的教导。术语“个人计算机”应理解为可用于实现本发明的教导的任意计算装置，本发明的范围并不仅仅局限于个人计算机应用。

因特网/内联网

在这里的说明中，术语因特网和内联网用于表示任意网络通信系统或环境。通常术语内联网将表示相对于指定系统或用户的本地通信，因特网描述更远距离的本地通信。本领域的技术人员将认识到在现代通信网络的环境中，这些术语是任意的，决不是对本发明范围的限制。

本发明明确预计在某些实现中，GUI开发框架(和/或其运行期组件)将通过因特网与用于驱动GUI的数据通信。从而，驱动用户接口的应用程序将驻留在一个计算机系统上，并且用于呈现和控制的数据可包含在另一计算机系统上的某处，并且借助任意数目的连网协议访问这些数据。

应用程序编程接口(API)

虽然本发明部分利用诸如软件开发工具包之类标准应用程序编程接口(API)实现，但是并不要求利用这些工具实现本发明。另外注意本发明的结构可合并到标准工具包中，所述标准工具包可以集成到API框架中，也可不集成到API框架中，供标准软件开发框架之用。

操作系统

另外，虽然本发明被实现成优先使用各种Microsoft^操作系统(包括各种Windows^TM变型)，不应被解释把本发明的范围局限于这些特殊的软件组件。特别地，可在其中一些可包含图形用户界面的各种系统中实现这里教导的系统和方法。这些系统的一些例子包括HP-UX^TM、LINUX^TM、SOLARIS和UNIX^TM(及其变型)等等。

数据结构

在一些优选实施例中，可以用各种数据结构体现本发明。但是，这里说明的这种数据结构的形式只是示范性的。本领域的技术人员会很快认识到各种各样其它数据结构可同样用在本申请中。于是，这些包含的任何数据结构都不应被理解为对本发明范围的限制。

通信介质

本发明可体现为通过各种通信介质实现事件通道信息的传送。但是用于传输这里描述的传送的信号格式只是示范性的。本领域的技术人员会很快认识到各种其它通信介质可同样用在本申请中。于是，这里包含的任何通信介质不应被理解为对本发明范围的限制。

CORBA

在某些优选实施例中可利用面向CORBA对象的框架实现本发明。但是，这里描述的实现方式只是示范性的。本领域的技术人员会很快认识到各种其它分布式面向对象的框架可同样用在本申请中。于是，这里包含的任何框架不应被理解为对本发明范围的限制。

通过查阅CORBA标准服务文件( ftp：//ftp.omg.org/pub/docs/ formal/98-12-01.pdf的“The Common Object Request Broker：Architecture and Specification”)可获得在本发明的各个例证实施例的环境中使用的命名服务的详细技术说明。

通过查阅1998 Object Management Group(OMG)Notificationservices，Joint Revised Submission，1998年11月，OMG TC Documenttelecom/98-11-01，BEA Systems等(ftp：//ftp.omg.org/pub/docs/formal/)可获得在本发明的各个例证实施例内使用的通知的详细技术说明。

应用程序概述

与发明的关系的概述

在关于例证应用程序的下述说明中，具体组件与图1中的发明环境相关。在例证的应用程序中，GEM服务程序是主应用软件(0150)。它接收来自网络部件(0111、0112)的事件。它把这些事件发送给EEP(0140)的例证应用程序。EEP随后使用事件通道(0120)把针对具体客户程序重新格式化后的接收事件发送给最终的事件用户客户程序(0130)。就例证的应用程序来说，存在三种事件客户程序，即GEM客户程序、ECOM客户程序和ALMAP客户程序。通常每种客户程序有一个以上的实例和EEP相连。图3以类似于图1的方式表示了例证应用程序的具体细节。

独立应用程序

体现为外部事件处理器(EEP)的本发明一般被实现为独立的应用程序。该应用程序通常在由GEM和事件客户程序用户所使用的同一传送平台上运行。例证的EEP应用程序使用CORBA接口提供对其服务的访问。每当起动或停止其相关的GEM服务程序时，EEP就被启动和停止。

必要的事件接口

EEP具有用于各种事件用户客户程序：GEM客户程序、ECOM客户程序和ALMAP客户程序的公共接口。每种事件用户客户程序使用EEP从GEM服务程序登记接收事件。接收的事件呈具体客户程序预定的形式。GEM服务程序把事件发送给EEP，以便处理并发送给登记的客户程序。

操作行为

在运行期，EEP从GEM服务程序接收事件。这些事件具有支持GEM服务程序要求的结构。当事件起因于物理网络部件(NE)上的活动时，事件将包含专用于发端NE的数据。当收到该事件时，EEP把呈现有GEM格式的事件发送给登记的GEM客户程序。

除此之外，EEP把事件转换并重新格式化成ECOM专用事件结构。就例证应用程序来说，转换是把事件从NE专用数据转换成ECOM类属数据所必需的。随后EEP把新转换并且重新格式化后的事件发送给登记的ECOM客户程序。EEP根据在登记过程中由ECOM客户程序确定的任意筛选及服务质量参数完成上述工作。

最后，EEP可转换并过滤接收的事件，以便传送给登记的ALMAP客户程序。

结构概述(0300)

图3(0300)图解说明了外部事件处理器(EEP)的体系结构。利用矩形表示了不是本例证应用程序一部分的其它外部应用程序。它们包括GEM服务程序(0320)；三种特定的事件客户程序：GEM客户程序(0331)、ECOM客户程序(0332)和ALMAP客户程序(0333)和提供EEP使用的传送事件的事件通道实体的通知服务(0360)。

如图3(0300)中所示，事件客户程序和GEM服务程序通过利用不同的外部接口访问EEP功能。每种客户程序有一个外部接口，GEM服务程序本身有一个外部接口。这些接口都专用于各个外部应用程序。EEP封装如何实现这些外部接口的细节。对信息来说，在通知服务(0360)中还表示了用于各个事件通道的外部接口。

对于所有事件客户程序来说，EEP(0310)的存在是透明的。这些客户程序只知道客户程序专用公共接口。在本例证实施例中，只有GEM服务程序自己(0320)才明确知道EEP。

图3(0300)还图解说明了例证应用程序中事件的流程。网络部件(0340)产生事件并把这些事件发送给GEM服务程序(0320)。通过利用GEM服务程序外部接口(0350)，这些事件被发送给EEP(0310)。EEP根据需要通过过滤、转换并发送事件，处理这些事件。最后，EEP把这些事件发送给所需的事件通道(0370)，以便传送给事件客户程序。

具体的体系结构(0410)

图4(0410)图解说明了EEP过程本身的例证内部体系结构。在本例证实施例中，EEP被表示为一组软件包以及软件包之间的相关性。每个软件包代表EEP内的一个软件模块，并且每个模块包含设计成为该模块提供必需特征的特定类程。

下面给出各个模块的详细说明。

应用程序模块(EEP∷app)(0420)

该模块整体代表该应用程序。它包括启动、停止和控制该应用程序的整个序列所需的类程。

主要职责

1.包含主例程，所述主例程处理配置参数(配置文件和命令行变元)；初始化其它模块；及进入主处理循环。

2.根据请求关闭应用程序。

3.为GEM服务程序提供EEP外部CORBA接口EventProcessor的实现(EventProcessorImpl)。

4.构造EEP使用的一组内部IEventDispatchers，以便把接收的GEM服务程序事件转移到事件客户程序事件通道。

合作者

1.由应用程序模块初始化的所有其它模块。

2.根据需要产生路由事件的IEventDispatcher的实例的调度模块(0490)。

公用程序模块(EEP∷util)(0430)

该模块包括其它软件包使用的所有类属公用子例程。对于理解本例证应用程序来说关于该模块的更多细节是不必要的。本领域的技术人员将认识到这种应用子例程取决于用于建立该例证应用程序的实际实现技术。

公用模块(EEP∷common)(0440)

该模块(0440)包含由所有其它模块共同使用的类程。对于理解本例证应用程序来说关于该模块的更多细节是不必要的。本领域的技术人员将理解当需要公用类程时，把这些公用类程封闭到诸如公用模块之类的模块中。

公用模块(0440)包含由EEP中所有其它内部模块使用的实现专用类程。该模块的内容根据用于构造EEP的实现技术的变化而变化。本领域的技术人员毫无疑问将认识到要使用的专用类程随所采用的具体实现方法而变化。

GEM客户程序模块( EEP：gemClient)(0451)

本模块(0451)包含为GEM客户程序提供公共外部接口必需的所有类程。

主要职责

1.提供GEM客户程序外部接口的实现从而包括线程策略。发布GEM客户程序访问所必需的接口。

2.调用传送模块提供登记、断开和过滤功能。

合作者

1.依赖于用于初始化的app模块(0420)和访问公共资源的公用模块(0440)。

2.依赖于把事件传送给实际Gem客户程序的实际实现的传送模块(0470)。

3.依赖于把Gem服务程序事件转换成Gem客户程序格式化报警事件的转换模块(0470)。

ECOM客户程序模块(EEP∷ecomClient)(0452)

本模块(0452)向ECOM客户程序提供和GEM客户程序模块(0451)向GEM客户程序所提供的完全相同的功能。其主要职责和合作者都和GEM客户程序模块(0451)相同，但是它是用于ECOM客户程序而不是用于GEM客户程序。

ALMAP客户程序模块(EEP∷almapClient)(0453)

本模块(0453)向ALMAP客户程序提供和GEM客户程序模块(0451)向GEM客户程序所提供的完全相同的功能。其主要职责和合作者都和GEM客户程序模块(0451)相同，但是它是用于ALMAP客户程序而不是用于GEM客户程序。

GEM服务程序模块(EEP∷gemserver)(0460)

本模块向GEM服务程序(0320)提供外部接口的实现。

主要职责

1.产生GEM服务程序外部接口的实现并且当GEM服务程序需要时发布该外部接口。

2.提供用于登记GEM服务程序的特征。

3.提供用于从GEM服务程序接收事件，并且把这些事件发送给EEP的其它各个部分的特征。

合作者

1.使用公用程序util(0430)和公用common(0440)模块访问应用程序资源。

2.使用调度模块dispath发送接收的事件。

传送模块(EEP∷transport)(0470)

本模块(0470)提供把事件从EEP传送给事件客户程序的方法。它访问事件通道的外部通知服务(0360)。它配置这些事件通道并且把这些事件通道和内部EEP事件调度机构相连。它产生各种事件客户程序的专用事件传送配置(事件通道，其在EEP内的配置和连接)。以事件的客户程序记录器(register)的形式产生该配置。

合作者

1.使用调度模块(0490)连接事件客户程序的事件通道。

2.使用公用程序(0430)和公用(0440)模块访问应用程序资源。

3.使用通知服务(0360)安排事件的实际传送。

4.由事件客户程序模块、gemClient(0451)、ecomClient(0452)和almapClient(0453)用于指示哪些客户程序需要哪些事件，事件流程的过滤和QoS设置和控制。

转换模块(EEP∷translate)(0480)

本模块(0480)包含可把来自GEM服务程序(0360)的事件转换成各种事件客户程序的专用格式化事件的类程。在运行期，这些类程的实例由app模块(0420)产生，包装到事件监听程序中，并且被登记以便监听来自GEM服务程序的事件。当收到事件时，转换程序把接收的事件转换成特定事件客户程序的恰当格式，并重新发送该事件。

调度模块(EEP∷dispatch)(0490)

本模块(0490)提供把从GEM服务程序(0460)接收的事件内部发送给不同的客户程序转换程序，随后发送给不同的客户程序调度程序，最后发送给各个客户程序的事件通道的方法。按照这种方式，为各个客户程序转换接收的事件，并且根据需要传送接收的事件。

主要职责

1.接收发送给它的事件，并且根据事件类型把该事件发送给登记的监听程序。

2.根据事件类型，登记/不登记事件的监听程序。

3.为事件调度提供线程策略。

合作者

1.由gemServer(0460)用于调度从GEM服务程序接收的事件。

2.由传送模块(0470)用于登记客户程序格式化事件的监听程序。这些监听程序与客户程序专用事件通道相连。

3.由转换模块(0480)用于登记将被转换的事件的监听程序。

4.由转换模块(0480)用于把转换后的事件发送给客户程序专用调度程序。

详细的类程说明

为了实现例证应用程序中的各个模块，需要许多逻辑类程。本节更详细地描述各个模块的主要类程。本领域的技术人员可利用本节的信息来理解EEP是如何内部实现其功能的。

应用程序模块(0500)

图5(0500)图解说明了应用程序模块中主要的公开可见的类程的例证类程图。

EEPServer(0510)

该静态类程代表EEP应用程序本身。它具有主方法的执行过程。主方法调用其它静态方法，所述其它静态方法按照应用程序特有的顺序初始化其它软件包。其方法包括：

·main—运行该应用程序的静态子例程。调用其它静态子例程并且随后运行ORB(通过对ORB_Manager∷runORB()的调用)。

·readConfiguration—读取配置数据并建立包含配置数据的内部数据结构的静态子例程。

initializeInternals—按照逻辑顺序初始化应用程序中的其它软件包静态子例程。由于相关性的缘故，逻辑顺序为：util，common，dispatch，translate，transport，client modules和gemServer模块。

setup—提供建立应用程序以支持GEM服务程序和所有EEP事件客户程序(ALMAP、ECOM、Gem)的专用静态子例程。

EventProcessorImpl(0520)

·该类程是实现EEP的EventProcessor接口的单一类程。只有GEM服务程序调用该接口。其方法包括：

·register_EML/NE—向EEP登记新的EML应用程序，或者网络部件。这允许Gem服务程序通知EEP它准备好在EML/NE层的操作。另外，如果Gem服务程序需要来自于EEP的任意数据，该操作可返回该数据。

·unregister_NE-register_NE操作的逆操作。当GEM服务程序不再管理特定NE时，调用unregister_NE。

·push_alarm_event，push_gem_event，push_ECOM_event—这些操作允许GEM服务程序把NE接收的事件转发给EEP，以便进行后续处理。存在涉及不同类型事件的多个操作。

调度(0600)

图6(0600)图解说明调度模块中主要的公开可见的类程的例证类程图。这些类程定义不同的事件类型，在EEP应用程序内调度事件的方法和一旦事件被调度，处理事件的类程。这些类程主要被传送模块用于把事件给予内部事件传送结构，所述内部事件传送结构被构造成把事件传送给EEP客户程序。

EEPEvent(0610)

该类程(0610)封装该应用程序的不同形式的事件。利用事件的各个实例产生单个实例。该类程事件类型，并且提供获取事件和关于事件的细节的操作。其方法是：

·new—产生包装所提供的事件的实例。

·getEventType()—返回代表其事件的EEP_EventType实例。

·getEvent()—返回事件。

·getID()—返回事件的身份值。

·toString()—返回描述其事件及其事件类型的字符串。

EEPEventType(0620)

该类程表示EEP的已知的不同事件类型。对于从GEM服务程序发送给EEP的每种唯一的事件类型以及对于发送给EEP客户程序的每种唯一的事件类型，存在一例这种类程。借助关于该类程的公共、静态方法可访问这些实例。提供内部获取事件数据的其它方法。

IEventDispatcher(0630)

该接口用于EEP内事件的调度(安排顺序、计时和目的地)。在EEP中，该接口的执行过程被用于“直接通信(direct traffic)”，根据需要把从GEM服务程序接收的事件发送给不同的目的地。该接口利用事件监听程序表示事件的目的地。监听程序向IEventDispatcher登记，以便接收事件。IEventDispatcher的数目，哪些事件被发送给IEventDispatcher以及哪些事件监听程序被登记确定任意事件的传送路径。

该接口定义预订和不预订事件监听程序的方法。另外还向供给者提供把事件调度给监听程序的方法。基本方法是：

·dispatch()—恰当地把事件调度给所有登记的事件监听程序(订户)。

·subscribe()—使监听程序预订要求IEventDispatcher调度的事件。监听程序可提供它希望接收的一系列事件类型。

·unsubscribe()—从所有事件类型的订户名单中除去该监听程序。

图6(0600)中IEventDispatcher的具体实现被表示为SimpleEventDispatcher(0660)。

IEventListener(0640)

这是定义处理事件的方法的接口。每当IEventDispatcher接收一项事件，并且该事件的类型和监听程序请求的类型相符时，IEventDispatcher调用该方法。基本方法是：

·handleEvent()—处理其类型和监听程序预订的类型相符的事件。

IDeMuxEventListener(0650)

这是扩展IEventListener的更复杂的监听程序。为每种特定的事件类型提供了一种处理方法。和这种监听程序一起可同时采用更复杂的内部事件传送方案。例证的应用程序使用这种监听程序把特定的事件类型传送给特定类型的客户程序。

ECOM客户程序(0700)

图7(0700)图解说明了ECOM客户程序模块中主要的公开可见的类程的例证类程图。ECOM客户程序模块是例证应用程序中几个客户程序包之一。该应用程序为可从EEP接收事件的各个客户程序提供客户程序专用模块。每个客户程序模块封装客户程序记录器如何接收事件的细节。为此目的提供了客户程序专用接口并由内部类程管理。

EventAdminImpl(0710)

该类程(0710)提供用于获取EventSupplier实例的特定ECOM客户程序接口的执行过程，这是ECOM客户程序记录器怎样接收事件。new操作被用于在AdminFactory的控制下产生该类程的实例。register操作由ECOM客户程序用于登记事件。

AdminFactory(0720)

AdminFactory类程(0720)是用于管理ECOM客户程序专用类程的内部类程。例证的应用程序使用该类程建立并配置客户程序专用接口。就ECOM客户程序来说，该类程提供被EEP内部程序调用的操作，从而导致产生和破坏ECOM接口。列举的操作对应于关于EventProcessorImpl(0520)描述的那些操作。register_EML/NE操作导致产生EventAdminImpl的实例，unregister_NE导致破坏EventAdminImpl实例。

未显示的是被app模块调用的初始化该特定事件客户程序模块的init操作。对于ECOM客户程序来说，init行为是产生内部支持对象，图中未表示这些内部支持对象。

对于产生的各个ECOM专用接口，AdminFactory还与传送模块相互作用。这种相互作用导致产生客户程序所需的客户程序专用事件传送结构。

EventSupplierImpl(0730)

该类程(0730)用于实现ECOM客户程序专用接口，所述专用接口用于控制事件的流程。每次ECOM客户程序调用针对EventAdminImpl类程的登记操作时，产生这种类程的实例。该接口为客户程序提供使事件用户和供给者相连的操作以及控制相对于其的事件流程的操作。关键方法是：

·connect_structured_push_consumer()-连接客户程序供给事件用户和该客户程序的事件流程。该步骤完成从GEM服务程序经过EEP到最终的客户程序事件用户的事件流动的路径。

·suspend/resume()—这些操作允许客户程序事件用户停止和启动来自EEP的事件的流程。

·disconnect()—该操作允许客户程序事件用户告知EEP它不再关心事件。EEP释放用于该特定客户程序事件用户的任意内部资源，并且不再向其发送事件。

GEM客户程序(0800)

图8(0800)图解说明GEM客户程序模块中主要的公共可见的类程的例证类程图。该类程具有用于GEM专用客户程序接口的实现类程。存在使这些实现类程和传送模块中的事件传送结构相连的管理类程。

EventService(0810)

该类程(0810)是EventNotifierImpl的实例的内部管理类程。该类程由例证应用程序用于初始化GEM客户程序专用模块，产生并发布EventNotifierImpl的实例，并保存为各个GEM客户程序产生的事件供给者的名单。另外，该类程联系传送模块，从而触发产生该客户程序的内部事件传送结构。其主要操作是：

·getInstance()—返回该类程的唯一实例。

·init()—利用应用程序配置信息初始化gemClient模块。该操作产生EventNotifierImpl的实例，激活EventNotifierImpl，并且发布GEM客户程序预期的特定位置中的接口。其副作用是初始化特定GEM事件客户程序类型的传送模块中的事件传送结构。

·creatSupplier()—这是每次EventNotifierImpl触发它自己的creatSupplier操作时被调用的内部操作。产生并初始化GemSupplierWraper的一个实例。这导致产生GemPushSupplierImpl的一个实例，并且最后被返回给调用GEM客户程序。

EventNotifierImpl(0820)

该类程(0820)提供用于登记事件的GEM客户程序专用接口的执行过程。GEM客户程序调用obtain_gem_push_supplier操作产生GemPushSupplierImpl的实例。后一实例被GEM客户程序用于启动和停止事件的流程。图中列举的其它操作用于例证应用程序的内部用途。

GemSupplierWrapper(0830)

该类程(0830)管理GemPushSupplierImpl的各个实例。每次GEM客户程序希望登记事件时，EventService产生该类程的实例。该类程的各个实例产生GemPushSupplierImpl的实例，并且使之与传送模块提供的内部事件传送结构相连。图中列举的操作用于例证应用程序的内部用途。

GemPushSupplierImpl(0840)

该类程(0840)用于实现GEM客户程序专用接口，该接口用于控制事件的流程。该客户程序专用接口为客户程序提供连接事件用户和供给者的subscribe操作。从而，客户程序完成从GEM服务程序通过EEP到达客户程序的事件用户的事件流程的路径。提供unsubscribe操作，以便断开该路径，并且终止到客户程序的事件用户的事件流程。

Translate(0900)

图9(0900)图解说明转换模块中主要的公共可见的类程的例证类程图。IEventTranslator(0910)是具有两种方法的接口。第一种方法，translate()复制参数EEE_Event，将其转换成适当的格式并返回EEP_Event。可进行其它工作，例如调度转换后的事件。updateEventTypes()是供未来功能所用的方法。

实现IEventTranslator的具体类程包括：

·NullEventTranslator(0920)—该类程不对事件进行任何处理。它可用于测试目的。

·ECOM_EventTranslator(0930)—该类程把接收的事件转换成ECOM格式并且调度该事件。

·GemEventTranslator(0940)—该类程和ECOM_EventTranslator进行相同的处理，不过把接收的事件转换成GEM格式。

Transport(1000)

图10(1000)图解说明传送模块中主要的公共可见的类程的例证类程图。

EventTransport(1010)

这是一个单一类程(1010)，该单一类程(1010)是该模块的主要入口点。它由app模块初始化。一旦被初始化，它根据传送策略(如下所述)例示事件传送的恰当的具体类程。所述策略由配置参数设置。通过关于EventTransport类程的方法获得其它类程。

·init()—由具有应用程序特性的app模块调用。EventTransport将使用该应用程序特性确定它将向客户程序提供ISupplierFactory的哪些具体子类程。它将联系通知服务(0360)获得用于产生事件通道的接口。

·getClientSupplierFactory()—返回实现对于特定客户程序来说恰当的ISupplierFactory的具体类程的单一实例。对于每种客户程序，存在ISupplierFactory的具体实现。恰当的客户程序模块使用ISupplierFactory产生与客户程序专用内部事件传送结构相连的供给者。

·shutdown()—当通知应用程序关闭时被app模块调用。这允许传送模块执行清除和持续操作。

ISupplier(1020)

该接口(1020)表示事件的典型供给者。提供暂停、恢复和断开供给者的操作。还提供确定供给者是被连接还是被暂停的询问操作。

ISupplierFactory(1030)

该接口(1030)表示ISuppliers的制造者(factory)。提供允许破坏ISupplier的操作。不存在用于产生ISuppliers的任何操作，因为这些操作预期为客户程序类型专用操作，并且由实现该接口的具体类程提供，例如参见IGemSupplierFactory。

IECOMSupplierFactory(1040)

该接口(1040)扩展ISupplierFactory，并且用于特定的ECOM事件客户程序。该接口由ecomClient模块用于产生IECOM_Suppliers的实例。实现该接口的具体类程具有使用ECOM客户程序专用事件传送结构的性能。

·creatSupplier()—在无任何设置的情况下产生并且随后返回IECOM Supplier。当ECOM客户程序登记事件(参见下文)时，ecomClient模块调用该操作。该操作的副作用是在特定ECOM客户程序的事件通道上产生供给者代理。

·register()—产生IECOM_Supplier，并且将其设置成只传送所需事件类型，并且通过所提供的筛选程序的事件。返回新的供给者。该操作同样由ecomClient模块使用，并且具有上述相同的副作用。

IECOMSupplier(1050)

该接口(1050)扩展ISupplier，并且用于专用ECOM事件客户程序。该接口由ECOM客户程序用于连接它们的外部事件用户和EEP，并且控制到达这些用户的事件流程。实现该接口的具体类程具有构建客户程序专用事件传送结构并且传送事件的性能。其方法是：

·connect()—使提供的客户程序事件用户和该供给者相连。一旦完成该调用，供给者将通过客户程序专用事件传送结构把事件发送给用户。

IGemSupplierFactory(1060)

用于产生IGemSupplier对象的接口(1060)。除了用于GEM专用客户程序类型之外，其用途、方法和IECOM_SupplierFactory相同。但是，该接口的具体实现专用于GEM客户程序。

IGemSupplier(1070)

用于特定GEM事件客户程序的连接它们的外部事件用户，并且接收和控制相对于用户的事件的接口(1070)。其功能和IECOM_Supplier的功能相似，不过是支持不同客户程序的不同接口。

例证应用程序性能

本节利用包括流程图的各个附图说明例证应用程序如何实现其功能。

概述(1100)

图11(1100)图解说明整个EEP应用程序的例证逻辑流程。该例证应用程序由计算机专用装置启动；本领域的技术人员熟悉实现此目的的多种方式。随后该例证应用程序读取其配置文件并初始化其内部模块(1101)。所述应用程序等待GEM服务程序对其进行登记(1102)。一旦完成登记，则EEP构建并激活客户程序专用事件传送机构(1103)。如果借助外部停机操作被激活(1104)，则该应用程序将退出。在激活客户程序专用事件传送机构(1103)之后，EEP可处理并接收来自GEM服务程序的事件(1105)，以及处理事件客户程序登记请求(1106)。在后续附图中更详细地说明各个节点。

读取和初始化(1200)

图12(1200)描述读取例证应用程序的配置文件并且初始化该例证应用程序的逻辑流程。按照特定的顺序(1202、1203、1204、1205和1206)初始化图4(0410)的不同结构模块。

公用模块(1201)

公用模块的初始化(1201)导致所有其它模块使用的所有公用对象的产生及可用性。作为该模块的初始化的一部分，例证的应用程序通过读取配置文件和命令行选项产生其内部配置数据。调度模块(1202)

调度模块初始化(1202)由EEPServer∷setupDispatch操作完成。为GEM服务程序接收的事件产生一个IEventDispatcher。它被称为MainAppDispatcher(0401)。同样为EEP支持的各个特定事件客户程序类型(0404)产生单一的IEventDispatcher。这样，为GEM、ECOM和ALMAP事件客户程序类型产生三种IEventDispatcher。相对于它所支持的具体客户程序类型命名各个IEventDispatcher，即：ECOM_EventDispatcher，GemEventDispatcher，AlampEventDispatcher。相对于具体的事件客户程序，根据需要配置各个IEventDispatcher。

转换模块(1203、1300)

转换模块由EEPServer∷setupTranslate操作初始化(1203)。图13中更详细地表示了该过程(1300)。为每种具体的事件客户程序产生一个IEventTranslator(1301)。就例证应用程序来说，为具体的ECOM、GEM和ALMAP客户程序产生ECOM_EventTranslator、GemEventTranslator和NullEventTranslator。为各个IEventTranslator产生一个IEventListener(1302)。每个IEventTranslator通过IEventListener与MainAppDispatcher(0401)相连(1303)。这样，GEM服务程序接收的任意事件被发送给各个转换程序。每个IEventTranslator从公用模块中的对象中查找其对应的客户程序专用IEventDispatcher(0404)，并与其相连(1304)。这允许输出将被发送给客户程序专用调度程序的转换程序。

传送模块(1204)

传送模块初始化由EventTransport∷init操作完成(1204)。在(1001)的说明中给出了该方法的行为。

客户程序模块(1205)

为每种特定的事件客户程序初始化客户程序软件包(1205)。各个客户程序模块的管理类程具有被调用的init操作。在各个客户程序专用模块(0810、0720)的中说明的该操作的行为。

主应用程序接口(1206)

由EEPServer∷setupGemServer操作初始化GEM服务程序的接口(1206)。该操作产生EventProcessorImpl对象的实例，并且在当GEM服务程序启动时，可被GEM服务程序找到的位置中发布该实例。

主应用程序记录器(1102)

GEM服务程序在EEP于初始化步骤(1206)中发布位置中找到其相对于EEP的公共接口，EventProcessor。根据需要，它调用EventProcessorImpl∷register EML和register NE操作。由于ECOM客户程序的特定需要，这些操作触发ECOM接口(0710、0730)的产生。这又导致(1040)和(1050)的实例的产生，所述(1040)和(1050)为ECOM事件客户程序建立完整的事件传送机构。

激活客户程序传送(1400)

图14(1400)描述为各个客户程序激活事件传送机构的步骤。虽然事件传送细节因各种事件客户程序而不同，但是总的过程是大致相同的。

根据在(1101)中确定的配置数据，选择特定客户程序的事件传送的具体策略(1401)。所述策略是事件通道、事件筛选程序和按照所需方式有效地把事件传送给目标客户程序的其它对象的配置。

查找通知服务(0360)的EventChannelFactory(1402)。该制造者(Factory)用于产生事件通道。利用本领域的技术人员了解的典型CORBA机制查找该制造者。

借助该制造者，产生一个或多个事件通道(1403)。根据选择的策略和供给的配置数据，配置新产生的事件通道(1404)。

产生通知服务事件供给者(1405)，它将把事件从EEP提供给事件通道。该事件供给者利用在CORBA标准服务文献中描述的程序与事件通道相连。

新产生的通道事件供给者(0406)与特定的客户程序调度程序相连(1406)。这是在调度模块的初始化(1202)内产生的IEventDispatcher的客户程序专用实例(0404)。通道事件供给者通过IEventListener的实例(0405)与调度程序相连。这在EEP内建立起从来自于GEM服务程序的事件的接收到将用于特定事件客户程序的事件通道的事件流程。

最后，产生恰当的ISupplierFactory(1030)的实例(1407)。具体的类型是正被激活的事件客户程序的函数。制造者与新产生的事件通道相关。当客户程序登记时，EEP将使用该制造者产生事件通道上的供给者代理，并且把这些返回给客户程序。借助该最终步骤，特定事件客户程序的内部事件传送结构被完全激活，并且可支持客户程序的登记和事件的传送。

处理客户程序登记(1500)

图15(1500)图解说明当事件客户程序登记时EEP可执行的步骤。虽然使用的实际接口和子例程专用于正在登记的事件客户程序，但是内部过程大体相同。

术语“登记”实际包括两种情况。第一种情况是事件客户程序正在试图连接以便接收事件。第二种情况是已连接的事件客户程序正在试图断开，从而不再接收事件。

连接客户程序

对于正在连接的事件客户程序(1501)，第一步(1502)是产生用于该特定客户程序的事件通道上的新的供给者代理。利用标准通知服务方法完成这项操作。一旦产生供给者代理，则根据特定事件客户程序的需要和EEP自身的配置，配置该供给者代理(1503)。

随后在恰当的客户程序模块(0700、0800等)内产生事件客户程序专用事件供给者。根据事件客户程序，所述事件供给者可以是GemPushSupplierImpl(0840)、EventSupplierImpl(0730)或其它的实例。在(1407)激活内产生的ISupplierFactory(1030)的客户程序专用实例用于该用途。事件供给者是客户程序希望用于关于事件进行连接，并且控制事件流程的事件客户程序专用接口。

随后使新产生的事件供给者与供给者代理(1505)相连。这种连接使客户程序的事件供给者能够向将进行实际工作的实际供给者代理发送连接并控制事件流程的请求。事件供给者用作特定事件供给者的接口要求和可从通知服务获得的接口要求之间的适配器的作用。

新的事件供给者被添加到该类客户程序的当前供给者名单中(1506)。保存该名单，从而如果需要稍后可断开事件客户程序。最后，事件供给者被返回给客户程序(1507)。这允许客户程序使用事件供给者进行实际连接，从而接收事件并且控制到达客户程序的事件流程。每个客户程序使用客户程序专用过程和一组子例程来完成此项工作，图中未表示。

断开客户程序

正在断开的客户程序(1501)已关于事件被连接。从事件供给者名单中找到特定事件客户程序的事件供给者(1508)。破坏与客户程序专用事件通道相连的事件供给者的供给者代理(1509)。这永久地阻止事件到达专用事件客户程序，同时便于未来连接客户程序。从名单中除去该事件供给者(1510)，以指出特定的事件客户程序已断开。

接收并处理事件(1600)

图16(1600)描述当EEP从GEM服务程序接收事件并且需要把该事件传送给登记的事件客户程序时，EEP执行的步骤。GEM服务程序把事件发送给EventProcessorImpl(0520)，以启动该过程。图4(0400)表示作这些步骤的结果，在EEP内的对象之间的事件的流动。

检查事件

检查事件以确定该事件是否是专用于事件客户程序类型的事件(1601)。GEM服务程序可选择特别用于诸如ECOM之类的单独事件客户程序类型的事件。如果事件是客户程序专用事件，则该事件被发送给恰当的客户程序调度程序(0404)。否则该事件被发送给MainAppDispatcher(0401)。

转换

发送给MainAppDispatcher(0401)的事件随后被发送给各个ClientTranslatorListener(0402)。这些监听程序确保事件被发送给各个客户程序转换程序(0403)(1602)。每个转换程序确定事件是否关心其特定的事件客户程序类型(1603)。各个事件客户程序具有关于它所希望接收事件的不同标准。如果客户程序不关心事件(1603)，则丢弃该事件(1605)，不进行进一步处理。如果客户程序关心事件，则将其从GEM服务程序产生的形式转换成由特定事件客户程序所需的形式(1604)。随后把转换后的事件发送给对应的客户程序调度程序(0404)。

调度

利用IEventDispatcher∷dispatch操作，把要发送给特定事件客户类型的所有事件发送给恰当的客户程序调度程序。客户程序调度程序将事件发送给各个登记的IEventListener(1607)，所述登记的IEventListener是ClientChannelListener(0405)。该监听程序利用ChannelSupplier(0406)把接收的事件发送给客户程序专用事件通道(1608)。一旦事件通道收到该事件，则事件通道将其发送给已登记的(1106)所有事件客户程序用户(1609)。按照这种方式，从GEM服务程序发出的事件被转换，并且按照客户程序所需的方式被发送给恰当的客户程序。

调度程序的对象模型(0400)

图4(0400)图解说明EEP内部提供的用于把接收的事件传送给它们的最终目的地的对象之间的关系。后缀为“Dispatcher”的各个对象是IEventDispatcher的实例。类似地，后缀为“Listener”的各个对象是IEventListener的实例。客户程序转换程序对象是IEventTranslator的实例。

MainAppDispatcher(0401)具有若干监听程序，一个监听程序用于一个ClientTranslator(0402)。这些监听程序从MainAppDispatcher(0401)接收事件，并将事件转发给它们相应的转换程序。转换程序执行其子例程(1602、1604、1605)，并且把事件发送给ClientDispatcher(0404)，每种客户程序存在一个ClientDispatcher(0404)。ClientDispatcher(0404)按照在(1600)中描述的方式处理事件。

本发明的优选系统环境

虽然本发明最好应用于通过利用基于图形用户界面(GUI)的操作控制台本地或者远程管理和维护电信网络的情况，不过本发明也可应用于按照统一的方式管理计算机网络中的任意类型的硬件和/或软件组件，同时使软件设计复杂性和维护费用降至最小的情况。

本发明的功能单元广泛适用于涉及源于各种硬件和软件生产商的多种远程设备的情况。由于本发明打破了网络部件管理和用于执行管理功能的工具之间的编译-时间连接，从而允许广泛应用于通过增加硬件和软件，网络必定动态增长，但是在这种升级过程中网络必须保持可工作状态的情形。

结论

公开一种包含允许重新格式化接收的事件，并且把这些事件传送给先前登记的事件用户的独立软件组件的外部事件处理器(EEP)系统和方法。本发明教导了在单独的软件进程内运行的应付事件处理和传送的独立软件组件的产生。该独立软件进程具有由网络管理应用软件用于以事件的最基本形式向外部事件处理器(EEP)发送事件的远程接口。随后，EEP执行把提供的事件转换成外部事件用户所需的恰当形式和类型必需的所有其它子例程。另外，EEP向事件提供外部用户所需的服务质量(QoS)性能。

虽然在附图中举例说明，并在前述说明中具体描述了本发明的一个优选实施例，但是要明白本发明并不局限于公开的实施例，相反在不脱离由下述权利要求陈述和限定的本发明的精神的情况下，可做出各种调整、修改和替换。

Claims

1、一种外部事件处理器(EEP)系统，包括：

(a)一个或多个事件供给者；

(b)一个或多个事件用户；

(c)一个或多个通知通道装置；和

(d)一个外部事件处理器软件子系统装置；

其中：

所述外部事件处理器软件子系统装置在所述事件供给者和所述事件用户之间转换事件；

所述外部事件处理器软件子系统装置具有通过主应用软件从所述事件供给者接收事件的外部接口；

所述外部事件处理器软件子系统装置可通过所述外部接口从一个或多个网络部件接收事件。

2、按照权利要求1所述的外部事件处理器(EEP)系统，还包括：

(a)MainAppDispatcher装置；

(b)ClientTranslatorListener装置；

(c)ClientListener装置；

(d)ClientDispatcher装置；

(e)ClientChannelListener装置；和

(f)ChannelSupplier装置；

其特征在于，

通过所述装置(a)-(f)顺序处理所述事件。

3、按照权利要求1所述的外部事件处理器(EEP)系统，还包括：

(a)EEP∷app装置；

(b)EEP∷util装置；

(c)EEP∷common装置；

(d)EEP∷client装置；

(e)EEP∷server装置；

(f)EEP∷transport装置；和

(g)EEP∷dispatch装置。

4、按照权利要求1所述的外部事件处理器(EEP)系统，其特征在于，所述事件供给者和事件用户驻留在计算机网络内的独立节点上。

5、按照权利要求1所述的外部事件处理器(EEP)系统，其特征在于，在应用程序编程接口(API)内实现所述系统的一个或多个组件。

6、按照权利要求1所述的外部事件处理器(EEP)系统，其特征在于，通过因特网进行所述传送。

7、按照权利要求1所述的外部事件处理器(EEP)系统，其特征在于，在个人计算机(PC)上实现所述系统的一个或多个组件。

8、按照权利要求7所述的外部事件处理器(EEP)系统，其特征在于，所述个人计算机使用HP-UX^TM操作运行环境。

9、按照权利要求7所述的外部事件处理器(EEP)系统，其特征在于，所述个人计算机使用LINUX^TM操作运行环境。

10、按照权利要求7所述的外部事件处理器(EEP)系统，其特征在于，所述个人计算机使用SOLARIS^TM操作运行环境。

11、按照权利要求7所述的外部事件处理器(EEP)系统，其特征在于，所述个人计算机使用UNIX^TM操作运行环境。

12、按照权利要求7所述的外部事件处理器(EEP)系统，其特征在于，所述个人计算机使用Microsof^Windows^TM操作运行环境。

13、一种外部事件处理(EEP)方法，包括：

(1)从网络部件或者其它事件供给者接收事件；

(2)通过外部接口把所述事件传送给外部事件处理(EEP)软件组件；

(3)把所述事件转换成适于由事件用户解释的形式；

(4)把所述转换后的事件传送给事件用户，

其中

通过一个或多个事件通道把所述事件从所述事件供给者传送给所述事件用户。

14、按照权利要求13所述的外部事件处理(EEP)方法，还包括通过下述装置顺序处理所述事件：

(a)MainAppDispatcher装置；

(b)ClientTranslatorListener装置；

(c)ClientListener装置；

(d)ClientDispatcher装置；

(e)ClientChannelListener装置；和

(f)ChannelSupplier装置。

15、按照权利要求13所述的外部事件处理(EEP)方法，还包括借助下述装置处理所述事件：

(a)EEP∷app装置；

(b)EEP∷util装置；

(c)EEP∷common装置；

(d)EEP∷client装置；

(e)EEP∷server装置；

(f)EEP∷transport装置；和

(g)EEP∷dispatch装置。

16、按照权利要求13所述的外部事件处理(EEP)方法，其特征在于，所述事件供给者和事件用户驻留在计算机网络内的独立节点上。

17、按照权利要求13所述的外部事件处理(EEP)方法，其特征在于，在应用程序编程接口(API)内实现所述方法的一个或多个步骤。

18、按照权利要求13所述的外部事件处理(EEP)方法，其特征在于，通过因特网进行所述传送。

19、按照权利要求13所述的外部事件处理(EEP)方法，其特征在于，在个人计算机(PC)上实现所述方法的一个或多个步骤。

20、按照权利要求19所述的外部事件处理(EEP)方法，其特征在于，所述个人计算机使用HP-UX^TM操作运行环境。

21、按照权利要求19所述的外部事件处理(EEP)方法，其特征在于，所述个人计算机使用LINUX^TM操作运行环境。

22、按照权利要求19所述的外部事件处理(EEP)方法，其特征在于，所述个人计算机使用SOLARIS^TM操作运行环境。

23、按照权利要求19所述的外部事件处理(EEP)方法，其特征在于，所述个人计算机使用UNIX^TM操作运行环境。

24、按照权利要求19所述的外部事件处理(EEP)方法，其特征在于，所述个人计算机使用Microsof^Windows^TM操作运行环境。

25、一种利用

(1)一个或多个事件供给者；

(2)一个或多个事件用户；

(3)一个通信网络；

(4)编码事件信令数据；和

(5)外部事件处理(EEP)装置；

构成的外部事件处理(EEP)编码传播信号数据流，

其中

所述外部事件处理装置借助外部接口，通过所述通信网络把所述事件供给者和事件用户之间的事件信息转换给主应用软件，所述主应用软件通过所述外部接口把事件数据推送给所述EEP；

借助事件信息的编码，通过所述通信通道进行从所述事件供给者到所述事件用户的所述转换。

26、一种具有提供外部事件处理(EEP)功能的计算机可读程序代码装置的计算机可用介质，所述计算机可读程序装置包括：

(1)从网络部件或者其它事件供给者接收事件的计算机程序代码装置；

(2)通过外部接口，把所述事件传送给外部事件处理(EEP)软件组件的计算机程序代码装置；

(3)把所述事件转换成适于事件用户解释的形式的计算机程序代码装置；

(4)把所述转换后的事件传送给事件用户的计算机程序代码装置，

其中

通过一个或多个事件通道，把所述事件从所述事件供给者传送给所述事件用户。

27、按照权利要求26所述的计算机可用介质，其特征在于，通过下述装置顺序处理所述事件：

(a)MainAppDispatcher计算机程序代码装置；

(b)ClientTranslatorListener计算机程序代码装置；

(c)ClientListener计算机程序代码装置；

(d)ClientDispatcher计算机程序代码装置；

(e)ClientChannelListener计算机程序代码装置；和

(f)ChannelSupplier计算机程序代码装置。

28、按照权利要求26所述的计算机可用介质，还包括借助下述装置处理所述事件：

(a)EEP∷app计算机程序代码装置；

(b)EEP∷util计算机程序代码装置；

(c)EEP∷common计算机程序代码装置；

(d)EEP∷client计算机程序代码装置；

(e)EEP∷server计算机程序代码装置；

(f)EEP∷transport计算机程序代码装置；

(g)EEP∷dispatch计算机程序代码装置。

29、按照权利要求26所述的计算机可用介质，其特征在于，所述事件供给者和事件用户驻留在计算机网络内的独立节点上。

30、按照权利要求26所述的计算机可用介质，其特征在于，在应用程序编程接口(API)内实现所述功能的一个或多个步骤。

31、按照权利要求26所述的计算机可用介质，其特征在于，通过因特网进行所述传送。

32、按照权利要求26所述的计算机可用介质，其特征在于，所述介质与个人计算机(PC)兼容。

33、按照权利要求32所述的计算机可用介质，其特征在于，所述个人计算机使用HP-UX^TM操作运行环境。

34、按照权利要求32所述的计算机可用介质，其特征在于，所述个人计算机使用LINUX^TM操作运行环境。

35、按照权利要求32所述的计算机可用介质，其特征在于，所述个人计算机使用SOLARIS^TM操作运行环境。

36、按照权利要求32所述的计算机可用介质，其特征在于，所述个人计算机使用UNIX^TM操作运行环境。

37、按照权利要求32所述的计算机可用介质，其特征在于，所述个人计算机使用Microsof^Windows^TM操作运行环境。