CN1265295C

CN1265295C - 集团型企业java分布式处理系统

Info

Publication number: CN1265295C
Application number: CNB998146765A
Authority: CN
Inventors: 迪安·B·雅各布斯; 安诺·R·兰根
Original assignee: BEA Systems Inc
Current assignee: Oracle International Corp
Priority date: 1998-11-05
Filing date: 1999-10-21
Publication date: 2006-07-19
Anticipated expiration: 2019-10-21
Also published as: EP1149340B1; US20060031846A1; US6941555B2; JP2002529852A; CA2349864C; EP1149340A4; ATE549674T1; US20030195996A1; CN1359495A; AU1217400A; CA2349864A1; AU761547B2; US7334232B2; EP1149340A1; KR20010092446A; US6571274B1; KR100614266B1; WO2000028421A1

Abstract

本发明提供了一种集团型企业Java分布式处理系统，该分布式处理系统包括与通信媒体连接的第一和第二计算机。第一计算机包括Java虚拟机(JVM)和含有远程Java虚拟机(RJVM)的、用于传送消息的核心软件层。第二计算机包括JVM和含有RJVM的核心软件层。消息从RJVM传送到一个计算机中的JVM，再传送到第二个计算机的JVM和RJVM。消息可以通过中间服务器转发或在网络重新配置之后重新择径。每个计算机包括含有复制处理器的智能存根模块，包括负载平衡软件部分和故障处理软件部分。每个计算机包括在节点上存储智能存根模块库的复制服务命名树。该计算机可以以无状态、无状态工厂、或有状态编程模型编程。集团型企业Java分布式处理系统允许提高规模可伸缩性和容错性。

Description

集团型企业JAVA分布式处理系统

发明领域

本发明涉及分布式处理系统，具体涉及分布式处理系统中的计算机软件。

相互参照相关申请

本申请要求1998年11月5日提出的美国临时申请No.60/107,167的权益。

下列同时待审的美国专利申请已转让给本申请的受让人，将它们的公开文本援引于此以供参考：

(A)申请号：尚不知(代理人备案号(Attorney Docket No.)：BEAS1027)，由Dean B.Jacobs和Anno R.Langen提出申请(申请日尚不知)，原标题：让消息通过分布式处理系统中的核心模块的集团型企业JAVA^TM(“CLUSTEREDENTERPRISE JAVA^TMHAVING A MESSAGE PASSING KERNEL IN A DISTRIBUTEDPROCESSING SYSTEM”)；

(B)申请号：尚不知(代理人备案号：BEAS1029)，由Dean B.Jacobs和Eric M.Halpern提出申请(申请日尚不知)，原标题：分布式处理系统中的智能存根模块或企业JAVA^TM豆模块(“A SMART STUB OR ENTERPRISE JAVA^TMBEANIN A DISTRIBUTED PROCESSING SYSTEM”)；和

(C)申请号：尚不知(代理人备案号：BEAS1030)，由Dean B.Jacobs和Eric M.Halpern提出申请(申请日尚不知)，原标题：分布式处理系统中的复制命名服务(“A DUPLICATED NAMING SERVICE IN A DISTRIBUTEDPROCESSING SYSTEM”)。

发明背景

存在若干种类型的分布式处理系统。一般地说，分布式处理系统包括多个处理设备，例如，两个与通信媒体连接的计算机。通信媒体可以包括有线媒体、无线媒体、或它们的组合，例如，以太(Ethernet)局域网或蜂窝网。在分布式处理系统中，至少有一个处理设备可以将通信媒体上的信息传送到另一个处理设备上。

图1所示的客户机/服务器结构110是一种类型的分布式处理系统。客户机/服务器结构110包括至少两个处理设备，表示为客户机105和应用程序服务器103。附加的客户机也可以与通信媒体104连接，例如客户机108。

通常，服务器103是商用逻辑模块(business logic)的宿主和/或协调事务处理以向另外的处理设备，例如客户机105和/或客户机108提供服务。应用程序服务器103通常用提供服务的软件编程。软件可以利用各种各样的编程模型，例如图1a-b所示的Enterprise Java^TM Bean(“EJB”)100b编程。服务可以包括，例如，检索和传送来自数据库的数据，提供图像和/或解方程。例如，服务器103可以响应来自客户机105的请求，通过通信媒体102从永久性存储器件101中的数据库101a检索数据。然后，应用程序服务器103可以通过通信媒体104传送请求数据到客户机105。

客户机是利用来自服务器的服务和可以请求服务的处理设备。用户106经常与客户机105交互操作，并可以使客户机105通过通信媒体104从应用程序服务器103请求服务。客户机经常处理与最终用户的直接交互操作，例如接受请求和显示结果。

各种各样不同类型的软件可以用于编程应用程序服务器103和/或客户机105。一种编程语言是Java^TM编程语言。Java^TM应用程序目标代码被装载到Java^TM虚拟机(“JVM”)中。JVM是装载到模拟特定机器或处理设备的处理设备中的程序。关于Java^TM编程语言的更多信息可以从http://www.javasoft.com站点上获得，将这个站点列在这里以供参考。

图1b表示若干种Java^TM企业应用编程接口(“API”)100，这些接口允许Java^TM应用代码仍然独立于基本事务处理系统、数据库、和网络基础设施。Java^TM企业API 100包括：例如，远程方法调用(“RMI”)100a、EJB 100b、和Java^TM命名和目录接口(JNDI)100c。

RMI 100a是经常用在如下所述的对等结构(peer-peer architecture)中的分布式编程模型。具体地说，一组类别和接口使一个Java^TM对象能够调用在不同JVM上运行的另一个Java^TM对象的公开方法。

EJB 100b的示例通常用在如上所述的客户机/服务器结构中。EJB 100b的示例是软件成分或可以与其它成分组合的可重用预建的一段封装的应用程序代码。通常，EJB 100b的示例包括商用逻辑单元。存储在服务器103中的EJB 100b示例通常管理永久性、事务处理、并发性、线程处理和安全性。

JNDI 100c向Java^TM软件应用程序提供目录和命令功能。

客户机/服务器结构110存在着许多缺点。首先，因为服务器103不得不处理许多连接，所以结构110的规模不能太大。换言之，可以附加到服务器103上的客户机的数量受到限制。另外，加倍地添加处理设备(客户机)未必向你提供加倍的性能。其次，难以维护客户机105和108上的应用程序代码。第三，结构110易遭受一些系统故障或单点故障。如果服务器101发生故障并无法备份，那么客户机105将不能获得服务。

图1c表示多层结构160。客户机151和152管理与最终用户的直接交互操作，接受请求和显示结果。应用程序服务器153寄存应用程序代码、协调通信、同步和事务处理。数据库服务器154和便携式存储装置155提供数据的持续事务型管理。

多层结构160具有与客户机/服务器结构110相似的上述缺点。

图2表示对等结构214。处理设备216、217和218与通信媒体213连接。处理设备216、217和218包括通过媒体213通信用的网络软件210a、210b、和210c。通常，在对等结构中的每个处理设备具有相似的处理能力和应用程序。对等程序模型的例子包括Common Object Request BrokerArchitecture(公用对象请求中介架构)(“CORBA”，)和Distributed ObjectComponent Model(分布式对象组件模型)(“DCOM”)结构。

