CN1954587A

CN1954587A - 分布式计算机

Info

Publication number: CN1954587A
Application number: CNA2005800155247A
Authority: CN
Inventors: 内克塔里奥斯·耶奥加拉斯
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2004-03-30
Filing date: 2005-03-23
Publication date: 2007-04-25
Also published as: US20080134210A1; CA2561643A1; EP1730684A1; GB0407150D0; WO2005096193A1

Abstract

本发明公开了一种分布式计算机。该分布式计算机根据由用户可修改的事件驱动的组件进程组成的分布式应用程序而进行操作。已知的这种类型的分布式计算机在单台计算机上执行进程的修改，导致作为整体的分布式计算机的操作缺乏鲁棒性。通过为运行分布式应用程序的组件(621)的各台计算机提供组件修改便利性来消除该问题。根据存储在数据库(623)中的策略，来修改组件(621)对事件消息的接收进行响应的操作。为了简化用户在编写这种策略时的工作，还提供了组件细节登记(627)，其给出了由组件(621)提供的过程或方法的名称和参数。

Description

分布式计算机

技术领域

本发明涉及分布式计算机以及对分布式计算机进行操作的方法。

背景技术

几十年来，将软件程序写成多个独立的模块(被称为结构化编程的行为)的好处已为公众所知。这种方法后来被进一步采用，并且引入了通过组合针对以前的程序而编写的模块来创建大程序的思想。通过这种方式使用以前准备的软件模块带来了软件生产的速度的提高，因此降低了应用程序的成本。

通常将以前编写的模块组织为被称作库的集合。在为单机计算机开发程序时，公知地，被称为链接器的程序将由编译器根据程序员所编写的程序而产生的对象与从该库中取出的对象进行链接。这些对象中的每一个都包括机器码和符号定义表。各个对象中的符号定义表包含所谓的输出符号和输入符号，输出符号是指该对象中存在的函数或模块，输入符号是由该对象调用或引用但在该对象内未定义的函数或变量。链接器程序将输入符号和输出符号关联起来，以产生表示整个程序的机器码。

现代操作系统环境(例如，Windows)使得能够在加载或运行程序时进行涉及这种关联(换句话说，链接)的动态链接。这种链接的动态特性意味着，在每一次后续加载包括一库例程(在Windows中为.dll文件)的应用时，都会反映出对于该库例程的更新。

以上涉及单机计算机-Xerox PARC的研究人员在20世纪80年代早期实现的分布式计算的早期示例。他们开发了用于调用其他计算机上的模块的软件，使得这些模块对于程序员看上去好像它们和调用它们的程序位于同一台计算机上。在论文“Implementing Remote Procedure Calls”，Birrell A.，and Nelson，B.，ACM Transactions on Computer Systems，Vol.2，No.1，February 1984，Page 39-59中描述了这种软件。该论文提出，通过添加通信程序以及客户端和服务器“占位程序(stub)”模块来实现远程过程调用(Remote Procedure Call)，该客户端和服务器“占位程序”模块一起使所选择的过程在远程计算机上执行，并将该过程的结果返回给应用程序。在编写分布式应用时，程序员准备用户和服务器程序以及一个或更多个接口模块(过程名称和过程所采用的参数的类型及其产生的结果的类型)。向用户提供根据程序员准备的接口模块而自动生成“占位程序”模块的软件。

这里，将进行以下操作的软件称为中间件：

a)提供“占位程序”，以使得在不同机器上执行的软件模块能够进行配合操作；

b)使得可以知道存在于不同计算机上的模块及其能力；以及

c)在程序之间提供数据的通信和编组(marshalling)。

远程过程调用的使用使得可以远程提供库函数并由多台计算机使用。于是，该库可以由独立的可执行文件(提供所需链接功能的中间件)构成。

为了组合面向对象的编程和分布式计算的优点，来自SunMicrosystems的Java编程语言为程序员提供了远程方法调用的便利性。这是中间件的一个示例。由于其仅在以Java编程语言编写的对象之间有效，所以无需程序员学习特殊的接口定义语言，而是使用Java自己的接口定义。

为了扩展软件再利用和分布式计算的优点，由对象管理组织在20世纪90年代早期发布的通用对象请求代理体系结构(CORBA)对中间件进行了标准化，使得程序员能够对由以不同语言编写的并在不同计算机上运行的模块/程序构成的应用进行编程。在兼容CORBA的系统中，提供了使得能够使用由远程对象提供的过程(方法)的、被称为“对象请求代理”(ORB)的代码。为了使得能够在调用对象与被调用对象之间进行“绑定”，每一个ORB都必须提供“接口库(repository)”。该“接口库”包含对于由对象提供的方法的描述，这些描述是以接口定义语言(IDL)编写的，该接口定义语言类似于C++程序中的说明语句。于是，可以根据IDL规范自动地创建适当的占位程序模块。CORBA使用通用数据表达(CommonData Representation)来传递在方法调用和响应中使用的参数值。

最近，网络服务技术受到关注。网络服务提供了另一种形式的中间件，但是提供了对CORBA的改进，因为采用可扩展标记语言(XML)在计算机之间传递参数值。这提供了一种对所传送的参数进行定义的灵活手段。

