CN1334530A - 通过共享数据库进行可用率监视的方法 - Google Patents

Abstract

本发明涉及指示并确定多个应用服务器的可用率的技术。所提出的方法对每个应用服务器都包括将限定可用率信号的重复周期的时间上限的通知周期插进可用率数据库的第一步骤,只要应用服务器是可用的,该信号就重复。第二步骤对每个可用率信号将其相应的时间标记作为可用率时间插进可用率数据库。当前时间和最近的可用率时间之差与上述通知周期相比表示应用服务器的可用率的测度值。

Description

通过共享数据库进行可用率监视的方法

技术领域

本发明涉及指示并确定对多个应用客户机提供应用服务的多个应用服务器的可用率的方法和装置。

背景技术

企业依赖于对它们日常工作进行支持的系统的可用率。如果系统一直正常运转并产生正确的结果，则将系统称为可用的。从狭义上说，系统的可用率是指该系统为可用的那一段时间的比率。MTBF表示这类系统出故障之前的平均时间，即在出故障之前系统可供使用的平均时间(这是系统的可靠度)。MTTR表示修复的平均时间即在出故障之后修复系统所花费的平均时间(这是系统因故障的停工期)。这样， $\mathrm{AVAIL}=\frac{\mathrm{MTBF}}{\mathrm{MTTR}+\mathrm{MTBF}}$ 是系统的可用率。在理论上说，系统的可用率是1。目前，如果一个系统的可用率约为99.999％，该系统就会宣称有高可用率(如果可用率约为99.99％，则被称为是容错的)。J.Gray和A.Reuter的《事务处理：概念和技术》San Mateo，CA Morgan Kaufmann 1993给出了有关这些方面的进一步详细内容。某种系统或应用的可用率具有至少两个方面：首先，从狭义上说，涉及某一系统是否是完全现役的以提供服务这样的问题；其次，从广义上说，涉及适时地提供上述服务以提供充分响应这样的问题。

提高可用率的一种基本方法是以“冗余”为基础：通过构建机器群集可提高硬件的可用率，通过在多个地址空间中运行同一软件可提高软件的可用率。

随着分布式系统的出现，业已发明了使用运行同一软件的不同机器上的两个或多个地址空间的技术来提高可用率(通常称为主动复制)。S.Mullender的《分布式系统》ACM出版社，1993年，说明了这些方面的其它细节。在使用运行同一种从共享输入队列中获得请求的软件的同一机器上的两个或多个地址空间时，可用热池技术来概括热备份技术。

C.R.Gehr等人的US专利第5828847号“用于最大服务器可用率和负载平衡的动态服务器转换”说明了一种与上述狭义可用率有关的动态服务器转换系统。这种动态服务器转换系统在各客户机中保存有一个静态且预定的列表(一个概要)，它可识别用于该客户机的主服务器和最佳通信方法以及相继的辅服务器层次结构和通信方法对。在客户机不请求由指定主服务器或指定通信方法来进行服务的情况下，系统会详细考察上述列表，以获得第一可用的备用服务器-通信方法对的标识。这种系统能使客户机将请求从未响应的服务器重新引向预定的备用服务器。通过这种方式，就服务可用率言，系统能提供反应性的服务器转换。

尽管能提高上述狭义的可用率，但是，上述方法具有多种缺点。Gehr教导的内容仅在完全不能与主服务器建立联系的情况下提供反应性的响应。不存在阻止客户机从不响应的服务器请求服务的前摄组件。由于是用统计方法来预先确定主服务器和备用服务器的列表，因此存在有这样的情形：完全不能找到服务器或者不会在业已测试了若干不响应的备用服务器之前找到服务器。在客户机和服务器永久地进入或离开网络以及对服务器的接入模式每时每刻都发生变化的高度动态的世界范围的操作网络环境中，Gehr的教导内容是不适当的。