在一个平台特定的分布式处理系统中，各个处理设备可以运行相同的操作系统。这样就允许诸如共享盘、多尾盘(multi-tailed disk)和高速互连之类的专有硬件用于处理设备之间的通信。该特定的分布式处理系统平台的例子包括IBM^Corporation′s S/390 Parallel Sysplex^、Compaq′s TandemDivision Himalaya服务器、Compaq′s Digital Equipment Corporation^TM(DEC^TM)Division OpenVMS^TM Cluster软件、和Microsoft CorporationWindows NT^Cluster Services(Wolfpack)。

图2b示出了事务处理(TP)结构220。具体地说，TP结构220示出了BEA^Systems，Inc.TUXEDO^结构。TP监视器224分别通过通信媒体280、281和282与处理设备ATM 221、PC 222和TP监视器223连接。ATM 221可以是自动出纳机，PC 222可以是个人计算机，和TP监视器223可以是另一个事务处理监视器。TP监视器224通过通信媒体283、284和285与后台服务器225、226和227连接。服务器225通过通信媒体286与永久性存储装置287、存储数据库289连接。TP监视器224包括工作流控制器224a，工作流控制器224a用于将来自诸如ATM 221、PC 222、或TP监视器223的处理设备的服务请求择径(routing)到诸如服务器225、226和227的各种服务器。工作流控制器224a允许做到(1)服务器之间的工作负载平衡，(2)受限制的规模可伸缩性或允许附加的服务器和/或客户机，(3)冗余后台服务器的容错性(或服务请求可以由工作流控制器发送到没有故障的服务器)，和(4)会话集中以限制同时连接到后台服务器的数量。其它事务处理结构的例子包括IBM^Corporation′s CICS^、Compaq′s Tandem DivisionPathway/Ford/TS、Compaq′s DEC^TM ACMS、和Transarc Corporation′sEncina。

TP结构220也存在着许多缺点。首先，单个处理设备或TP监视器224的故障可以使网络变成不能工作。其次，规模可伸缩性或与TP监视器224连接的处理设备(服务器和客户机两者)的数量可能受TP监视器224的硬件或软件的限制。第三，将客户机请求择径到服务器的灵活性受到限制。例如，如果通信媒体280不能工作，但通信媒体290可以使用，那么，ATM 221通常不可以通过通信媒体290直接从服务器225请求服务，而必须访问TP监视器224。第四，客户机通常不知道后台服务器或其它处理设备的状态。第五，没有工业标准软件或API用于负载平衡。和第六，即使客户机含有能够进行高效服务的相关信息，客户机通常也不可以选择特定的服务器。

因此，最好是能提供一种分布式处理系统，尤其是能提供一种具有现有技术分布式处理系统的优点而没有其固有缺点的分布式处理系统软件。该软件应该考虑到通常用在客户机/服务器、多层或对等分布式处理系统中的工业标准API。该软件应该支持各种各样的计算机编程模型。并且，该软件还应该能允许(1)提高容错性、(2)有效率的规模可伸缩性、(3)有效的负载平衡、和(4)会话集中控制。改进了的计算机软件应该考虑到重新择径或网络重新配置。此外，该计算机软件还应该允许处理设备状态的确定。

发明概述

本发明的目的是提供一种改进分布式处理系统，尤其提供一种供分布式处理系统用的计算机软件。该计算机软件改进了分布式处理系统的容错性，以及能有高效率的规模可伸缩性。该计算机软件允许有效的负载平衡和会话集中。该计算机软件支持重新择径或计算机网络的重新配置。该计算机软件支持各种各样的计算机编程模型和允许用在客户机/服务器和对等分布式处理结构两者中的工业标准API的使用。该计算机软件允许服务器或其它处理设备状态的确定。该计算机软件还支持在包括安全性模型在内的各种情况下的消息转发。

根据本发明的一个方面，分布式处理系统包括与第一处理设备和第二处理设备连接的通信媒体。第一处理设备包括模拟处理设备(“JVM1”)的第一软件程序，含有具有数据结构(“RJVM1”)的第一核心软件层。第二处理设备包括模拟处理设备(“JVM2”)的第一软件程序，含有具有数据结构(“RJVM2”)的第一核心软件层。来自第一处理设备的消息通过第一处理设备中的第一核心软件层和第一软件程序传送到第二处理设备中的第一核心软件层和第一软件程序。

根据本发明的另一个方面，在第一处理设备中的第一软件程序是Java^TM虚拟机(“JVM”)，和在第一处理设备中的数据结构是远程Java^TM虚拟机(“RJVM”)。类似地，在第二处理设备中的第一软件程序是JVM，和在第二处理设备中的数据结构是RJVM。第二处理设备中的RJVM对应于第一处理设备中的JVM。

根据本发明的另一个方面，第一处理设备中的RJVM包括接头(socket)管理器软件部分、线程(thread)管理器软件部分、消息择径软件部分、消息压缩软件部分、和/或对等消失(peer-gone)检测软件部分。

根据本发明的另一个方面，第一处理设备利用从由下列协议组成的协议组中选择的协议与第二处理设备进行通信：Transmission Control Protocol(传输控制协议)(“TCP”)、Secure Sockets Layer(安全接头协议)(“SSL”)、Hypertext Transport Protocol(超文本传输协议)(“HTTP”)隧道技术、和Internet InterORB Protocol(互联网ORB间协议)(“IIOP”)隧道技术。

根据本发明的另一个方面，第一处理设备包括存储Java^TM应用程序的存储器。

根据本发明的另一个方面，第一处理设备是第二处理设备的对等物。此外，第一处理设备是服务器，和第二处理设备是客户机。

根据本发明的另一个方面，第二通信媒体与第二处理设备连接。第三处理设备与第二通信媒体连接。第三处理设备包括模拟处理设备(“JVM3”)的第一软件程序，含有具有第一数据结构(“RJVM1”)和第二数据结构(“RJVM2”)的核心软件层。

根据本发明的另一个方面，第一处理设备包括含有复制管理器软件部分的存根模块(“stub”)。复制管理器软件部分包括负载平衡软件部分和故障处理(failover)软件部分。

根据本发明的另一个方面，第一处理设备包括Enterprise Java^TMBean对象。

根据本发明的另一个方面，第一处理设备包括存储在树节点上的、含有存根模块库的命名树，和第二处理设备包括该命名树的复制件。

根据本发明的另一个方面，第一处理设备包括以无状态程序模型(stateless program model)编码的应用程序，和该应用程序包括无状态会话豆模块(stateless session bean)。

根据本发明的另一个方面，第一处理设备包括以无状态工厂程序模型(stateless factory program model)编码的应用程序，和该应用程序包括有状态会话豆模块(stateful session bean)。

根据本发明的另一个方面，第一处理设备包括以有状态程序模型(stateful program model)编码的应用程序，和该应用程序包括实体会话豆模块(entity session bean)。

根据本发明的另一个方面，提供包括信息存储媒体的制品。该制品包含将消息从第一处理设备中的RJVM传送到第二处理设备中的RJVM的第一组数字信息。

根据本发明的另一个方面，该制品包含第一组数字信息，包括含有从多个服务提供者中选择一个服务提供者的负载平衡软件程序的存根模块。

根据本发明的另一个方面，存根模块含有从多个服务提供者中删除一个发生了故障的服务提供者的故障处理软件部分。