问题在于，使用以上形式以外的任意中间件构成的分布式应用难以开发和修改。为了改变其操作，必须改变软件模块(对象)，然后重新编译并重新启动该软件模块。根据所使用的中间件以及该改变的复杂度，可能还必须生成针对改变后的软件模块的接口规范，并对该接口规范进行编译。这对于通常要求连续运行的现代电子商务应用来说尤其是不期望的。

为了消除该问题，Sharma Chakravarthy等人提出了采用以前在某些数据库管理软件中使用的思想。他们在论文“ECA Rule Processing inDistributed and Heterogeneous Environments”，in the proceedings of theInternational Symposium on Distributed Objects and Applications，1999中建议，可以通过根据存储在数据库中的事件-条件-动作规则进行操作，而在运行时改变分布式应用的操作。也就是说，向其中所述的分布式计算机赋予了“主动”能力。所提出的系统是一种分布式计算机，其中的每一台计算机上都安装有CORBA中间件。该分布式计算机中的一台计算机被指定为复合事件检测和规则执行(CEDaR)服务器计算机，该计算机：

(i)从形成在独立计算机上运行的分布式应用的一部分的软件组件接收事件(即，表示该事件的特性的结构化数据)，并对其进行响应，

(ii)找到存储在CEDaR服务器中的表示用于对这种事件进行响应的条件-动作对的一个或更多个“规则”，

(iii)调用另一方法/过程来对该条件进行评估(可能将该事件作为参数传送)，以及

(iv)如果该条件为真，则调用另一方法/过程来执行该动作(可能将该事件再次作为参数传送)。

该动作通常是执行构成该分布式计算机的其他计算机之一上的软件组件(或者该软件组件中的至少一个过程或方法)。在一另选设计中，该动作可以是执行包含在CEDaR服务器上的本地软件库(这种库可以用新软件来更新，而无需停止分布式应用程序的执行)中的软件。

为了使分布式应用可适用，在运行时对可更新ECA规则进行解释。当然，不需要在运行时解释经更新的ECA规则，除非正在执行的程序为了反映数据库中已产生的变化而在运行时调整其执行。为了满足这种要求，Chakravarthy提出的分布式计算机中的CEDaR服务器和其他计算机使用来自Iona Technologies的OrbixWeb(使得能够在作为分布式应用程序的一部分执行的组件之间进行通信的兼容CORBA的对象请求代理)。OrbixWeb提供了一种动态调用接口，该动态调用接口使得程序员能够以如下方式来编写执行程序，即，在运行时自动选择存储在数据库中的ECA规则的行为域中所命名的方法。此外，通过使用作为由Sun Microsystems提供的Java编程语言包的一部分提供的Java反射应用程序接口(API)，提供了在运行应用的同时使用所定义的事件的能力。

依靠单台服务器来评估规则、调用条件评估和规则执行过程意味着，Chakravarthy的分布式计算机高度依赖于该单台服务器的性能，并且发送和接收随着所运行的分布式应用的大小而增长的通信量。

发明内容

根据本发明的第一方面，提供了一种分布式计算机，该分布式计算机包括至少两个互连的计算机，所述计算机中的每一个都存储有：

i)组件进程代码，可执行用于提供构成分布式软件应用的一部分的进程；

ii)事件消息传送(messaging)代码，可执行用于从所述计算机中的另一个接收一个或更多个事件消息；

iii)事件反应规则存储代码，可执行用于响应于所述事件消息的接收，将包括对所述组件进程中的功能的一个或更多个调用的一个或更多个事件反应规则存储在可更新存储器中；

iv)事件反应规则解释代码，可执行用于对所述计算机进行操作，以根据所述事件反应规则对事件消息的接收进行响应；

v)事件反应规则修改代码，可执行用于使得用户能够对存储在所述可更新存储器中的所述事件反应规则进行修改。

通过在分布式计算机内的两个或更多个计算机(这些计算机中的每一个都执行构成在所述计算机上运行的分布式应用程序的一部分的一个或更多个组件)中的每一个处存储一个或更多个事件反应规则(其指定了要响应于事件消息的接收而进行的对所述组件中的功能的调用)，并且使得用户能够对事件反应规则进行更新，提供了鲁棒且依然可易于更新操作的分布式计算机。

优选地，根据对于所述计算机中的每一个可访问的事件方案数据对所述事件消息进行结构化。这使得计算机能够检查所述事件是否为正确的数据类型。

进一步优选地，所述事件消息包括事件数据和标记数据的组合。这简化了在接收计算机处对事件数据的组成部分进行解包所需的处理。

在一优选实施例中，所述事件消息被作为编码文本进行发送。这使得可以使用简单的基于文本的消息传送协议，例如超文本传输协议。具体地，可以根据可扩展标记语言方案来形成事件消息。

优选地，所述进程修改代码可执行用来通过指定要调用的方法或过程和伴随所述方法或过程调用的参数，来配置所述进程。在某些实施例中，所述指定方法或过程在所述计算机中的另一个上运行。这使得可以再利用安装在其他计算机上的代码，同时保持通过将事件反应规则和可修改组件存储在同一计算机上而提供的相对简便性。