与本发明相同的发明人的题为“集群应用服务器的提高了的可用率”的欧洲专利申请EP99109926.8也涉及到可用率问题。但是，其内容完全集中于应用客户机方面。为了确实使某一应用请求由可用的应用服务器来处理，建议将该应用请求在多点传送步骤中并行地发送给大量应用服务器，假定有至少一个可用的应用服务器会接收到应用请求。上述内容在如何指示某一应用服务器的可用率的技术方面完全没有说明。

已知还有同一发明人的题为“提高集群应用服务器的可用率和伸缩率”的另一个欧州专利申请EP9912914.7。在该申请中，已经把确定应用服务器的可用率的技术的存在假定为起点。其内容集中于应用客户机如何通过选定某一应用服务器去处理应用请求而进行工作负荷平衡的技术。

尽管迫切地需要所有这些进步和改进以便在提高应用的可用率以及例如进行7(天)*24(小时)的电子商务方面对企业进行支持，但由于世界范围内的计算机网络在任何位置处都最终会普遍存在，故人们可能会对访问某一应用服务器感兴趣。

发明内容

本发明基于上述目的而提供一种用于指示应用服务器的可用率以便接受应用请求的改进型方法和装置，并提供一种由应用客户机来判断应用服务器的可用率的改进的方法和装置。

本发明的另一个目的是通过提供一种这样的技术而提高可用率，所述技术能对网络内各个应用服务器的可用率的动态变化作高度响应。

本申请的独立权利要求可以实现本发明的目的。相应的附属权利要求说明了本发明的最佳结构和实施例。

所提出的方法对每个应用服务器来说都包括将一个用于限定可用率信号的重复周期的时间上限的通知周期插进到可用率数据库中的第一步骤，只要应用服务器是可用的，所述可用率信号就重复下去。

在第二个步骤中，对每个可用率信号来说，将其对应的时间标记作为可用率时间插进到可用率数据库。

当前时间和最近的可用率时间之差与上述通知周期相比可以表示应用服务器的可用率的测度值。

所提出的技术能提高向多个应用客户机提供服务的多个应用服务器的可用率和可伸缩率。本发明提供了一种前摄技术，因为，这种技术能阻止应用客户机生成从非响应服务器那里请求服务的错误请求路由。具有在进行中处理的动态技术能高度响应客户机和服务器永久地进入或离开网络的动态网络环境。因此，本发明可使服务器机器热插入应用集群，从而进一步增加环境的可伸缩性。可完全避免将应用客户机与应用服务器联系起来的复杂管理努力。

附图说明

图1是反映应用服务器、热池、应用集群和应用客户机的概念的图；

图2反映了所提出的本发明的可用率数据库，它由作为通信介质的各个应用服务器/相应的监视器来维护，以便指示其可用状态；

图3示出了本发明周期表的记录格式，该表包括各个通知周期；

图4以直观的方式示出了可用率数据库中用来存储各可用率信号的记录格式；

图5反映出了一流程图，它说明了本发明用于指示可用率的方法，所述流程图还包括根据工作负荷情况来调整通知周期的动态方面；

图6示出了将周期表和可用率信号表组合进单独的一个表内的实现形式的实例。

具体实施方式

可用硬件、软件、或硬件和软件的结合来实现本发明。任何类型的计算机系统(或其它适于执行本文所述方法的设备)都是适当的。硬件和软件的典型组合是带有计算机程序的通用计算机系统，所述程序在被装载和执行时可对计算机系统进行控制，从而使计算机可执行本文所述的方法。本发明还可嵌进计算机程序产品，所述产品包括所有的能实现本文所述方法的特征并且能在被装载进计算机系统时实现这些方法。

本文中的计算机程序装置或计算机程序是指一组指令的用任何语言、代码或标记的任何表达方式，所述指令可使得具有信息处理能力的系统直接或在下述两种情况之一或所有这两种情况之后执行特定的功能，所述的两种情况是：a)转换成另一种语言、代码或标记，b)以不同的材料形式再现。