根据本发明的另一个方面，负载平衡软件部分基于对一个特定服务提供者的亲缘关系(affinity)选择一个服务提供者。

根据本发明的另一个方面，负载平衡软件部分以循环(round robin)方式选择服务提供者。

根据本发明的另一个方面，负载平衡软件部分以随机方式选择服务提供者。

根据本发明的另一个方面，负载平衡软件部分根据每个服务提供者的负载从多个服务提供者中选择一个服务提供者。

根据本发明的另一个方面，负载平衡软件部分根据所请求的数据类型从多个服务提供者中选择一个服务提供者。

根据本发明的另一个方面，负载平衡软件部分根据物理上最接近的服务提供者从多个服务提供者中选择一个服务提供者。

根据本发明的另一个方面，负载平衡软件部分根据每个服务提供者响应的时间周期从多个服务提供者中选择一个服务提供者。

根据本发明的另一个方面，该制品包含第一组数字信息，包括从多个服务提供者中选择一个服务提供者的Enterprise Java^TM Bean对象。

根据本发明的另一个方面，存根模块存储在分布式处理系统中的处理设备中。存根模块包括由下列步骤组成的方法：获取服务提供者列表，和从该服务提供者列表中选择一个服务提供者。

根据本发明的另一个方面，该方法还包括从服务提供者列表中删除发生故障的服务提供者。

根据本发明的另一个方面，一种设备包括与第一处理设备和第二处理设备连接的通信媒体。第一处理设备存储命名树，该命名树包括用于访问服务提供者的远程方法调用(“RMI”)存根模块。第二处理设备含有复制的命名树和服务提供者。

根据本发明的另一个方面，命名树含有包括当前服务提供者的服务库的节点。

根据本发明的另一个方面，服务库包括存根模块(stub)。

根据本发明的另一个方面，分布式处理系统包括与第二计算机连接的第一计算机。第一计算机含有命名树，包括访问服务提供者的远程调用存根模块。第二计算机含有复制的命名树和服务提供者。

根据本发明的另一个方面，提供了包括与第二处理设备连接的第一处理设备的分布式处理系统。第一处理设备具有JVM和包括第一RJVM的第一核心软件层。第二处理设备具有第一JVM和包括第二RJVM的第一核心软件层。当在第一JVM和第二JVM之间没有可用的接头时，可以将消息从第一处理设备传送到第二处理设备。

根据本发明的另一个方面，第一处理设备在防火墙之后，在小应用程序(applet)安全模型下运行，或者是一个客户机，和第二处理设备也是一个客户机。

通过参照随后的附图、详细说明和权利要求书，可以看出本发明的其它特征和优点。

附图简述

图1a表示现有技术的客户机/服务器结构；

图1b表示现有技术的Java^TM企业API；

图1c表示多层结构；

图2a表示现有技术的对等结构；

图2b表示现有技术的事务处理结构；

图3a表示本发明实施例的简化软件方块图；

图3b表示图3a所示的核心模块的简化软件方块图；

图3c表示集团型(clustered)企业Java^TM结构；

图4表示集团型企业Java^TM命名服务结构；

图5a表示智能存根模块(smart stub)结构；

图5b表示EJB对象结构；

图6a是说明负载平衡方法的控制流程图；

图6b-g是说明负载平衡方法的控制流程图；

图7是说明故障处理方法的的控制流程图；

图8表示在图3-5所示的集团型企业Java^TM结构中客户机/服务器的硬件和软件部分。

通过参照附图和如下的详细说明，可以更好地理解本发明。在附图中，相同的标号表示相同的部分。

详细说明

I.集团型企业Java^TM分布式处理系统

A.集团型企业Java^TM软件结构

图3a示出了根据本发明实施例的、在集团型企业Java^TM系统的处理设备中的软件层的简化方块图380。下面描述集团型企业Java^TM分布式处理系统的详细说明。软件的第一层包括通信媒体软件驱动器351，用于传送和接收在诸如以太网局域网之类的通信媒体上的信息。包括传输控制协议(“TCP”)软件部分353和因特网(“IP”)软件部分352的操作系统310是以特定格式检索提取和发送信息包或信息块的上层软件层。“上层”软件层一般定义为一个利用或访问一个或多个“下层”软件层的软件部分或几个软件部分。接着，实现JVM 354。然后，将含有远程Java^TM虚拟机356的核心模块层355放置在JVM 354的上面。下面要详述的核心模块355用于在集团型企业Java^TM分布式处理系统中的处理设备之间传送消息。远程方法调用357和企业Java^TM豆模块(bean)358是核心模块355的上层软件层。EJB 358是用于各种Java^TM应用程序的容器。

图3b表示图3a所示的核心模块355的细节图。核心模块355包括接头管理器部分363、线程管理器部分364、和RJVM 356。RJVM 356是包括消息择径软件部分360、含有简表161c的消息压缩软件部分361、和对等消失检测软件部分362的数据结构。RJVM 356和线程管理器部分364与接头管理器部分363交互操作以在处理设备之间传输信息。

B.分布式处理系统

图3表示集团型企业Java^TM分布式处理系统300的简化方块图。处理设备与通信媒体301连接。通信媒体301可以是有线和/或无线的通信媒体，或它们的组合。在一个实施例中，通信媒体301是局域网(LAN)。在另一个实施例中，通信媒体301是广域网(WAN)，例如，因特网或万维网(WWW)。再在另一个实施例中，通信媒体301是LAN和WAN两者。

各种不同类型的处理设备都可以与通信媒体301连接。在一个实施例中，处理设备可以是如下所述的、如图8所示的通用计算机100。本领域的普通技术人员应该理解，图8和下列说明仅描述了一种特定类型的处理设备，而按照本发明的实施例可以使用带有不同软件和硬件配置的许多其它类型的处理设备。在另一个实施例中，处理设备可以是打印机、手持式计算机、膝上型计算机、扫描仪、蜂窝式电话、寻呼机、或它们的等效物。

图3c表示本发明中服务器302和303与通信媒体301连接的实施例。服务器303还与通信媒体305连接，通信媒体305可以具有与上面针对通信媒体301所述相似的实施例。客户机304也与通信媒体305连接。在另一个实施例中，客户机304可以如图3中虚线和方块所示的那样与通信媒体301连接。应该理解为，在另一个实施例中，服务器302是(1)客户机和服务器两者、或(2)客户机。类似地，图3表示了其中表示三个处理设备的实施例，而本发明的其它实施例包括了如省略号所示的许多其它处理设备或通信媒体。

服务器302分别利用网络软件302a和网络软件303a将通信媒体301上的信息传输到服务器303。在一个实施例中，网络软件302a、303a、和304a包括通信媒体软件驱动器351、传输控制协议软件353和因特网协议软件352(“TCP/IP”)。客户机304还包括网络软件304a，用于通过通信媒体305将信息传输到服务器303。服务器303中的网络软件303a还用于通过通信媒体305将信息传输到客户机304。

根据本发明的实施例，集团型企业Java^TM结构300中的每个处理设备都包括支持多层和对等功能两者的消息传递核心模块355。核心模块是用于向处理设备上的其它软件程序提供基本服务的软件程序。