根据本发明的第二方面，提供了一种操作分布式计算机的方法，所述分布式计算机包括多个互连的计算机，所述方法包括对所述计算机中的每一个进行操作，以执行以下操作：

i)执行构成在所述分布式计算机上运行的分布式程序的一部分的一个或更多个组件进程；

ii)存储一个或更多个事件反应规则；

iii)向用户提供可以更新所述事件反应规则的接口；以及

iv)根据所述事件反应规则，响应于事件的接收对所述组件进程的操作进行配置。

附图说明

下面将参照附图，仅通过示例的方式来说明本发明的具体实施例，附图中：

图1例示了本发明第一实施例中使用的硬件；

图2例示了根据本发明第一实施例的事件数据类型的整体结构；

图3例示了根据本发明第一实施例的策略数据类型的整体结构；

图4例示了第一实施例中使用的组件描述数据的结构；以及

图5例示了第一实施例中用于提供基于可修改组件的计算机的软件的体系结构。

具体实施方式

图1示出了经由互联网14和网络服务器15与客户的家庭计算机12相连的电信网络运营商的分布式计费系统。该计费系统包括通过内联网10互连的四个重要的子系统2、4、6、8。这四个子系统为呼叫数据记录子系统2、可修改事件驱动账单计算子系统4、可修改事件驱动账单产生子系统6和计费系统配置站8。从账单产生子系统6进行从计费系统到互联网的连接。如在真实商业环境中的通常情况一样，这四个子系统位于不同的地点。

呼叫数据记录系统2基于从电信网络内的交换机(exchange)10、12接收的呼叫数据。交换机中的每一个都被编程为经由局域网16将其通过公共交换电信网15(PSTN)采集的呼叫数据发送给呼叫数据记录计算机18。呼叫数据记录计算机18将呼叫数据保存在大容量存储装置20中。从CD-ROM 17将计费事件产生软件加载到计算机18中。呼叫数据可以具有与下表1所示的相似的格式：

主叫号码	020 7356 1111
主叫号码	020 7356 1111	被叫号码	01473 642222
开始时间	10:23:52 18/10/03	被叫号码	01473 642222
开始时间	10:23:52 18/10/03	结束时间	10:46:31 18/10/03

表1

如本领域的技术人员将理解的，该呼叫数据通常不包括上表中的内容。相反，数值/时间数据将根据预定格式进行格式化，例如，其可以表现为四条美国信息交换标准编码(ASCII)文本，或者时间元素可以表现为预定的时间格式。

与商业计算机的许多软件相同，账单事件产生软件在计算机18上连续运行。所运行的软件对计算机18进行操作，以监测针对各个主叫号码的计费日期(应该记住，在许多情况下，主叫号码等同于客户)，并在每次达到客户账单的到期日时向账单计算子系统4发送“账单到期(BillDue)”事件消息。该“事件”消息是根据下面将参照图2描述的方案进行了格式化的可扩展标记语言XML文件。本领域的技术人员可以毫不费力地提供生成并传送诸如“账单到期”事件消息的消息的程序。

经由内联网10和局域网24将“账单到期”事件消息从呼叫数据记录计算机18发送给账单计算计算机26。账单计算计算机26具有从CD-ROM 27安装到其上的软件。如以下将参照图5更加详细描述的，CD-ROM 27提供了策略数据库管理软件、策略处理软件、以及基于组件的账单计算软件，该账单计算软件的操作可通过更新存储在本地策略数据库28中的策略来进行修改。应该理解，预期可以经由互联网(可能以支付费用为代价)将诸如此类的可修改组件提供给开发人员。因此，计算机26可以经由局域网24连接至全局互联网14并且计费计算机26的管理员可以从互联网14上的其他地方的组件服务器下载类似的组件，而不是从CD-ROM 27获得基于组件的账单计算软件。基于组件的账单计算软件通过产生“账单已计算”事件消息来对从呼叫数据记录系统2接收到“账单到期”事件消息进行响应，然后将其发送给账单产生子系统6。

账单产生子系统6包括与内联网10相连并进一步与账单产生计算机30和账单打印机32相连的局域网34。在用于账单产生计算机30的CD-ROM 36上提供有与在CD-ROM 27上为账单计算计算机26提供的相似的策略数据库管理软件以及策略处理软件。CD-ROM 36上还提供了基于组件的账单产生软件，可以通过更新存储在本地策略数据库38中的策略来对其操作进行修改。

图2表示最高级事件规范由六个元素组成。每一个事件(event)类型都具有唯一的事件id(event-id)201，其为用于触发适当策略的全局唯一的字符串(如下将说明)。描述(description)元素202是旨在由人读取而不是自动处理的文本串。可选的产生时间(generationTime)元素203识别特定事件何时发生，而可选的有效期(timeToLive)元素205指定了该事件相关多久。使用这种信息使得可以在未及时处理的情况下丢弃特定的事件，从而限制不必要的管理通信量。源(source)元素207识别产生该事件的计算机。源元素207有两个子元素，角色(role)子元素209和实体(entity)子元素211。实体子元素211识别产生该事件的软件组件。提供在已对事件进行了处理时可以向其发送确认或结果的地址是有用的。角色子元素209表示对于获得对来自不同源的事件公共的行为有用的分类。这在响应于来自相同源的事件而触发不同的处理时也是有用的。数据(data)元素213具有开放内容模型，并且使得可以包括任意合适的XML。这是可以包括与该事件有关的任意特定信息的情况。