如果本说明书涉及到一种应用，则该应用可以是不限于任何特定类型或实现形式的任何种类的计算机程序。术语应用客户机和应用服务器必须从逻辑的角度来加以理解，它们仅涉及某种类型的“实例”。这些术语不必区分出不同的地址空间甚至不同的计算机系统。

本发明假定在应用客户机与应用服务器之间有某种通信路径；这并不意味着本发明限于某种通信范例。

如果本说明书涉及“数据库”，则应从广义上来理解该术语，它不仅包括实际的数据库(象关系、层次数据库等)，而且包括简单的文件等。换句话说，术语数据库是指任何类型的持续存储装置。

企业依赖于对它们日常工作进行支持的系统的可用率。如果系统一直正常运转并产生正确的结果，则将系统称为可用的。从狭义上说，系统的可用率是指该系统为可用的那一段时间的比率。其次，从广义上说，可用率涉及是否以适时的方式提供应用服务从而提供充分的响应这样的问题。

在所述最佳实施例中，本发明涉及根据以下还要在图1中予以说明的概念的所谓“应用集群”的环境。

应用服务器(110、111或112)是可执行一组相关服务，例如包括访问某一共享的远程数据库(100)。热池(110、111、112)是一组地址空间，其每个空间都运行同样的应用服务器，并且，这些应用服务器中的每一个都接收来自输入队列(125)的请求，所述输入队列在热池成员之间是共享的。服务器机器(101、102或103)是指某种物理机器，它是应用服务器的热池的宿主。应用集群(120)是一组服务器，它们独立地出故障，并且，每个服务器都是同种应用服务器的热池的宿主。

应用(130)通过应用客户机请求来自应用服务器的服务。应用客户机(131)是可执行的，它与应用运行在同一机器上并且代表应用与服务器相通信。如果应用客户机与服务器之间的通信是以(异步)可靠消息交换为基础的，则认为应用服务器是基于消息的。在下文中，我们假定在应用客户机与应用服务器之间有基于消息的通信，当然，本发明并不局限于基于消息的通信的范例，相反可以使用其它范例。因此，应用客户机可通过将相应的消息发送进特定机器上的相关应用服务器的热池的输入队列而请求执行某一服务。

客户机可保护自身不受服务器故障的影响，从而能直接通过如以上已连同欧洲专利申请EP99109926.8说明的那样的多点传送其请求而提高整个环境的可用率。但是，这需要应用服务器的特殊实现形式或者限于等幂请求。此外，还会成倍地增加所发送的消息的数量。

如果消息的数量是个问题，则将请求发送给热池的各个客户机均必须检测出该热池业已出了故障(这很容易做到：通过发消息的中间件以否定的方式向客户机确认相应的PUT命令)。在客户机了解同一应用服务器(即应用集群中出故障的热池是其成员的服务器机器)的其它热池时，就将其请求发送给该集群中的不同服务器上的另一个热池。在这样做时，客户机可在热池本身之间进行接管。

所以，问题是检测仍可接收请求的服务器(所谓的可用率监视)。就这一目的而言，可用所谓的监视器去监视单个机器上的热池，以便检测出出故障的服务器。此外，监视器会自动地重新启动它所监视的热池的出了故障的应用服务器。连同上述欧洲专利申请EP99122914.7，业已说明了监视器监视的概念以便检测出应用集群中出了故障的服务器机器。这一概念是以进行监视并确定成组可用应用服务器的监视器之间的特定通信协议为基础的。

一般地说，通过一个分布式应用的各个部分之间的网络来发送消息，以便维护其各个组件的整个状态。通过将要进行监视的监视器组看作是这样的分布式应用(这样做的唯一目的是进行响应以查询它的各个分布式组件的有效性)，可以使用这种基于网络的消息传送方案。但是，基于网络的消息传送协议例如具有若干(严重程度不一样的)固有问题，例如