具体地说，服务器302、服务器303、和客户机304分别含有核心模块302b、303b、和304b。具体地，为了使两个JVM交互操作，无论它们是客户机还是服务器，每个JVM都构造代表另一个的RJVM。消息从一侧上的上层发出，通过相应的RJVM，跨过通信媒体，再通过对等的RJVM，最后被传送到另一侧上的上层。在各种实施例中，消息可以利用各种不同的协议传输，包括(但不限于)：Transmission Control Protocol/Internet Protocol(“TCP/IP”)、Secure Sockets Layer(“SSL”)、Hypertext Transport Protocol(“HTTP”)隧道技术、和Internet InterORB Protocol(“IIOP”)隧道技术、和它们的组合。RJVM和接头管理器创建和维护以这些协议为基本接头和在上层中的所有对象之间共享它们。接头(socket)是代表分布式处理系统中的处理设备之间的端点(terminal)的逻辑位置。核心模块维护执行线程库，和线程管理器软件部分364多路复用接头读取和请求执行之间的线程。线程是执行程序代码段或功能的序列。

例如，服务器302包括JVM1和Java^TM应用程序302c。服务器302还包括代表服务器303的JVM2的RJVM2。如果消息要从服务器302发送到服务器303，则消息通过服务器302中的RJVM2发送到服务器303中的RJVM1。

C.消息转发

集团型企业Java^TM网络300能够通过中间服务器转发消息。如果客户机通过前台网关从后台服务器请求服务，则这种功能是重要的。例如，来自服务器302(客户机302)的消息并具体地JVM1可以通过服务器303(前台网关)或JVM2转发到客户机304(后台服务器304)或JVM3。这种功能在控制会话集中或在服务器与各种客户机之间建立多少个连接时是重要的。

并且，消息转发可以用在在两个JVM之间不能创建接头的情况中。例如，消息的发送者正在小应用程序安全模式下运行，而这种模式不允许创建到原始服务器的接头。小应用程序安全模型的详细说明可以从http://www.javasoft.com站点上获得，将这个站点列在这里以供参考。另一个例子包括当消息的接收者处于防火墙之后时。此外，如下所述，消息转发也可以应用在发送者是客户机和接收者是客户机时，因此不接受任何输入接头。

例如，如果消息从服务器302发送到客户机304，则该消息将不得不通过服务器303择径。具体地说，将使RJVM3(代表客户机304)之间的、如302f所示的消息切换是切换到服务器302中的RJVM2(代表服务器303)。消息将利用接头302e在服务器302中的RJVM2和服务器303中的RJVM1之间传输。然后，消息按虚线303f所示的那样，从服务器303中的RJVM1切换到服务器303中的RJVM3。接着，消息将在服务器303中的RJVM3和客户机304中的RJVM2的接头之间传送。最后，消息将按虚线304f所示的那样，从客户机304中的RJVM2传送到客户机304中的RJVM1。

D.重新择径

客户机/服务器中的RJVM能够在任何时候将通信路径或通信媒体切换到其它的RJVM。例如，如果客户机304创建到服务器302的直接接头，则服务器302就能够开始使用该接头来代替通过服务器303的消息转发。这个实施例用代表客户机304的虚线和方块示出。在一个实施例中，通过RJVM传输消息的使用确保了在出现网络重新配置之后可靠有序的消息传送。例如，如果客户机304被重新配置成通信媒体301来代替图3所示的通信媒体305。在另一个实施例中，消息可以不按顺序传送。

RJVM进行几种通过路由择径(routing)实现的端到端操作。首先，RJVM负责各个客户机/服务器意外死机时的检测。在一个实施例中，如图3b所示对等消失选择软件部分362负责这种功能。在一个实施例中，当在预定时间间隔内没有发送其它消息时，RJVM将心跳(heartbeat)消息发送到其它客户机/服务器。如果客户机/服务器在预定计数时间内没有接收到心跳消息，则检测到应该发送心跳的客户机/服务器发生故障了。在一个实施例中，通过连接超时或发生故障的客户机/服务器是否在预定时间量内不发送消息来检测发生故障的客户机/服务器。在另一个实施例中，发生故障的接头指示发生故障的客户机/服务器。

其次，在消息串行化期间，各个RJVM，特别是消息压缩软件360，缩减共同传输的数据值以降低消息大小。为了实现这个目的，每个JVM/RJVM对保持匹配缩减表。例如，JVM1包括缩减表，和RJVM1包括匹配缩减表。在消息在中间服务器之间转发期间，在路由中的中间服务器上消息的主体不进行去串行化。

E.多层/对等功能

集团型企业Java^TM结构300考虑到多层和对等编程。

集团型企业Java^TM结构300支持与多层分布式处理结构一致的、用于客户机/服务器编程的显式语法。举例来说，如下的客户机方代码片段将信息消息写入服务器日志文件中：

T3Client clnt=new T3Client("t3://acme:7001");

LogServices log=clnt.getT3Services().log();

Log.info("Hello from a client");

第一行利用t3协议建立与顶级(acme)服务器会话。如果RJVM还不存在，则每个JVM构造关于另一方的RJVM，并建立底层(underlying)TCP接头。这个会话的客户机方表示-T3Client对象-和服务器方表示通过这些RJVM进行通信。服务器方支持各种各样的服务，包括数据库访问、远程文件访问、工作空间、事件和日志记录。第二行获得LogServices对象，和第三行写消息。

集团型企业Java^TM计算机结构300还支持与对等分布式处理结构一致的服务器中性的语法。举例来说，如下的代码片段从服务器上的遵从JNDI的命名服务中获得关于RMI对象的存根模块，并调用其方法之一。

Hashtable env=new Hashtable();

env.put(Context.PROVIDER_URL,"t3://acme:7001");

env.put(Context.INITIAL_CONTEXT_FACTORY,

"weblogic.jndi.WeblogicInitialContextFactory");

Context ctx=new InitialContext(env);

Example e=(Example)ctx.lookup("acme.eng.example");

result=e.example(37);

在一个实施例中，JNDI命名上下文被封装成RMI对象以实现远程访问。因此，上面代码显示了一种类型的RMI引导(bootstrap)。前四行获得顶级服务器上关于初始上下文的RMI stub。如果RJVM还不存在，则每一方都构造关于另一方的RJVM，并建立用于t3协议的底层TCP接头。调用方对象-RMI stub和被叫方对象-RMI impl-通过RJVM进行通信。第五行查找在名称acme.eng.example上的另一个RMI对象，即Example和第六行调用Example方法之一。在一个实施例中，Example impl不在与命名服务相同的处理设备上。在另一个实施例中，Example impl是在客户机上。Example对象的调用导致了适当RJVM的创建，如果它们还不存在的话。

II.知晓复制的或智能的存根模块/EJB对象

在图3c中，处理设备通过复制RMI和/或EJB对象能够向结构300中的其它处理设备提供服务。因此，结构300是易于伸缩的和容错的。通过将复制的RMI和/或EJB对象加入现有的处理设备或新附加的处理设备中，可以容易地将附加服务加入结构300中。并且，由于RMI和/或EJB对象可以通过结构300复制，因此，单个处理设备、多个处理设备、和/或通信媒体可能发生故障，但仍然不会使结构300不能工作或显著变坏。