本领域的技术人员应该理解，图2中所示的事件方案使得可以将账单数据(甚至其他类型的数据)插入到数据元素213中。因此，根据图2所示的方案所构建的并在本实施例中用于从呼叫数据记录子系统2到账单计算子系统4的事件消息的XML文件可以表示如下：

<event>

<event-id>Bill Due</event-id>

<description>This event is generated by Call data recording System on the date on

which a customer is to be billed arriving. It includes the call data pertaining to that

customer during the billing period</description>

</role>

<entity>Call Data Recording System</entity>

</source>

<data>

<name>

Fred Bloggs

</name>

123 Acacia Avenue

</address>

</customer data>

</call data>

</data>

</event>

可以看到，表1中所示的呼叫数据在以上事件文件中传送。

账单计算计算机26根据存储在大容量存储装置28的数据库中的策略文件对从呼叫数据记录计算机18接收的事件文件进行响应。

在通过所提供的呼叫数据并根据存储在策略库28中的一个或更多个策略计算出用户的账单后，账单计算计算机26向账单产生计算机30发送“账单已计算”事件。这种事件的示例如下：

<event>

<event-id>Bill Due</event-id>

<description>This event is generated by Call data recording System on the date on which

a customer is to be billed arriving.It includes the call data pertaining to that customer

during the billing period</description>

</role>

<entity>Bill Calculation Sub-System</entity>

</source>

<data>

<name>

Fred Bloggs

</name>

123 Acacia Avenue

</address>

</customer data>

</bill data>

</data>

</event>

应该理解，本实施例使用事件来发布系统状态的信息。例如，当用户通过其计算机12表示他们希望以电子形式接收其账单时，该信息使得网络服务器15产生对于存储在大容量存储装置28和38中的客户细节数据库的数据库更新事件。

返回到账单计算计算机26的操作，因为账单计算是根据存储在策略数据库28中的策略文件来进行的，所以管理员易于使用管理计算机8通过更新存储在大容量存储装置28中的数据库的内容，来更新计费计算机26的操作。以这种方式对账单计算计算机26的操作进行修改的能力显然对于希望引入新的计费策略(例如，如果客户选择电子地而不是以纸件形式接收他们的账单，则减少客户的账单费用)的电信网络运营商有用。下面将参照图5来说明策略数据库28的更新有效地对账单计算计算机26的操作进行更新的方式。

图3中示出了策略(policy)(例如，存储在账单计算策略数据库28或账单产生策略数据库38中的策略)的整体结构。最高级策略规范由五个元素构成。以下详细说明策略id(policy-id)301、描述(description)303、主题(subject)组件305、事件id(event-id)307和规则(rule)309。

策略id 301是旨在全局唯一的字符串。希望对其自动地进行处理并使得可以明确地参照一个策略。描述元素303是旨在主要针对该策略的人类读者的可选文本串。其可用于传送不旨在自动处理的任意附加信息。

主题元素305识别在策略被修改的情况下其行为被修改的组件。

假设这里给出的策略规范与基于事件的方法一起工作，以发布系统状态的信息。在这种情况下，策略指定了当发生特定事件时策略处理软件应该表现出的行为。事件id 307表示哪个事件触发了该策略。当检测到事件时，必须启动相关的策略。假定策略是由单个事件触发的。事件id 307是全局唯一的字符串，与在触发该策略的事件文件中找到的事件id(图2，201)相对应。

每一个策略都包括一个或更多个规则元素309。这些规则元素指定了应该由触发了该策略的事件的出现而导致的行为。每个规则元素309都包含以下域：

首先是可选的<rule-id>312，其包括针对特定规则的标识符。

接下来是可选的条件(condition)元素313。<condition>元素313由子元素<BooleanExpression>、<true>和<false>构成。BooleanExpression元素提供了将由从CD-ROM 27或CD-ROM 36获得的策略处理软件进行评估的条件谓词。根据包括在策略处理软件内的策略处理器类的语义，该字符串可以包括大量内容。首先，BooleanExpression可以包含其语法可由策略处理器识别的字符串。策略处理器将读入该字符串并原样对其进行评估。例如，该字符串可以是直接以Java语法表示的谓词(例如，a＞3&&b＝＝4)，或者另选地是以策略处理器专用的方式(例如，agreaterThan 3并且b equals 4)表示的谓词。使用Java语法来表示条件更容易，因为当符号＞、＝＝、3和4是Java符号时，可以由Java本身对它们直接进行语法分析并理解，并且仅符号a和b需要在策略处理器中有意义，即，策略处理器需要知道a和b表示什么。使用策略处理器专用的方式来表达谓词使策略处理器软件的操作变得复杂，因为在策略处理器上不仅要分析和理解a和b而且要分析和理解所有其他符号(即，GreaterThan、AND和equals)。其次，该字符串可以包含对于条件的标识符。在这种情况下，策略处理器将使用标识符来调用返回真或假的条件评估方法/程序(本地或远程的，取决于该条件是否检查本地或某些远程环境中的状态)。其后是<true>和<false>元素，它们都针对的是条件估计分别为true和false时要执行的规则组。