·发送消息会使得在某些情况下耐受能力不佳的网络有额外的负载；

·必须实现更复杂的算法，以避免单个故障点(与“集中式”监视相类似，在此，一个不同的监视器只是将其它的监视器作为参与者来进行观察)，这会导致需要有更多的改进努力，而且，这种实现方式会引发“对检查器进行检查”的问题，也就是说，必须要使用特定的编程技术以确保这些检查本身不会形成任何故障。

·必须能确保可到达性属性(例如，在“集中监视”中，中心监视器必须能对所有其它监视器起作用，或者，在“分布式监视”中，每个监视器必须能对所有其它监视器起作用)，这两种情况都难以在建立环境时适当地实现管理任务并难以在可能发生并必须加以处理的网络分隔的情况下(例如，由于连接丢失，网络分成不相连的各个子网)进行处理。

因此，本发明的目的是克服这些需要基于这种扩大的网络的消息传送协议的问题。但是在此同时，对于这些问题的预定解决方案应能提供一种前摄技术，这种技术能自动地确定进入(热插入)或离开所述集群的应用服务器。

图2反映出了本发明的中心思想。本发明的中心观点是，引入中心和共享数据库来显著地降低上述网络消息拥挤问题。建议将由所有要加以监视的监视器所共享的数据库用作通信介质，该介质用来交换应用服务器的有效性的状态。这种新的数据库称为寿命数据库或可用率数据库200。在本发明的最佳实施例中，集群202的相应应用服务器的各监视器201将一个“我活着！”203记录写进寿命数据库，该记录应被理解为相应应用服务器的可用率信号，以指示它们准备就绪去接受应用服务请求。引入监视器概念是一种附加的改进，当然，各应用服务器本身可以进行响应，以便将可用率信号插进可用率数据库。

作为一个示例性实施例，假定关系数据库系统是应用集群的寿命数据库的宿主。请注意，这一点并不是本发明的中心，也就是说，就这方面而言，可使用任何其它稳定存储方式(例如文件系统或企业级Java beans实体容器)。具体地说，可通过表示寿命数据库的适当的表来扩展一个拓扑数据库，该拓扑数据库可被应用集群用于其系统管理。

能够访问应用集群的寿命数据库的任何软件(例如对请求的应用服务感兴趣的应用客户机)均能确定可用的服务器以及那些业已出故障且当前不可用的服务器。

对某一应用服务器或其监视器而言，使相应的可用率信号只进入可用率数据库一次是不够的。如果在这一事件之后应用服务器崩溃，则可用率数据库会不与当前环境相同步。为了处理这一问题，本发明就这一目的建议寿命数据库必须还包含有与每个监视器同意将“我活着！”的记录写进该数据库内的周期有关的信息。所以，要把包括通知同期的另一个数据元素插进可用率数据库，只要相应的监视器(或应用服务器)是可用的，所述通知周期就限定了重复可用率信号的时间上限。

作为一个实例，图3示出了用于存储各个通知周期的周期表。建议该周期表包括监视器(代表应用集群)的标识或用于重复可用率信号和通知周期301的应用服务器300的标识。参与可用率监视的每个监视器/应用服务器均使这种记录输入到可用率数据库。对本领域的普通技术人员来说，如何通过SQL获得所述周期并且使得监视器写入来自上表的“我活着！”消息是很明显的。而且，该应用集群所包括的所有监视器都可以通过SQL从所述表中获得。

作为一个实例，图4说明了Alive_Signal(活着的信号)表，该表用于表示监视器的“我活着！”记录，也就是说，对接收自监视器的各个可用率信号来说，要使这种记录进入可用率数据库。与所述周期表相类似，建议Alive_Signal表包括用于发送可用率信号的相应监视器/应用服务器的标识400。而且，Alive_Timestamp(活着的时间标记)字段401存储该时间标记，从而存储最近可用率信号的可用率时间。

包含在上述两个表(即周期表和Alive_Signal表)中的信息精确地描述了应用服务器的可用率。