图5a表示结构500中的知晓复制(“RA”)的或智能的存根模块580。结构500包括与通信媒体501连接的客户机504。服务器502和503分别与通信媒体501连接。永久性存储装置509分别通过通信媒体560和561与服务器502和503连接。在各种各样的实施例中，通信媒体501、560和561可以是如上所述的有线和/或无线通信媒体。类似地，在一个实施例中，客户机504、服务器502、和服务器503可以是如上所述的客户机和服务器两者。本领域的普通技术人员应该理解，在其它可替代的实施例中，多个其它服务器和客户机可以如省略号所示的那样包括在结构500中。此外，如上所述，在其它可替代的实施例中，客户机504、服务器502、和服务器503的硬件和软件配置如下面所描述的和图8所示的那样。

RA RMI存根模块580是一种能够根据负载平衡方法507和/或故障处理方法508找出几乎所有服务提供者并在它们之间切换的智能存根模块。在一个实施例中，RA存根模块580包括选择适当负载平衡方法507和/或故障处理方法507的复制处理器506。在其它可替代的实施例中，可以实施单负载平衡方法和/或单故障处理方法。在其它可替代的实施例中，复制处理器506可以包括多负载平衡方法和/或多故障处理方法以及它们的组合。在一个实施例中，复制处理器506实现如下接口：

public interface ReplicaHandler{

Object loadBalance(Object currentProvider)throws

RefreshAbortedException;

Object failOver(Object failedprovider,

RemoteException e)throws

RemoteException；

}

紧接调用一种方法之前，RA存根模块580调用负载平衡方法507，它接管当前服务器，并返回替换者。例如，客户机504可能正在利用服务器502检索数据库509a或个人存储装置509的数据。由于服务器502负担服务请求过重，因此，负载平衡方法507可以切换到服务器503。处理器506可能选择完全在调用方上的服务器替换者，也许利用关于服务器502负载的信息，或者，处理器506可以请求服务器506检索特定类型的数据。例如，处理器506可以选择特定服务器解方程，因为服务器已经提高了计算能力。在一个实施例中，复制处理器506实际上不需要在每次调用时都切换提供者，因为复制处理器506正试图使创建的连接数最少。

图6a是说明图5a-b所示的负载平衡软件507的控制流程图。应该理解，图6a是说明由负载平衡方法507中的软件完成的功能或步骤的逻辑序列的控制流程图。在其它可替代的实施例中，可以完成附加的功能或步骤。并且，在其它可替代的实施例中，硬件可以执行特定的功能或所有的功能。

负载平衡软件507从圆圈600所示的位置开始。然后，在逻辑块601中确定调用线程是否已经建立起对特定服务器的“亲缘关系”。客户机与协调它当前事务处理的服务器有亲缘关系，和服务器与它自己有亲缘关系。如果亲缘关系已建立，则将控制进到逻辑块602，否则，则控制进到逻辑块604。在逻辑块602中确定有亲缘关系的服务器是否提供所请求的服务。如果是，则将控制进到逻辑块603。否则，则控制进到逻辑块604。将有亲缘关系的服务器上的服务提供者返回给逻辑块603中的客户机。在逻辑块604中，联系命名服务并获取更新了的当前服务提供者列表。在逻辑块605中调用getNextProvider(取下一服务者)方法以获取服务提供者。getNextProvider方法的各种实施例显示在图6b-g中，下面将作详细描述。在逻辑块606中获得服务。然后，如果在逻辑块606中没有提供服务，则调用故障处理方法508，最后，负载平衡方法507从逻辑块608所示的位置退出。故障处理方法508的实施例表示在图7中，下面将作详细描述。

图6b-g示出了图6a的逻辑块605中所使用的getNextProvider方法的各种实施例。如图6b所示，getNextProvider方法以循环方式选择服务提供者。如圆圈621所示进入getNextProvider方法620。在逻辑块622中获取当前服务提供者列表。在逻辑块623中递增指针。在逻辑块624中根据指针选择下一个服务提供者，并在逻辑块625中返回新的服务提供者，最后，如圆圈626所示退出getNextProvider方法。

图6c示出了通过随机选择服务提供者来获取服务提供者的getNextProvider方法的另一种可替代实施例。如圆圈631所示进入getNextProvider方法630。如逻辑块632所示的那样获取当前服务提供者列表。如逻辑块633所示的那样随机选择下一个服务提供者，并在逻辑块634中返回新的服务提供者，最后，如圆圈635所示退出getNextProvider方法。

getNextProvider方法还有一个实施例显示在图6d中，它根据各服务提供者的负载获取服务提供者。如圆圈641所示进入getNextProvider方法640。在逻辑块642中获取当前服务提供者列表。在逻辑块643中获取每个服务提供者的负载。然后，在逻辑块644中选择负载最轻的服务提供者。最后，在逻辑块645中返回新的服务提供者，并且如圆圈646所示退出getNextProvider方法。

getNextProvider方法的再一个可替代的实施例显示在图6e中，它根据从服务提供者获得的数据类型获取服务提供者。如圆圈651所示进入getNextProvider方法650。在逻辑块652中获取当前服务提供者列表。在逻辑块653中确定从服务提供者请求的数据的类型。然后，在逻辑块654中根据数据类型选择负载服务提供者。最后，在逻辑块655中返回新的服务提供者，并且如圆圈656所示退出getNextProvider方法。

getNextProvider方法的再一个实施例表示在图6f中，它根据服务提供者物理位置选择服务提供者。如圆圈661所示进入getNextProvider方法660。在逻辑块662中获取当前服务提供者列表。在逻辑块663中确定到每个服务提供者的物理距离，和在逻辑块664中选择到正在请求的客户机的物理距离最近的服务提供者。最后，在逻辑块665中返回新的服务提供者，并且如圆圈666所示退出getNextProvider方法660。

getNextProvider方法的还在一个的实施例显示在图6g中，它根据服务提供者响应以前的请求所花费的时间量选择服务提供者。如圆圈671所示进入getNextProvider方法670的控制。在逻辑块672中获取当前服务提供者列表。在逻辑块673中确定每个服务提供者响应特定消息的时间间隔。然后，在逻辑块674中选择以最短时间间隔响应的服务提供者。最后，在逻辑块675中返回新的服务提供者，并且如圆圈676所示退出来自getNextProvider方法的控制。

如果服务方法的调用以保证重试这样的方式出故障，则RA存根模块580调用故障处理方法508，它接管发生故障的服务器和提示是什么故障的异常，并返回一重试用的新服务器。如果新服务器不适用，则RA存根模块580报告异常。

图7是说明图5a-b所示的故障处理软件508的控制流程图。如圆圈700所示进入故障处理方法508。在逻辑块701从服务的当前提供者列表中删除发生故障的提供者。然后，调用getNextProvider方法以便获取服务提供者。最后，在逻辑块703中返回新的服务提供者，和如圆圈704所示退出故障处理方法508。

虽然图6-7表示复制处理器506的实施例，但其它可替代的实施例还包括以循环方式实现的如下功能或它们的组合。

首先，要维护服务的服务器或服务提供者的列表。每当列表需要使用和列表最近没有被更新时，处理器506就联系如下所述的命名服务并获取提供者的最新列表。