<action>元素321(每个规则元素309中存在至少一个)描述了要采取的动作(如果相关规则中没有条件元素，则将不可避免地采取该动作)。该动作元素包含表示组件或者要调用的组件中的方法或函数的<target>323。当条件评估为真时，可能存在一个以上要调用的<action>。另外，动作元素中还包含上下文(context)子元素326，上下文子元素326用于识别要对目标组件调用的方法或过程，并且可以包括要传送给该组件的一个或更多个参数。应该注意，目标组件323无需和主题组件305相同，通常，主题组件305的行为将通过使其进行方法调用而变得灵活，该方法调用取决于动作(action)域321的目标323和上下文326子域。

接下来是<rules>元素327，其引入了要按照以上条件-动作结构的顺序来执行的一组附加规则。这些规则可以通过规则标识符，即<rule-id>(其指向要使用的特定规则)来表示，或者通过使用嵌入的元素<rule>作为附加条件-动作结构来显式地描述这些规则。在使用rule-id的情况下，假设描述所参照的规则的显式XML文件独立地存在并且可以通过策略处理器从规则数据库(例如Xset)中检索到。Java代码的等效部分如下：

if(...){//rule 1

...//some actions

}

if(...){//rule 2

...//some actions

}

以下给出了可以在图1的计费系统中使用并且具体地存储在计费计算机26中的示例策略：

<policy-id>ElectronicBillingRebate</policy-id>

This policy reduces a customer’s bill by ￡5 if they elect to receive their bill in

electronic form.

</description>

<subject>Bill Calculation Sub-System</subject>

<event-id>BillDue</event-id>

<rule>

<rule-id>1234</rule-id>

IsBilledEloctronically＝＝true

</BooleanExpression>

<false>

<target>Bill Calculation Sub-System</target>

<name>calculateBill()</name>

<parameter>CustomerID</parameter>

</method>

</context>

</action>

</false>

</condition>

<target>Bill Calculation Sub-System</target>

<name>rebateBill()</name>

<parameter>CustomerID</parameter>

</method>

</context>

</action>

<target>Bill Calculation Sub-System</target>

<name>calculateBill()</name>

<parameter>CustomerID</parameter>

</method>

</context>

</action>

</rule>

</policy>

可以看出，以上策略是在客户帐单到期事件(如同以上所示的事件)到达时根据客户是否选择了电子地接收帐单而被触发的，在向帐单产生计算机30发送“帐单已计算”事件以触发帐单的产生之前，对客户账单应用折扣。账单产生计算机30对该事件的反应也取决于策略文件，如下所示：

<policy-id>ElectronicBillingImplementation</policy-id>

This policy selects between an electronic bill and a customer bill dependent on

the customer’s preference.

</description>

<subject>Bill Production Sub-System</subject>

<event-id>BillCalculated</event-id>

<rule>

<rule-id>1235</rule-id>

IsBilledElectronically＝＝true

</BooleanExpression>

<false>

<target>Bill Production Sub-System</target>

<name>printBill()</name>

<parameter>CustomerID</parameter>

</method>

</context>

</action>

</false>

</condition>

<target>Bill Calculation Sub-System</target>

<name>generateElectronicBill()</name>

<parameter>CustomerID</parameter>

</method>

</context>

</action>

</rule>

</policy>

可以看到以上策略如何简单地使请求了电子账单的客户以电子格式接收到他们的账单，并使没有请求电子账单的客户以纸件形式接收到他们的账单。

图4中示出了用于表示在该实施例中使用的软件组件的数据结构。

其最高级包括与该数据结构所表示的组件(component)的特性相关的四个元素。第一元素是用来唯一识别该组件的组件名称(name)401。第二元素403用于列出以下事件：

a)由组件(使用(consumed)元素409)处理的事件；以及

b)由组件(生成(produced)元素411)产生的事件。

还包括了用于由该组件处理或产生的事件中的每一个的标识符(413，417)。

下一个元素是列出了响应于该组件所使用的事件的接收来影响该组件的行为的策略(policies)的元素405。每个策略都具有用于识别它的策略id(policy-id)417。

下一个元素407被称为能力(capabilities)，其包含与传统组件模型(例如CORBA组件模型或者在网络服务中使用的组件模型)中看到的相类似的参数。

每个能力都具有一个或更多个操作(operation)元素419，这些操作元素与传统组件模型相同，为操作提供名称(name)421，并为任意输入参数(input)423提供名称(name)425和类型(type)427，并且类似地，为任意输出参数(output)429提供名称(name)431和类型(type)433。

该信息对于希望提供新策略来对账单计算子系统和账单产生子系统的操作进行配置的管理员是有用的。通过上述内容可以理解，引入以上两个策略将如何一方面对账单产生子系统6进行修改以根据客户的偏好产生纸件或电子账单，另一方面对账单计算子系统4的操作进行修改一这种修改(如下文所述，其不需要对在账单计算计算机和账单产生计算机上运行的软件进行重新编译或重新启动)需要编写目标323和上下文326子元素的人知晓目标组件所提供的方法的名称，以及该方法所需要的和所返回的参数的名称和类型。该方法的名称设置在名称域439中，其输入和输出参数以及类型由子元素441至451提供。