概括地说，就每个应用服务器而言，与所述特定应用服务器的通知周期相比，可用率测度值是由当前时间(例如，查询可用率数据库时的时间)与最近可用率时间之差来限定的。更一般地说，可将当前可用率时间与前一可用率时间之间的第二差值添加至上述可用率测度值。业已证明，下述具体的可用率测度值是成功的：

1、如果当前时间与最近可用率时间之差超过上述通知周期，则将相应的应用服务器看作是不可用的，这是因为，应用服务器“承诺”至少在通知周期内重复可用率信号。否则，将应用服务器看作是可用的。

2、可根据Alive_Signal表确定在插入由特定监视器写入的至少两个“我活着！”记录之间经过的时间，也就是说，可确定最近可用率时间与前一个可用率时间之间的时间差。如果所述持续时间超过了监视器同意插入“我活着！”消息的通知周期，则所述监视器是可能已经出故障的监视器。所述可用率测度值基于这样的假设即：如果所述至少两个可用率信号未处在预定的通知周期内，则这表示应用服务器目前正经历着问题，从而应加以避免。

3、一般地说，这种基于超时的故障判断机制必须能应付这类情形，即：监视器仅仅是太忙而不能将可用率信号写进可用率数据库但却仍然是可用的。如果当前时间与前一可用率时间之差是通知时间的N倍，则可通过将一个应用服务器看作是不可用的而实现能够应付这种情形的可用率测度值。

但是，根据可用率数据库(寿命数据库)，可以确定哪个监视器/应用服务器业已出了故障以及哪个监视器/应用服务器仍然是可用的。具体地说，能访问寿命数据库的每个程序都能进行这种检查：每个监视器、一个可为这种环境构建的独立管理组件、当然还有每个需要查找可用的应用服务器以便传送应用服务请求的应用客户机。每个应用客户机均可查询可用率数据库，以便利用上测可用率测度值去确定至少一个可用的应用服务器，然后，应用客户机可将应用服务请求发送给该应用服务器。

当监视器或应用服务器能动态地调整它们的通知周期时，则可以实现本发明的另一个最佳实施例。如果这种动态调整取决于应用服务器所处理的工作负荷，则可用率测度值会通过也表示工作负荷指标而成为一个新的参量。所述通知周期在工作负荷增加的情况下通过增加通知周期并在工作负荷减少的情况下通过减少通知周期而(同时)代表一个工作负荷指示符，该指示符表示应用服务器的响应率。应用客户机可通过并行地确定用于一组应用服务器的可用率测度值而利用这一指标。在这种情况下，可用率测度值不仅可用于确定可用的应用服务器(它仅表示一个二进制判断：“可用”与“不可用”)的子集、而且可构成由应用客户机所执行的工作负荷平衡决策的基础。作为参数的、或多或少地要受当前通知周期影响的所述可用率测度的数字值于是也是一个工作负荷指标。然后，应用客户机将其应用服务请求发送给有最低工作负荷的可用应用服务器，即发送给相对这种另一个应用请求有最大可用率测度值的应用服务器。

图5反映了一个流程图，该流程图说明了用于指示可用率的方法，该方法还包括根据工作负荷情况调整通知周期的动态方面。

在步骤501中开始应用服务器或监视器进行可用率监视的过程。在下一个步骤502中，确定当前工作负荷情况，以便计算出这样的通知周期，该通知周期与当前工作负荷周期相比，既不太高，也不太低。在步骤503，(当然)应该使计算出的通知周期进入可用率数据库。在通知周期所设定的时间参照系中，应当使当前可用率信号进入可用率数据库，步骤504反映出了这一点。所述通知周期限定了用于重复可用率信号的时间上限，应用服务器/监视器根据工作负荷试图更频繁地发送可用率信号。在步骤504之后(或者作为在这一步骤之前的另一个实施例中)，在步骤505中分析当前工作负荷情况。如果当前工作负荷情况以需要重新调整通知周期的方式而改变，则再次开始确定通知周期的处理步骤，以便选择控制路径506。如果当前工作负荷情况没有显著变化，则重复发出可用率信号，从而选择路径507。

