客户机/服务器网络中服务器对象之间的工作负荷管理的制作方法

专利名称：客户机/服务器网络中服务器对象之间的工作负荷管理的制作方法
技术领域：
本发明涉及客户机/服务器(也称为“分布式”)计算，在其中，例如，一个计算设备(“客户”)请求另一个计算设备(“服务器”)执行一部分客户的工作。
过去几年中，客户机/服务器计算已在信息技术领域中变得越来越重要。这种类型的分布式计算允许某个计算机上运行的一个过程(“客户”)把其工作的一部分委托到在另一个计算机上运行的另一个过程(“服务器”)，例如，由于后者可能更适合执行该工作。客户机和服务器也可能是在同一物理计算机上运行的二个过程。
通过采用周知的称为面向对象的程序设计(OOP)的计算机编程技术，客户机/服务器计算的好处得到进一步的提高，OOP允许客户机和服务器位于不同的(多机种的)“平台”上。平台是计算机用以完成其工作的具体硬件/软件/操作系统/通信协议的组合。OOP允许客户机应用程序以及服务器应用程序在它们各自的平台上操作，不必操心客户机应用程序的工作请求将如何和服务器应用程序通信以及如何由服务器应用程序接收。类似地，服务器应用程序不必操心OOP系统将如何接收、变换服务器应用程序的处理结果并发送回到请求的客户应用程序上。
美国专利5,440,744号和欧洲专利公开申请EP0677,943A2解释了如何和多机种客户机/服务器系统集成的OOP技术的细节。这二篇资料是本文的参考文献。然而，下面将给出基本体系结构的一个例子，以便理解本发明的环境的前后关系。在该例子中，客户机和服务器位于不同的计算机上，但是，如果它们位于相同的计算机上，会应用相同的软件体系结构。
如