因此，表示在账单计算计算机26上运行的账单计算组件的XML文件可以如下所示：

<name>Bill Calculation Sub-System</name>

</produced>

<consumed>BillDue</consumed>

</events>

<policy-id>ElectronicBillingRebate<policy-id>

</policies>

<name>calculateBill()</name>

<input>

<name>CustomerID</name>

<type>Integer</type>

<type>Integer</type>

</input>

</operation>

<name>rebateBill()</name>

<input>

<name>CustomerID</name>

<type>Integer</type>

<type>Integer</type>

<name>Rebate Amount</name>

<type>Integer</type>

</input>

</operation>

<name>isBilledElectronically()</name>

<input>

<name>CustomerID</name>

<type>Integer</type>

</input>

<name>isBilledElectronically</name>

<type>Boolean</type>

</output>

</operation>

</capabilities>

</component>

下面参照图5更详细地说明CD-ROM 27和36上所包括的软件。如上所述，该软件包括策略数据库管理软件、策略处理软件，以及其操作可以通过对存储在本地策略数据库28中的策略进行更新而修改的基于组件的账单计算软件。电信运营商的计算机15、18、26、30中的每一个上都安装有使得能够在它们之间发送事件消息的软件。在图5中，将进行该操作所需的软件表示为通知服务器软件601、603。

策略处理软件是利用Java编程语言编写的，并由以下Java类构成：接收器类605、事件使用者类607、策略管理器类608、策略处理器类609、调用器类613、组件登记类615、组件细节管理器616、事件产生器类617和发送器类619。所有这些类构成了以下被称为“容器”的应用程序。账单计算计算机26的存储器中还存储有XML数据库软件611(该具体实施例中使用了XSET XML数据库)以及也由Java编程语言编写的可修改账单计算软件组件621。

接收器605

这是以主要方法启动该容器的主要类。当接收器605运行时，其首先对容器进行初始化。然后，将对接收器对象的参照发布给远程方法调用(RMI)登记，使得计算机18和34上的通知服务器程序601可以联系该容器。接收器605使用由这些计算机发送给容器的事件，并通过产生账单生成事件来进行响应。在使用事件时，创建事务上下文对象并联系事件使用者607。当生成事件时，发送器619使用事务上下文对象的getEventSourceEntity()方法(参见下文)来检索该事件要发送到的目的地。

事务上下文

该类记录了与每一个新事务相关的信息(一使用事件，事务就开始)。在事务上下文对象中捕获的与事务相关的信息是事件源的标识，因此使用该对象来保持要将该事件已经被处理(或者事件处理由于某种原因而失败)的确认发送到的地址的记录。应该记住，该信息包含在该事件的源元素207的实体子元素(图2：211)中。事务上下文对象为该数据提供了getter方法[getEventSourceEntity()]和setter方法[setEventSourceEntity()]。事务上下文对象在接收器605处创建，由事件使用者607更新并由策略处理器609参考。它是在接收器605、事件使用者607和策略处理器609之间交换的对象以便向所有接收器605、事件使用者607和策略处理器609提供有用的与事务相关的信息的公共观点。

事件处理器607

该类负责处理所有被使用的事件。其包含handleEvent()方法和getassociatedPolicy()方法。通过接收器605将事件XML文件和事务上下文对象传送给handleEvent()方法。handleEvent()方法首先对事件XML文件进行语法分析，以产生文件对象模型(DOM)树，然后从事件DOM的剩余部分中解包出数据部分，其中数据表示要处理的内容，即，本示例中的呼叫数据。应该记住，该数据包含在事件的数据元素213中。getassociatedPolicy()方法根据在该事件的事件id元素201中找到的事件id以及包含在数据库611中的策略的事件id元素307，从策略库623(参见下文)中检索相关策略。如果所使用的事件涉及存储策略，则getassociatedPolicy()方法检索出管理策略，如以下更详细说明的，该管理策略指定了应该如何处理包含要保存在策略库623中的新策略的事件。在传送至策略处理器609之前对所有检索出的策略进行语法分析。

策略处理器609

该类对检索出的策略进行处理。其包含以下方法：handlePolicy()、validatePolicy()、analysePolicy()和executeAction()。事件使用者607将检索出的策略传送给handlePolicy()方法。策略处理器使用validatePolicy()方法来检查策略的有效性。

接下来，analysePolicy()方法解释该策略。该解释涉及对该策略的任意条件内的任意BooleanExperssion(图3：315)进行评估。找到对应的动作来恢复与要使用传统计费软件组件的哪些方法有关的细节。这些细节(方法的名称以及要传送给该方法的参数)是包含在该策略的上下文元素(图3，326)中的值。由executeAction()使用所恢复的细节和在该策略的上下文元素326中找到的数据，executeAction()随后与调用器613进行通信。在所选择的策略为管理策略的情况下，analysePolicy()会将由在该事件的数据元素213中找到的数据表示的内容保存在策略库609中。

XSET XML数据库611

这是存储以下内容的内部数据库：

i)保存一个或更多个策略的策略库623；以及

ii)组件细节登记627。