必须仅从概念的角度来理解带有周期表(图3所示)和可用率表(图4所示)的可用率数据库的结构和布局。当然，可用率数据库的结构可以是如下所述的进一步改进的主题：

1、每次插入新的通知周期或新的可用率信号都会将一新记录引入数据库。为了防止可用率数据库持久性地增加，建议进行这样处理：删除不再有用的旧数据库记录，例如，就某一监视器/应用服务器的各种记录类型而言，仅将最近的和前一个记录保存在数据库内。为了实现这种处理，最好使用“存储过程(stored procedures)”技术，所采用的存储过程可在后台的数据库中运行，以便删除不再需要的记录。

2、对本发明来说，将通知周期和可用率信号存储到不同数据库记录中当然并不是关键所在。图6中形象化地示出了如何将两种数据元素包括到一个数据库记录内的实例。从图6中可以看出，除监视器标识/应用服务器标识600和通知周期601以外，大量的可用率信号被减少到仅为两个条目。无论何时由新的可用率信号来更新当前的可用率信号602，都将其内容传送到存储前一可用率信号603的字段中，此后，将新的可用率信号插进当前可用率信号602的字段内。利用这种技术，可用率数据库可以限制在中等规模，至于各个监视器/应用服务器，仅必须保留一个单个的数据库记录。

本发明的优点在于，所提出的技术能提高向多个应用客户机提供服务的多个应用服务器的可用率和可伸缩率。本发明提供了一种前摄技术，因为，这种技术能阻止客户机生成从非响应服务器请求服务的错误请求路由。建议在进行中的处理能高度响应动态网络环境，在这种环境中，客户机和服务器永久地进入或离开网络。因此，本发明可使服务器机器热插入应用集群，从而进一步增加环境的可伸缩性。可完全避免将应用客户机与应用服务器联系起来的复杂的、或由于其特别复杂而不可能实现的管理。

由于本发明未采用任何基于网络的消息传递，故可避免这种机制(可参考上述说明)的所有缺点。唯一的系统先决条件是一个共享的数据库。当今的数据库管理系统是非常坚固的，因此，不必将寿命数据库看作是一个出故障的点。此外，大多数应用服务器都构建在数据库系统上。因此，在许多情况下都能自动地满足共享数据库的假设。可到达性完全不是问题，因为，作为是热池宿主的各服务器机器均能访问共享数据库。最后，在将寿命数据库放进关系型DBMS中时，通过SQL可很容易地实现监视器监视技术。

Claims (17)

1、一种用于指示一个或多个应用服务器的可用率的计算机化方法，

所述方法包括将第一数据元素(301、601)插入可用率数据库(200)内的第一步骤(503)，所述第一数据元素(301、601)包括一个通知周期，所述通知周期限定了一个可用率信号的重复周期的时间上限，只要所述应用服务器是可用的，所述用可用率信号就重复下去；以及

所述方法包括将第二数据元素(401、602)插进上述可用率数据库内的第二步骤(504)，所述第二数据元素包括就各可用率信号而言的作为可用率时间的相应时间标记；并且

由此，当前时间和最近的可用率时间之差与上述通知周期相比表示所述应用服务器的可用率的测度值。

2、如权利要求1的用于指示可用率的计算机化方法，其特征在于，

所述方法包括根据上述应用服务器的工作负荷在该工作负荷增加的情况下通过使所述通知周期增加或者在该工作负荷减少的情况下通过使所述通知周期减少从而更新该通知周期的第三步骤(505)。

3、如权利要求1的用于指示可用率的计算机化方法，其特征在于，

在所述第一和第二步骤中，还将应用服务器标识(300、400、600)插进前述可用率数据库并使之与前述第一和第二数据元素相关联。