其次，如果处理器506打算从列表中选择提供者和存在到主服务器的现存的RJVM级连接，该主服务器在最后的心跳周期未接收到消息，则处理器506跳过该提供者。在一个实施例中，由于对等的消失是在几个这样的心跳间隔之后确定的，因此，服务器可以在以后恢复。这样，就可以获取基于服务器负载的负载平衡。

第三，当提供者发生故障时，处理器506从列表中删除该提供考。这样就避免了重复尝试使用不工作的服务提供者所引起的延迟。

第四，如果服务正在从作为服务的提供者的宿主的服务器调用的，那么就使用该提供者。这有利于链式调用服务的提供者的共置托管(co-location)。

第五，如果服务正在在事务处理的范围内被调用和起事务处理协调者作用的服务器作为服务的提供者的宿主，那么就使用该提供者。这有利于在事务处理范围内的提供者的共置托管。

能够在方法调用期间发生的故障可以分类成：(1)与应用程序有关的、或(2)与基础设施有关的。在发生与应用程序有关的故障的情况下，RA存根模块580将不重试操作，因为不能期望改善这种情况。在发生与基础设施有关的故障的情况下，RA存根模块580也许能够，或也许不能够可靠地重试操作。一些初始非幂等操作，例如递增数据库中字段的值，可能完成。在一个实施例中，只有当(1)用户已经声明服务方法是幂等的，或者(2)系统可以确定请求的处理从未开始。作为后者的一个例子，如果作为负载平衡方法的一部分，存根模块580切换到其宿主已经发生故障的服务提供者，RA存根模块580将重试。作为另一个例子，RA存根模块580得到对事务处理操作的否定确认，则RA存根模块580将重试。

RMI编译器识别命令该编译器生成用于对象的RA存根模块的特殊标志。附加的标志可以用于规定服务方法是幂等的(idempotent)。在一个实施例中，RA存根模块580将利用如上所述的和图5a所示的复制处理器。附加的标志可以用于规定不同的处理器。另外，在服务被布置的点上，即被结合在如下所述的集团型命名服务的点上，处理器可以被取代。

图5b表示本发明的另一个实施例，其中EJB对象551用于取代图5a所示的存根模块。

III.复制的遵从JNDI的命令服务

如图4所示，对结构400中的服务提供者的访问是通过遵从JNDI的命名服务获得的，在整个结构400中复制遵从JNDI的命令服务，使得不存在任何单个故障点。因此，如果提供遵从JNDI的命名服务的处理设备发生了故障，则可以使用具有复制的命名服务的另一个处理设备。为了提供服务的示例，服务器在复制命名树中的特定节点上通告服务的提供者。在一个实施例中，每个服务器将用于提供者的RA存根模块附加到存储在命名树的服务器备份中的节点上的兼容服务库。如果新提供(offer)的类型与现有库中提供的类型不兼容，则使新提供暂停，并通过ConflictHandler接口作出往调用(callback)。在撤消任一种类型的提供之后，另一种提供将最终被装在每一处。当客户机查找服务时，客户机获取联系服务库的RA存根模块以刷新服务提供者的客户机列表。

图4表示结构400中复制的命名服务。在一个实施例中，服务器302和303分别提供示例的服务提供者P1和P2，并且分别拥有命名服务树402和403的复制品。命名服务树402和403中的节点acme.eng.example分别拥有服务库402a和403a，包含到Example服务提供者P1和P2的参考点。客户机304通过在acme.eng.example节点上进行命名服务查找获取RA存根模块304e。存根模块304e联系服务库的示例以获取到可用服务提供者的参考点的当前列表。存根模块304e可以按负载平衡和故障处理的需要在服务库的示例之间切换。

关于命名服务的初始上下文的存根模块是知晓复制的或智能的存根模块，它最初作命名服务提供者之间的负载平衡，并在发生故障的情况下进行切换。命名服务树的每个示例包含当前命名服务提供者的完整列表。存根模块从当前正在使用的示例中获取刷新列表。为了引导这个处理，系统使用Domain Naming Service(域名命名服务)(“DNS”)以找出示例的(可能不完整的)初始列表和从它们之一中获取完整列表。举例来说，可以按如下获取关于于命名服务的初始上下文的存根模块：

Hashtable env=new Hashtable();