本实施例使用XSet(一种存储器内的基于XML的数据库)。存储器内数据库是一种特殊类型的数据库，其中所有数据都存储在存储器中而不是硬盘上的文件中，以便提供对数据的更快访问。可以在以下文献中找到XSet的细节：XSet XML Search Engine and XBench XML QueryBenchmark，Technical Report UCB/CSD-00-1112，Ben Yanbin Zhao，Computer Science Division，University of California，Berkeley，2000。策略库623提供了对其内容的访问方法。具体地，storeInXSet()以DOM树的形式存储XML文件，或者从文件读入XML文件，queryXSet()通过执行查询表达式来检索XML文件，而deleteFromXSet()删除存储在数据库611中的XML文件。

调用器613

该类负责在其所用过的策略在策略库623中被更新时改变正在执行的组件的行为。策略处理器609将方法的名称以及在该策略中找到的输入参数传送给调用器613的invokeAction()方法，以调用执行环境。通过使用Java反射API，设置了调用器，以在执行的同时，使用在策略中描述的参数，来调用与在该策略中识别的组件有关的方法。因此，响应于事件的接收而进行的方法调用取决于当前用于指定该组件应该如何对事件进行响应的策略。选择在运行时运行的方法意味着，可以在运行时调整可以被视为分布式计费应用的程序的行为，而无需对在系统中运行的任何程序进行重新编译或重新启动。

组件细节登记627

这是XSET数据库的一部分，该部分存储与该XSET数据库存储在同一计算机中的组件的组件细节(图4)。提供了访问方法，即，用于存储的put()、用于检索的get()、用于删除的remove()，并且包括用于检查是否包括组件参照的Component()。该登记的每个部分都实现以下的Java接口，该接口仅是标记，即，其仅将各个部分标记为组件。

public interface Component{}

与组件登记615进行联系的唯一模块是调用器613。

当启动容器实例时，容器最初使用通知服务器程序601(已被加载到通知服务器计算机(未示出)上)进行登记，以宣告其关注于侦听对于该容器专用的某种类型的事件。每次呼叫数据记录计算机18向容器发送账单到期事件(该事件包括呼叫数据)时，该事件都首先到达通知服务器程序601，该程序已被加载到通知服务器计算机上，并且已向这些计算机(15，18，26，30)进行了登记。在接收到事件时，通知服务器程序601将该事件打包到通知消息602中(即，将事件封装在通知消息602中)并将该消息传送到容器已经向其进行了登记的通知服务器程序603。通知服务器程序603从该消息中解包出事件部分(即，提取事件部分)，并将其发送至接收器605。

在对计费系统进行初始化时，接收器603使用两个事件。这些事件由操作管理计算机8的管理员来发送。事件在其数据元素213中包含两个管理策略。这两个策略的事件id元素307都不包含任何值，表示该策略在一接收到就启动。第一个策略确定在使用StorePolicy事件时，应该将包含在该StorePolicy事件的数据元素213中的数据存储在策略库623中。第二个策略表示当使用QueryPolicy事件时，应该对策略库623的内容运行包含在该QueryPolicy事件的数据元素213中的查询。这两个管理策略都存储在策略库623中。

接收器605使用通过通知服务器601/603从计算机8、15、18、26、30之一到达该接收器605的事件。使用Xerces Java^TM分析器(来自ApacheXML项目)对该事件进行分析(703)，并且创建事务上下文对象并联系事件使用者607。将事件和事务上下文对象都传送给事件使用者607，事件使用者607最初从该事件中解包出数据。该数据表示客户的呼叫数据或者表示新策略，并且包含在事件的数据元素213中。另外，事件使用者607使用事件id(由事件的源元素207的值表示的信息)来更新事务上下文对象。接下来，联系策略库623，以检索与所接收的事件相关的任意策略。该检索的重要信息是包含在该事件的事件id元素201中的事件id。

下面将说明使用在参考策略时运行的组件方法对呼叫数据事件进行的处理。

事件使用者607联系策略库623。搜索相关策略并获得策略，将该策略连同包含在该事件的数据元素213中的数据和事务上下文对象一起传送给策略处理器609。下一步骤是对该策略进行分析，即解释。分析的目的是提取描述应该使用的组件方法的信息。所请求的特定信息是要调用的方法的名称以及要传送给该方法的参数。该信息包含在该策略的上下文元素326中。随后，将名称方法传送给调用器模块，并请求调用提供所提供的参数的指定方法。当运行该方法时，策略处理器609请求调用器613调用在所选择的策略中指定的方法，还传送参数(来自数据元素213)。调用器613调用所请求的动作。来自该动作的返回结果始终传播回到事件产生器617，事件产生器617分别产生账单已计算事件，以发送给账单产生计算机30。

下面将说明对管理员产生的事件(例如，StorePolicy和QueryPolicy事件)进行的处理。