4、如权利要求3的用于指示可用率的计算机化方法，其特征在于，

如果所说的差值超过前述通知周期，则所述可用率的测度值指示前述应用服务器的不可用性。

5、如权利要求1的用于指示可用率的计算机化方法，其特征在于，

所述可用率数据库由多个应用服务器所共享，每个应用服务器均包括上述一个或多个应用服务器的热池；以及

对于上述热池，一个监视器监视着该热池的可用率状态；以及

所述方法由上述监视器来执行；以及

只要有上述热池的至少一个应用服务器是可用的，则重复所说的可用率信号；以及

在所述第一和第二步骤中，还将一个热池标识插进前述可用率数据库并使之与前述第一和第二数据元素相关联。

6、如权利要求2或5的用于指示可用率的计算机化方法，其特征在于，

作为第二差值，所述最近可用率时间与前一可用率时间(603)之差被包括在前述可用率测度值内。

7、一种用于确定接受应用服务请求的一个或多个应用服务器的可用率的计算机化方法，所述方法包括查询可用率数据库(200)的第一步骤，

对于第一数据元素(301、601)，包括一个通知周期，所述通知周期限定了可用率信号的重复周期的时间上限，只要所述应用服务器是可用的，所述可用率信号就重复下去；以及

对于第二数据元素，包括就各可用率信号而言的作为可用率时间的相应时间标记；以及

所述方法包括通过比较当前时间和当前可用率时间之差与所述通知周期来确定所述应用服务器的可用率的测度值的第二步骤；

所述方法包括在所述可用率测度值指示出所述指示服务器的可用率的情况下仅将应用服务请求发送给所述应用服务器。

8、如权利要求7的用于确定可用率的计算机化方法，其特征在于，

如果所述差值超过前述通知周期，则所述可用率测度值指示前述应用服务器的不可用性。

9、如权利要求7的用于确定可用率的计算机化方法，其特征在于，

所述方法在上述第一步骤中还对第三数据元素(603)进行查询，所述第三数据元素包括用于前一可用率信号的前一可用率时间，以及

在所述第二步骤中，作为第二差值，所述最近可用率时间与前一可用率时间(603)之差被包括在所述可用率测度值内。

10、如权利要求7的用于确定可用率的计算机化方法，其特征在于，

如果所述差值是前述通知周期的N倍，则所述可用率测度值指示前述应用服务器的不可用性。

11、如权利要求9的用于确定可用率的计算机化方法，其特征在于，

对多个应用服务器执行所述方法；以及

在所述第三步骤中，

确定应用服务器的一个子集，其中包括所述可用率测度值对其指示出了可用率的那些应用服务器；以及

对于所述子集中的各应用服务器，将其相应的可用率测度值解释为工作负荷指标；以及

将所述应用服务请求发送给有最低工作负荷的应用服务器。

12、一种用于指示一个或多个应用服务器的可用率的系统，所述系统包括用于执行前述权利要求1至6中任何一项的方法的步骤的装置。

13、一种在数据处理系统内执行的数据处理程序，该程序包括用于执行前述权利要求1至6中任何一项的方法的软件代码部分。

14、一种存储在计算机可用介质上的计算机程序产品，它包括计算机可读程序装置，该装置用于使计算机执行前述权利要求1至6中任何一项的方法。

15、一种用于确定接受应用服务请求的一个或多个应用服务器的可用率的系统，所述系统包括用于执行前述权利要求7至11中任何一项的方法的步骤的装置。

16、一种在数据处理系统内执行的数据处理程序，该程序包括在所述程序在计算机上运行时用于执行前述权利要求7至11中任何一项的方法的软件代码部分。

17、一种存储在计算机可用介质上的计算机程序产品，它包括计算机可读程序装置，该装置在所述程序在计算机上运行时用于使计算机执行前述权利要求7至11中任何一项的方法。

Images