env.put(Context.PROVIDER_URL,“t3://acmeCluster:7001”);

env.put(Context.INITIAL_CONTEXT_FACTORY,

“weblogic.jndi.WebLogiclnitialContextFactor”);

Context ctx=new InitialContext(env);

结构中的一些分组服务器已经被约束在名称acmeCluster下的DNS中。并且，应用程序仍然能够规定各个服务器的地址，但是，当应用程序首先试图获取存根模块时，应用程序将存在单个故障点。

可靠的多点传送协议是所期望的。在一个实施例中，通过IP多点传送或点到点协议分配提供者存根，并创建复制的命名树。在IP多点传送实施例中，有三种类型的消息：Heartbeat、Announcement(通知)、StateDump(状态转储)。Heartbeat用于在服务器之间传输信息，和通过它们的存在与否，识别发生故障的服务器。Announcement包含一组服务的提供和撤消。来自每个服务器的Announcement按顺序编号。每个接收器处理Announcement以便识别丢失的Announcement。每个服务器在它的Heartbeat中包括已经发送的最后一个Announcement的序号。关于丢失的Announcement的NegativeAcknowledgement(“NAK”，否认)包括在随后输出的Heartbeat中。为了处理NAK，每个服务器都保留服务器已经发送的最后几个Announcement的列表。如果关于Announcement已经被删除的NAK到达，服务器就发送StateDump，它包含服务器的服务的完整列表和它下一个Announcement的序号。当新服务器加入到现有的结构中时，新服务器NAK(否认)来自每个其它服务器的第一消息，这导致StateDump被发送。如果服务器在预定时间间隔之后没有从另一个服务器接收到心跳(Heartbeat)，则服务器撤消由没有产生心跳(Heartbeat)的服务器提供的所有服务。

IV.编程模型

用在图3-5所示的结构中的应用程序随要处理应用程序状态的方式而定使用三种基本编程模型之一：(1)无状态的或直接的、(2)无状态工厂(stateless factory)的或间接的、或(3)有状态的或有目标的。在无状态模型中，通过命名服务查查找表返回的智能存根模块直接参考服务提供者。

Examplee=(Example)ctx.lookup(“acme.eng.example”);

result1=e.example(37);

result2=e.example(38);

在该例中，由于为了负载平衡，智能存根模块能够在不同的服务提供者之间切换，因此，对实例的两种调用可以由不同的服务提供者来处理。因此，Example服务对象不能够代表应用程序在内部存储信息。通常，只有当提供者无状态时，才使用无状态模型。举例来说，纯粹无状态提供者可以计算其变元的一些数学函数，并返回结果。无状态提供者可以为它们自己存储信息，例如为了财会的目的。更重要的是，无状态提供者可以访问底层的永久性存储器，和根据需要将应用程序的状态装入存储器中。例如，为了使实例返回作为变元进入其中的所有值的运行和。该实例可以从数据库中读取以前的和，加入它的当前的变元中，写出新的值，然后将其返回。这种无状态服务模型提高了规模可伸缩性。

在无状态工厂编程模型中，通过查找返回的智能存根模块是创建其自身不是智能存根模块的所需服务提供者的工厂。

ExampleFactory gf=(ExampleFactory)

ctx.lookup(“acme.eng.example”);

Example e=gf.create();

result1=e.example(37);

result2=e.example(38);

在该例中，确保对实例的两种调用由同一服务提供者来处理。因此，服务提供者可以代表应用程序可靠地存储信息。无状态工厂模型应该应用在调用者需要与提供者进行“对话”时，例如，调用者和提供者可以进行往复协商。知晓复制的存根模块一般与无状态和无状态工厂模型中的相同。唯一不同之处在于存根模块是涉及服务提供者，还是涉及服务提供者工厂。

提供者工厂存根模块在努力创建提供者的过程中可以随意地进行故障处理，因为这种操作是幂等的。为了进一步提高间接服务的可用性，应用程序代码必须包含围绕服务创建和调用的显式重试循环。

while(true){

  try{

     Example e=gf.create();

     result1=e.example(37);

     result2=e.example(38);

     break;

}catch(Exception e){
     if(!retryWarranred(e))

         throw e;
				
				<dp n="d20"/>
    }

}

这将会，例如，处理由工厂成功创建的提供者e的故障。在这种情况下，应用程序代码应该确定是否完成非幂等操作。为了进一步提高适用性，应用程序代码可以尝试取消这样的操作并重试。

在有状态编程模型中，服务提供者是由一些唯一系统级关键字标识的长寿命、有状态对象。可以利用这种模型访问的“实体”的例子包括远程文件系统和数据库表中的行。目标提供者可以由许多客户机访问许多次，这与每个提供者只由一个客户机使用一次的其它两种模型不同。用于目标提供者的存根模块可以通过关键字只不过是命名服务名称的直接查找表，或通过关键字包括对创建操作的变元的工厂两者之一获取。在每一种情况中，存根模块将不作负载平衡或故障处理。即使作的话，重试必须再次显式地获取存根模块。

在EJB中存在三种类型的豆模块，其中的每一种映射到三种编程模型之一。无状态会话豆模块(bean)是为特定调用者创建的，但在调用之间不保持内部状态。无状态会话豆模块映射到无状态模型。有状态会话豆模块是为特定调用者创建的，并在调用之间保持内部状态。有状态会话豆模块映射到无状态工厂模型。实体豆模块是由全系统关键字标识的奇异的、有状态对象。实体豆模块映射到有状态模型。所有三种类型的豆模块都由称为EJB家庭(home)的工厂创建的。在一个实施例中，它们创建的EJB家庭和豆模块两者都用RMI标记。在图3-5所示的结构中，用于EJB家庭的存根模块是智能存根模块。用于无状态会话豆模块的存根模块是智能存根模块，而用于有状态会话豆模块和实体豆模块的存根模块则不是。用于基于EJB的服务的复制处理器可以在它的布置(deplotment)描述符中规定。

为了创建间接的、基于RMI的服务，这是当对象要为调用者保持状态时所需要的，应用程序代码必须显式地构建工厂。有目标的、基于RMI的服务可以通过无需任何特殊标志地运行RMI编译器，然后将所得的服务结合到所复制的命名树中来创建。用于对象的存根模块将直接结合到命名树的每个示例中和将不创建任何服务库。这样就提供了关键字是命名服务名称的有目标服务。在一个实施例中，这用于创建远程文件系统。

V.硬件和软件部分

图8表示图3-5所示的示例性服务器和/或客户机的硬件和软件部分。图8的系统包括通用计算机800，它通过诸如连接829之类的一个或多个通信媒体与LAN 840，并且也与在这里如因特网880所示的WAN相连接。通过LAN840，计算机800可以与诸如文件服务器841之类的其它本地计算机通信。在一个实施例中，文件服务器841是如图3所示的服务器303。通过因特网880，计算机800可以与诸如万维网服务器881之类的、本地的和远程的其它计算机通信。在一个实施例中，万维网服务器881是如图3所示的服务器303。应该理解，从计算机800到因特网880的连接可以通过各种各样的方式实现，例如，直接通过连接829，通过局域网840，或通过调制解调器(图中未示出)。

计算机800是个人或办公用计算机，它们可以是，例如，工作站、个人计算机、或其它单用户或多用户系统；一个示例性的实施例使用了SunSPARC-20工作站(Sun Microsystems，Inc.，Mountain View，CA)。为了便于说明，可以将计算机800方便地划分成硬件部分801和软件部分802；但是，本领域的普通技术人员应该理解，这种划分是概念性的，并且多少有些随意性，在硬件和软件之间的界线也不是严格的。此外，应该理解，在主计算机与它的附属外设之间的界线也不是严格的，尤其是，被认为是一些计算机的外设的部分也可以被认为是其它计算机的整体部分。因此，例如，用户I/O 820可以包括键盘、鼠标、和显示监视器，它们的每一种既可以被认为是外围设备，也可以被认为是计算机本身的一部分，用户I/O 820还可以包括通常被认为是外设的本机打印机。作为另一个例子，永久性存储器808可以包括CD-ROM(光盘只读存储器)单元，它既可以是外设，也可以内置在计算机中。

硬件部分801包括处理器(CPU)805、存储器806、永久性存储器件808、用户I/O 820、和网络接口825，它们都与总线810连接。这些部分都是本领域的普通技术人员所熟知的，因此，只需作简要说明。

处理器805可以是，例如，微处理器、或为了多重处理而构成的微处理器的集合。

存储器806可以包括只读存储器(ROM)、随机访问存储器(RAM)、虚拟存储器、或其它存储技术，它们既可以是单个形式，也可以是组合形式。永久性存储器件808可以包括，例如，硬磁盘、软磁盘、或其它永久性读-写数据存储技术，它们既可以是单个形式，也可以是组合形式。它还可以包括大型或归档存储器件，例如可以通过CD-ROM或其它大容量存储技术提供的那种。(请注意，文件服务器841提供了处理器805可以利用的附加存储能力。)

用户I/O(输入/输出)硬件820通常包括诸如CRT或平板显示器之类的视频显示监视器、字母数字式键盘、和鼠标或其它点击设备，可选地，还可以包括打印机、光学扫描仪，或供用户输入输出用的其它设备。

网络I/O硬件825提供了计算机800和外界的接口。更明确地说，网络I/O硬件825让处理器805通过连接829与通过LAN 840和因特网880的其它处理器和设备通信。

软件部分802包括操作系统850和在操作系统310控制下的一组任务，例如，Java^TM应用程序860、和重要的是，JVM软件354和核心模块355。操作系统310还让处理器805控制诸如永久性存储器件808、用户I/O 820、和网络接口825之类的各种设备。处理器805与存储器806和计算机系统800的其它部分相联系执行操作系统310、应用860、JVM 354、和核心355的软件。在一个实施例中，软件802包括如图3c的服务器302中所示的网络软件302a、JVM1、RJVM2和RJVM3。在一个实施例中，Java^TM应用程序860是如图3c所示的Java^TM应用程序302c。

本领域的普通技术人员应该理解，图8的系统的意图是用于举例说明的，而不是用于限制的，各种各样计算、通信、和信息设备都可以用来取代或附加到图8所表示的设备上。例如，通过因特网880的连接一般涉及通过中间路由器计算机(未示出)的分组交换，和计算机800在典型的万维网客户机会话期间可能访问任何数量的万维网服务器，包括，但决不仅限于，计算机800和万维网服务器881。

上述对本发明优选实施例的说明是为了图示和描述的目的而提供的。它不是穷举的，或将本发明限制在所公开的精确形式上。显然，各种改进和变动对于本领域的普通技术人员来说是显而易见的。选择和描述实施例是为了最佳地解释本发明的原理和它的实际应用，从而使本领域的其它普通技术人员能够理解有关各种实施例的和包括适用于所设想的特定用途的各种改进在内的本发明。应采用下列权利要求和它们的等效物来限定本发明的范围。

Claims

1.一种用于在簇中的处理设备之间的通信的系统，包括：

第一处理设备，具有在其上执行的第一虚拟机、包括存根的第一远程方法调用层、传输层、以及第一核心，所述第一核心包括对应于在第二处理设备执行的第二虚拟机的第一消息数据结构，其中所述第一消息数据结构包括第一消息路由软件部分和第一消息压缩软件部分；

第二处理设备，具有在其上执行的所述第二虚拟机、包括构架的第二远程方法调用层、传输层、以及第二核心，所述第二核心包括对应于在所述第一处理设备执行的第一虚拟机的第二消息数据结构，其中所述第二消息数据结构包括第二消息路由软件部分和第二消息压缩软件部分；以及

其中，经由所述第一处理设备上的第一消息数据结构、传输层和所述第二处理设备上的第二消息数据结构，使用相应的消息路由软件部分和消息压缩软件部分，将消息从所述第一远程方法调用层中的存根传送到所述第二远程方法调用层中的构架。

2.如权利要求1所述的系统，其中所述第一虚拟机是第一Java虚拟机，所述第一消息数据结构是第一远程Java虚拟机，并且其中第二虚拟机是第二Java虚拟机，并且所述第二消息数据结构是第二远程Java虚拟机。

3.一种用于在簇中的处理设备之间的通信的系统，包括：

第一处理设备，具有在其上执行的第一虚拟机、第一远程方法调用层、以及第一核心，所述第一核心包括对应于在第二处理设备执行的第二虚拟机的第一消息路由数据结构；

第二处理设备，具有在其上执行的所述第二虚拟机、第二远程方法调用层、以及第二核心，所述第二核心包括对应于在所述第一处理设备执行的第一虚拟机的第二消息路由数据结构，和对应于在第三处理设备执行的第三虚拟机的第三消息路由数据结构；

第三处理设备，具有在其上执行的所述第三虚拟机、第三远程方法调用层、以及第三核心，所述第三核心包括对应于在所述第二处理设备执行的第二虚拟机的第四消息路由数据结构；以及

其中，经由所述第一处理设备上的第一消息路由数据结构、所述第二处理设备上的第二消息路由数据结构、所述第二处理设备上的第三消息路由数据结构、以及所述第三处理设备上的第四消息路由数据结构，将消息从所述第一远程方法调用层传送到所述第三远程方法调用层。

4.如权利要求3所述的系统，其中所述第一虚拟机是第一Java虚拟机，所述第一消息路由数据结构是第一路由Java虚拟机，并且其中第二虚拟机是第二Java虚拟机，所述第二消息路由数据结构是第二远程Java虚拟机，并且其中所述第三虚拟机是第三Java虚拟机，所述第三消息路由数据结构是第三远程Java虚拟机，并且第四消息路由数据结构是第四远程Java虚拟机。

5.一种用于在簇中的处理设备之间的通信的方法，包括步骤：

提供第一处理设备，所述第一处理设备具有在其上执行的第一虚拟机、第一远程方法调用层、以及第一核心，所述第一核心包括对应于在第二处理设备执行的第二虚拟机的第一消息数据结构，其中所述第一消息数据结构包括第一消息路由软件部分和第一消息压缩软件部分；

提供第二处理设备，所述第二处理设备具有在其上执行的所述第二虚拟机、第二远程方法调用层、以及第二核心，所述第二核心包括对应于在所述第一处理设备执行的第一虚拟机的第二消息数据结构，其中所述第二消息数据结构包括第二消息路由软件部分和第二消息压缩软件部分；以及

经由所述第一处理设备上的第一消息数据结构和所述第二处理设备上的第二消息数据结构，使用相应的消息路由软件部分和消息压缩软件部分，将消息从所述第一远程方法调用层传送到所述第二远程方法调用层。

6.如权利要求5所述的方法，其中所述第一虚拟机是第一Java虚拟机，所述第一消息路由数据结构是第一远程Java虚拟机，并且其中第二虚拟机是第二Java虚拟机，所述第二消息路由数据结构是第二远程Java虚拟机。

7.一种用于在簇中的处理设备之间的通信的方法，包括步骤：

提供第一处理设备，所述第一处理设备具有在其上执行的第一虚拟机、第一远程方法调用层、以及第一核心，所述第一核心包括对应于在第二处理设备执行的第二虚拟机的第一消息路由数据结构；

提供第二处理设备，所述第二处理设备具有在其上执行的所述第二虚拟机、第二远程方法调用层、以及第二核心，所述第二核心包括对应于在所述第一处理设备执行的第一虚拟机的第二消息路由数据结构，和对应于在第三处理设备执行的第三虚拟机的第三消息路由数据结构；

提供第三处理设备，所述第三处理设备具有在其上执行的所述第三虚拟机、第三远程方法调用层、以及第三核心，所述第三核心包括对应于在所述第二处理设备执行的第二虚拟机的第四消息路由数据结构；以及

8.如权利要求1所述的系统，其中所述第一消息数据结构还包括第一对等消失检测软件部分，用于检测第二虚拟机是否有效。

9.如权利要求5所述的方法，其中所述第一消息数据结构还包括第一对等消失检测软件部分，用于检测第二虚拟机是否有效。

10.如权利要求8所述的系统，其中所述第二消息数据结构还包括第二对等消失检测软件部分，用于检测第一虚拟机是否有效。

11.如权利要求9所述的方法，其中所述第二消息数据结构还包括第二对等消失检测软件部分，用于检测第一虚拟机是否有效。

12.如权利要求1所述的系统，其中所述第一消息数据结构还包括第一对等消失检测软件部分，用于检测第二处理设备是否有效。

13.如权利要求5所述的方法，其中所述第一消息数据结构还包括第一对等消失检测软件部分，用于检测第二处理设备是否有效。

14.一种用于在簇中的处理设备之间的通信的系统，包括：

第一处理设备，具有在其上执行的第一虚拟机、第一远程方法调用层、以及第一核心，所述第一核心包括对应于在第二处理设备执行的第二虚拟机的第一消息数据结构，其中所述第一消息数据结构包括第一消息路由软件部分和对等消失检测软件部分；

第二处理设备，具有在其上执行的所述第二虚拟机、第二远程方法调用层、以及第二核心，所述第二核心包括对应于在所述第一处理设备执行的第一虚拟机的第二消息数据结构，其中所述第二消息数据结构包括第二消息路由软件部分和第二对等消失检测软件部分；以及

其中，经由所述第一处理设备上的第一消息数据结构和所述第二处理设备上的第二消息数据结构，使用相应的消息路由软件部分和对等消失检测软件部分，将消息从所述第一远程方法调用层传送到所述第二远程方法调用层。

15.如权利要求7所述的系统，其中所述第一、第二、第三和第四消息路由数据结构中的每个还包括对等消失检测软件部分。