开始时，该事件由接收器605使用。然后对其进行分析，并创建事务上下文对象。将经分析的事件和事务上下文对象都发送给事件使用者607，事件使用者607从该事件中解包出包含在数据元素213中的数据，并使用来自该事件的源元素207的事件源URI来更新事务上下文对象。接下来，在策略库623中检查管理策略。如上所述，这些策略是由管理员创建的，并且最初是由容器读入的。这些策略在处理管理员产生的事件的内容时，确定策略库623是数据要存储到的目标。将检索出的管理策略返回给事件使用者607，然后连同数据一起传送给策略处理器609。其中，对策略进行验证和分析，此后，策略处理器609调用在该策略中指定的动作，以存储内容或者从策略库623中检索内容。策略库623随后返回查询结果或者该操作的成功/失败指示。将结果传播回产生Acknowledgement事件或QueryResults事件的接收器605。所产生的事件最终通过通知服务器601/603返回到初始事件源。

通过以上说明可以看出第一实施例是如何提供如在现有技术中看到的分布式应用的运行时修改的。然而，还可以看出如何根据与其操作经修改的组件存储在同一机器上的策略在运行时修改组件中的可修改方法调用(对于在运行分布式应用程序时所涉及的多个计算机的每一个都适用)。这使得不需要复杂的软件来处理对存储在另一计算机上的方法的动态调用，因此减少了提供运行时可修改分布式计算机的成本，而不需要以分布式计算机的操作的可修改性为代价。

尽管在上述实施例中使用了基于存储器内的数据库(XSet)，但是在其他实施例中，任意持久性的数据存储(例如可以从IBM、Oracle和Sybase得到的那些)都是适用的。此外，该数据存储可以远离计费计算机26，例如经由LAN 24连接。

在以上实施例中，各个子系统都是由一个电信公司拥有的。然而，在其他实施例中，这些子系统可以由不同的公司拥有，标准数据编码方案(XML)的使用使得可以相对直接地集成由不同公司拥有的子系统。

Claims

1、一种分布式计算机，该分布式计算机包括至少两台互连的计算机，所述计算机中的每一台计算机都存储有：

ii)事件消息传送代码，可执行用于从所述计算机中的另一台计算机接收一个或更多个事件消息；

iii)事件反应规则存储代码，可执行用于响应于所述事件消息的接收，将包括对所述组件进程中的过程的一个或更多个调用的一个或更多个事件反应规则存储在可更新存储器中；

iv)事件反应解释代码，可执行用于根据所述事件反应规则对所述计算机进行操作；

v)事件反应规则修改代码，可执行用于使得用户能够在所述组件进程正在运行时对存储在所述可更新存储器中的所述事件反应规则进行修改，由此在所述分布式软件应用正在运行时对其操作进行修改。

2、根据权利要求1所述的分布式计算机，其中，所述计算机中的每一台计算机都存储要与所述组件进程代码相关联的组件过程接口信息。

3、根据权利要求1所述的分布式计算机，其中，所述分布式计算机包括计算反射代码，该计算反射代码可执行用于将所述事件反应规则中的方法或过程调用数据转换为对应的方法或过程调用来执行。

4、根据权利要求1所述的分布式计算机，其中，根据对于所述计算机中的每一台计算机可访问的事件方案数据对所述事件消息进行了结构化。

5、根据权利要求4所述的分布式计算机，其中，所述事件消息包括事件数据和标记数据的组合。

6、根据权利要求5所述的分布式计算机，其中，所述事件消息被作为编码文本进行发送。

7、根据权利要求1所述的分布式计算机，其中，所述进程修改代码可执行以通过指定要调用的方法或过程以及伴随所述方法或过程调用的参数来对所述进程进行配置。

8、根据权利要求7所述的分布式计算机，其中，所述指定的方法或过程在所述计算机中的另一台计算机上运行。

9、根据权利要求1所述的分布式计算机，其中，所述互连的计算机包括管理计算机，该管理计算机上安装有可执行用于使得管理员能够更新所述事件反应规则的图形用户界面代码。

10、根据权利要求1所述的分布式计算机，其中，所述事件反应规则响应于事件消息的接收，指定要执行的方法或过程。

11、根据权利要求10所述的分布式计算机，其中，所述事件反应规则还指定要测试的条件，所述动作的执行以所述条件得到满足为条件。

12、根据权利要求1所述的分布式计算机，其中，所述计算机中的每一台计算机还存储数据库管理代码，该数据库管理代码可执行用于为存储在所述计算机上的所述规则提供数据库存储。

13、根据权利要求1所述的分布式计算机，其中，所述计算机中的每一台计算机还存储组件进程细节，该组件进程细节包括由所述组件进程提供的一个或更多个过程或方法的名称。

14、根据权利要求13所述的分布式计算机，其中，所述组件进程细节还包括方法调用要包括的一个或更多个输入参数的名称以及这些输入参数的类型指示。

15、根据权利要求13或14所述的分布式计算机，该分布式计算机还包括图形用户界面代码，该图形用户界面代码可执行用于使得用户能够查看所述组件进程细节。

16、一种操作分布式计算机的方法，所述分布式计算机包括多台互连的计算机，所述方法包括对所述计算机中的每一台进行操作，以执行以下操作：

ii)存储一个或更多个事件反应规则，所述事件反应规则包括对所述组件进程内的一个或更多个过程的引用；

iii)向用户提供可以更新所述事件反应规则的接口；以及

iv)响应于在所述计算机处对事件消息的接收，解释对应的事件反应规则，并由此执行在所述事件反应规则中引用的所述一个或更多个过程。