图1中所示，客户计算机10(它例如可能是一台在其上安装着IBM OS/2操作系统的个人计算机)具有某个在它的操作系统上运行的应用程序40(“IBM”和“OS/2”是国际商用机器公司的商标)。应用程序40周期地请求在服务器计算机20执行工作和/或从服务器回送应用程序40接着使用的数据。服务器计算机20例如可以是一台在IBM的MVS操作系统下运行的高性能大型计算机(“MVS”也是IBM公司的商标)。对于本发明的目的，是否通过用户交互利用第一应用程序40启动由服务器实施的通信服务请求，或者是否由应用程序40独立地操作用户接口并在运行该程序期间自动地作出请求，是没有关系的。
当客户计算机10希望对服务器计算机20的服务作出请求时，第一应用程序40通知第一逻辑装置50所需的服务。具体做的例子可以是，向第一逻辑装置发送远程过程名及输入输出参数表。接着，第一逻辑装置50参照存储部件60中存储的可使用的通信服务的解说处理寻找并建立与第二计算机20的必要通信的任务。所有可能的服务被定义为各对象类70的内聚(cohesive)框架。在该过程期间，第一逻辑装置确定一个对象标记，该对象标记具有一个识别服务器计算机20的组元(服务器地址)并具有另一个识别位于服务器计算机20上的特定服务器对象的组元(对象关键字)。以这种方式定义服务可在性能上和可重复使用性上产生许多优点。
为了建立和服务器20的必要通信，第一逻辑装置50确定需要使用框架中的那个对象类，然后产生该对象的一个事例，并产生一条发送给该对象的报文以使该对象调用它的各方法中的一个方法。这导致通过连接装置80建立与服务器计算机20的连接，并相继地向第二逻辑装置90发送某个请求。
第二逻辑装置90接着把该请求传送到在服务器计算机20上运行的第二应用程序100(以下称为服务应用)，从而服务应用100可以执行该请求所需的具体任务，例如运行某个数据检索过程。一旦完成该任务，该服务应用可能需要把结果送回到第一计算机10。在执行所需的任务期间以及在向第一计算机10回送结果时，服务器应用程序100和第二逻辑装置90交互。第二逻辑装置90建立各对象的事例，并且随服务器应用程序100的需要调用这些对象的适当方法，对象事例是从存储在存储部件110中的各对象类的内聚框架建立的。
利用上述的技术，客户应用程序40不对通信体系结构暴露。此外，服务应用100是通过它的环境下的标准机制调用的；它不知道它正被远程调用。
对象管理组(OMG)是涉及到如图1中所示的多机种平台上的客户机/服务器计算的各个方面的各种机构的国际合作组织。OMG已经颁布各种客户机(例如10)和服务器(例如20)通信(在OOP形式下)的标准。作为这些标准的一部分，已经定义了对象请求代理器(Broker)，其被称为公用对象请求代理器体系结构或简写为CORBA，它在客户机和服务器之间提供面向对象的桥路。对象请求代理器(ORB)把客户机和服务器同面向对象的实施细节隔绝起来，完成第一和第二逻辑装置50和90以及连接装置80的至少一部分的工作。
常常配置重复的服务器资源(以多个服务器的形式)，以使“服务器”能够同时处理大量的客户请求并且能够容忍故障(若一个服务器是出故障的，可以使另一个服务器取而代之)。各个客户机认为它们和单个“服务器”通信，但是，事实上，多个(或成组的)服务器处理许多请求(这些服务器可以位于不同的计算机上，或者可以是在同一计算机上运行独立的过程)。在这个意义上，派往“服务器”的各个客户请求是朝向一个中央网关(对于组成“服务器”的所有服务器计算机它是公用的)，该中央网关执行工作负荷管理以及负荷平衡，以便根据任何周知的工作负荷平衡策略(或多种策略的组合)，诸如循环方法策略，把客户请求分配到组里的不同服务器中，在循环策略中轮流地向各个服务器分配请求。在调度新的请求时，组中各服务器的当前工作负荷也是一个常采用的因素(即，把新请求分配给一个具有低当前工作负荷的服务器)。所采用的平衡策略/平衡策略集的具体细节是由配置“服务器”系统结构的人选择的，该人员典型地是系统管理员。
作为CORBA标准的一部分，定义了ORB之间的通信协议，称之为通用对象请求代理器间协议(GIOP)。该协议基本上是一个报文表，客户ORB和服务器ORB可以互相发送这些报文。当把因特网当作客户ORB和服务器ORB之间的传递媒体时，需要把GIOP变换到TCP/IP层(TCP/IP是因特网业务的基础)。这种变换被称为因特网对象请求代理器间(Inter-Orb)协议(IIOP)。
从而，所有的已知工作负荷管理网关，例如上述所述的管理网关都在IIOP层执行工作负荷管理策略。也就是说，IIOP网关接收来自客户ORB的用户请求并且接着着手把服务器组中的一个服务器分配给该请求，所有的一切都在IIOP层发生。一旦IIOP网关选择出该组中的一个服务器，为了把该请求发送到该选定的服务器网关必须接着生成另一个IIOP请求。为了把进入的客户请求重定向到选定的服务器，IIOP网关必须对每个客户请求中所包括的参数表编组及去编组，从而在网关处需要大量的工作，这放慢整个系统的动作并造成低效设计。
1997年9月宣布的IBM的Component Broker Series(IBM的一个商标)产品涉及到对客户ORB增添特别的功能，以允许在一组对象服务器中实施工作负荷管理。这样，对于具有该附加功能的客户，免除掉了需要经过网关路由器传送请求。请参见1997年5月8日提交的美国专利申请S.N.853,102。但是，这种方法只能应用于安装着该特别功能的客户机，而不能应用到涉及到大范围的客户的环境中。不具有该附加功能的客户仍旧必须经过这种IBM产品中的IIOP路由器发送它们的请求。
从而，现有技术中需要一种方法，以便在更有效的方式下允许大范围的客户访问工作负荷管理服务器组中的各个资源。
根据第一方面，本发明提供一种面向对象的客户机/服务器计算环境中在一组服务器对象之间执行工作负荷管理的方法，该方法包括步骤接收客户请求；访问一个事先由该组服务器输出的一个指针，该指针指向一个工作负荷管理部件；利用该工作负荷管理部件对该客户请求执行工作负荷管理以便从该组服务器中选出应使用的服务器来满足该请求，工作负荷管理在网间协议(IP)层上进行；以及把该客户请求传送到该选定的服务器。
最佳性能如下。该指针是一个具有主机名字段的对象标记，该主机名字段含有一个充当工作负荷管理部件的IP路由器的名字或IP地址。备择地，该指针是一个具有主机名字段的对象标记，该主机名字段含有一个标识该组服务器的标识符，该标识符由一个充当工作负荷管理部件的动态域名服务器识别。
根据第二方面，本发明提供一组配置成用于工作负荷管理的对象服务器，其中该组服务器向希望调用该组以执行某些工作的客户输出一个对象标记，该对象标记具有一个指向工作负荷管理部件的字段，该工作负荷管理部件在网间协议(IP)层执行该组服务器之间的工作负荷管理。
根据第三方面，本发明提供一种存储在计算机可读存储介质上的计算机程序产品，该产品在计算机上运行时实现上面根据第一方面所说明的方法。
根据第四方面，本发明提供一种设备，用于在面向对象的客户机/服务器计算环境中的一组对象服务器之间执行工作负荷管理，该设备包括用于接收客户请求的装置；用于访问一个事先由该组服务器输出的指针的装置，该指针指向一个工作负荷管理部件；用于利用该工作负荷管理部件对所述客户请求进行工作负荷管理以便从该组服务器中选出应使用的服务器来满足该请求的装置，工作负荷管理在网间协议(IP)层上进行；以及用于把该客户请求传送到该选定的服务器的装置。
通过在IP层执行工作负荷管理，由于编组及去编组参数表所涉及到的处理量保持为最小，可以快速地和有效地把请求发送到服务器组中的选定对象服务器。此外，不需要为了实现这种有效的工作负荷管理而对客户增添额外的软件。
通过下述对各最佳实施方式的详细说明可更好地理解本发明，各最佳实施方式是参照下述附图呈现的。
图1是周知的采用着对象技术的多机种客户机/服务器体系结构的方块图；图2是一个方块图，表示本发明的第一最佳实施方式的软件单元；
图3是一个方块图，表示本发明的第二最佳实施方式的软件单元；图4是表示根据图2的第一最佳实施方式的对象标记的IIOP简表的一些字段；图5是一个流程图，表示图2和图4的第一最佳实施方式的操作期间所采取的步骤；图6是表示根据图3的第二最佳实施方式的对象标记的IIOP简表的一些字段；以及图7是一个流程图，表示图3和图6的第二最佳实施方式的操作期间所采取的步骤。
图2中第一最佳实施方式的服务器组23包括多个对象服务器23a-23c，如上面所解释，每个对象服务器是为了对客户请求服务而设置的。图2的客户21a、21b和21c类似于图1中所示的客户，即各具有一个应用层、一个代理(proxy)对象以及一个ORB层(后二个单元对应于图1中的部件50、60、70和80)。在图1的这种现有技术配置中，当第一应用程序40希望使一个服务器做它的一部分工作时，它向代理对象发送一条规定要做什么的报文。代理对象从该请求中寻找一个对象标记(其事先由某服务器输出)并把该对象标记传送给ORB,ORB利用该对象标记中所包含的服务器地址把该请求路由选择到该服务器上。该对象标记还包括对象关键字，后者标识为处理客户请求该服务器应调用那个对象。
在图2中，当把对象服务器组23a-23c对待成用于工作负荷管理目的的一组对象时，工作负荷平衡属性和一个类相联系，当在服务器设置该类时记录该类。此属性是一个布尔值，其确定该类的对象是否适用于工作负荷平衡。例如，可定义一个IDL(接口定义语言)接口“WorkloadBalanced”，必须进行工作负荷平衡的对象类必须从该接口继承。当从某服务器ORB向各客户ORB输出一个对象标记时，服务器ORB检查相关的对象是否属于配置成适用于工作负荷管理(平衡)的一类。若它不属于，则根据常规过程输出该对象标记。但是，若它属于，必须在带有一个IOP简表下输出该对象标记，该IIOP简表在某些字段中含有一定的值，如后面所说明的那样。
在图2中，服务器组23向各个客户21a-21c输出一个内部可操作的对象标记(IOR)，从而各客户明白为作出请求应如何和该服务器组接触。如图4所示，输出的IOR包含一个IIOP简表41，后者具有一个主机名字段411，该主机名字段411包含着一个含有IP路由器22的服务器过程(通常称为IP喷射器(sprayer))的IP地址。备择地，主机名字段411可包括一个用于该服务器组的名字(例如，SG1.1)，通过访问一个标准域名服务器(DNS)客户可把该名解成IP路由器22的IP地址。IIOP简表41还包括一个端口号字段412，其含有该IP路由器22用来监听进入的IIOP请求的端口号。此外，IIOP简表41具有一个对象关键字字段413，其含有一个标识该服务器组的标识符(从而该服务器组能够识别它先前已输出的各对象关键字，从而可为它们构造本地对象，与对由其它服务器输出的对象构造代理相异)。
从而，当客户21b的ORB对服务器组23作出某请求时，该客户ORB首先和位于IPR(即由对象标记指向的服务器过程)的包含着IP路由器22的服务器过程接触。接着，IP路由器22利用(上面所述的)工作负荷管理策略作出为对该特定的客户请求服务应选择那个对象服务器的决策。该工作负荷管理决策是在TCP/IP层进行的。也就是说，该IP路由器22查看该服务器组23中的每个对象服务器1至n的IP地址(IP1至IPn)，做出工作负荷管理决策以在该服务器组中选择一个具体的对象服务器，然后简单地把来自IPR的请求传送到选定对象服务器的IP地址。路由器22在该服务器组23中的各个对象服务器的IP地址之间作出工作负荷平衡。
IP路由器22可使用IBM的交互式网络调度程序的网络调度功能(在“交互式网络调度程序用户指南”中说明，IBM资料GC31-8496-00)，并由ISS(交互式对话支持)工作负荷监视代理(agent)提供和该服务器组中每个对象服务器有关的工作负荷信息。可在含有对象服务器的每个计算机上运行一个ISS工作负荷监视。该代理发出可配置的命令组以确定计算机的工作负荷。例如，该代理可以确定其在上面运行的计算机的CPU使用率和/或对该服务器已作出的和/或长期连接的数量。IP路由器22利用该采集的工作负荷数据，从而做出在某具体时间选择组中那个对象服务器的有关决策。另外，可以把“交互式网络调度程序”的IP路由器配置成具有一个“粘性”端口，从而来自某给定客户IP地址的所有请求都重定向到一个相同的服务器。
现结合图5的流程图说明在一组服务器对象之间进行工作负荷管理所涉及的步骤。在该例中，客户21b对服务器组23做出请求。
在步骤51，客户21b的ORB访问先前由服务器组23输出到客户21b的IOR的IIOP简表41。在该IIOP简表41的字段411中，客户21b的ORB判定IP路由器22位于IP地址IPR并且该IP路由器22正在监听端口PORTR上的IIOP请求。从而，客户21b的ORB产生一个IIOP请求，并且利用从IIOP简表41获悉的TCP/IP连接信息把请求发送到IP路由器22。
当IP路由器22接收该请求时，它利用工作负荷管理数据选择组23的对象服务器23a至23c中的一个对象服务器(步骤52)。接着，IP路由器22把客户21b的IIOP请求重定向到选出的对象服务器的IP地址(步骤53)。然后，选定的对象服务器会使用对象关键字字段413中的对象关键字OK23，以标识该选定的对象服务器上的要被调用的具体对象(这是作为组23的一个成员的该对象服务器上的那个输出图4中所示的对象标记的对象)。
因为服务器组标识符包含在工作负荷可管理对象组的对象关键字中，选出的服务器可以判定该对象是由服务器中的一个成员输出的，并且据此建立或激励一个本地对象而不是一个远程对象的一个代理。
应该注意到，在该第一实施方式中，一旦IP路由器22选择出服务器组23中的一个服务器，IP路由器22不必为了把请求发送到选出的服务器而必须在IIOP层生成一个请求。替代地，IP路由器22在不必对该请求做进一步的处理变到IIOP层下简单地把该客户请求重定向到该选出服务器的IP地址上。IP路由器和选定的服务器之间的通信位于IP层。这对进入的IIOP客户请求造成非常快的和非常有效的再路由选择。一旦建立和该选定服务器的连接，在该连接的生命周期内IIOP请求被重定向到该服务器。
在图3的第二最佳实施方式中，当服务器组的ORB输出一个需要工作负荷管理的IOR时，该IOR把请求客户指向一个执行工作负荷管理的动态域名服务器(DNS)32。
具体地，图6的IOR的IIOP简表61含有一个字段611中的标识该服务器组的主机名(例如，SG1.1)，一个规定在和某服务器连接期间所使用的一个端口号的端号字段612以及一个对象关键字字段613。当客户31c的ORB希望对服务器组33发送一个请求时，访问图6的IOR。由于在字段611中存储着主机名(而不是IP地址)，该ORB把主机名SG1.1发送到动态DNS32(图7流程图的步骤71，该流程图示出第二最佳实施方式的操作)。动态DNS32得到服务器组33的主机名并进行分解以便动态地选择出服务器组33的对象服务器中的一个IP地址(IP1至IPn)(步骤72)。也就是说，通过考虑服务器组33中的各个对象服务器的IP地址并且从中选择出一个，在动态DNS32中执行工作负荷管理。
更具体地，常规DNS会接收作为输入的主机名并且总把相同的IP地址提供为输出。但是，动态DNS会把主机名作为输入并寻找在该主机名下存储的多个IP地址(服务器组中的每个服务器各有一个IP地址)。动态DNS考虑每个IP地址，并根据选定的工作负荷管理策略(或策略组)选出其中的一个IP地址输出到客户31c的ORB。可以把IBM的交互式网络调度程序的交互式对话支持(ISS)子例程用作为动态DNS。
一旦客户31c的ORB接收到选定服务器33b的IP地址，客户31c产生一个IIOP请求并且利用在IOR的IIOP简表的字段612中规定的端口号PORT1.1把该请求发送到对象服务器33b(步骤73)。该选定的对象服务器接着会使用对象关键字字段613中的对象关键字OK33去标识要调用的该选定对象服务器上的具体对象(这是作为组33的一个成员的该对象服务器上的那个输出图6中所示的对象标记的对象)。
请注意，在第二实施方式中，必须在IIOP层发生的只有一个请求流，即从客户31c到服务器33b的请求流。动态DNS32和客户31c之间的通信位于IP层。这造成非常快地和非常有效地把客户请求分配给服务器组中一个经过工作负荷平衡选择的服务器。一旦建立和该选定服务器的连接，在该连接的生命周期内IIOP请求被重定向到该服务器。
通过在动态DNS的后面设置多个IP路由器可把所说明的二种实施方式组合起来。这些IP路由器应该依次地放在公用后端服务器组的前面。
权利要求
1．一种面向对象的客户机/服务器计算环境中在一组对象服务器之间执行工作负荷管理的方法，所述方法特征在于包括步骤接收客户请求；访问一个事先由该组服务器输出的一个指针，所述指针指向一个工作负荷管理部件；利用所述工作负荷管理部件对所述客户请求执行工作负荷管理以便从所述服务器组中选出应使用的服务器来满足该请求，所述工作负荷管理在网间协议(IP)层上进行；以及把所述客户请求传送到选定的服务器。
2．权利要求1的方法，其特征在于，所述指针是对象标记。
3．权利要求2的方法，其特征在于，所述对象标记具有一个主机名字段，该字段包含某IP路由器的名字或IP地址。
4．权利要求2的方法，其特征在于，所述对象标记具有一个主机名字段，该字段包含一个标识所述服务器组的标识符。
5．权利要求1的方法，其特征在于，所述工作负荷管理部件是一个IP路由器。
6．权利要求1的方法，其特征在于，所述工作负荷管理部件是一个动态域名服务器。
7．一组配置成用于工作负荷管理的对象服务器，其特征在于，所述组向希望调用该组以执行某些工作的客户输出一个对象标记，所述对象标记具有一个指向一个工作负荷管理部件的字段，该工作负荷管理部件在网间协议(IP)层执行所述组之间的工作负荷管理。
8．权利要求7的对象服务器组，其特征在于，所述对象标记具有一个主机名字段，该字段包含某IP路由器的名字或IP地址。
9．权利要求7的对象服务器组，其特征在于，所述对象标记具有一个主机名字段，该字段包含一个标识所述服务器组的标识符。
10．权利要求7的对象服务器组，其特征在于，所述工作负荷管理部件是一个动态域名服务器。
11．一种存储在计算机可读存储介质上的计算机程序产品，当其在计算机上运行时，用户实现一种面向对象的客户机/服务器计算环境在一组对象服务器之间执行工作负荷管理的方法，所述方法特征在于包括步骤接收客户请求；访问一个事先由该组服务器输出的一个指针，所述指针指向一个工作负荷管理部件；利用所述工作负荷管理部件对所述客户请求执行工作负荷管理以便从所述服务器组中选出应使用的服务器来满足该请求，所述工作负荷管理在网间协议(IP)层上进行；以及把所述客户请求传送到选定的服务器。
12．一种用于在面向对象的客户机/服务器计算环境中的一组对象服务器之间执行工作负荷管理的设备，所述设备特征在于包括用于接收客户请求的装置；用于访问一个事先由该组服务器输出的指针的装置，所述指针指向一个工作负荷管理部件；用于利用所述工作负荷管理部件对所述客户请求进行工作负荷管理以便从所述服务器组选出应使用的服务器来满足该请求的装置，所述工作负荷管理在网间协议(IP)层上进行；以及用于把所述客户请求传送到选定服务器的装置。
全文摘要
描述为工作负荷管理而配置的对象服务器组,在其中该服务器组向可能希望调用该组以执行某些工作的客户输出一个对象标记。该对象标记具有一个指向一个工作负荷管理部件的字段,工作负荷管理部件于网间协议(IP)层在该组服务器之间执行工作负荷管理。
文档编号H04L29/08GK1226702SQ9812280
公开日1999年8月25日 申请日期1998年11月26日 优先权日1998年2月19日
发明者肯尼斯·埃德华·戴维斯, 当纳·加尔－廷·迪伦伯格, 格林·诺尔明顿 申请人:国际商业机器公司