用于在事务中间件机器环境中支持隐式版本控制的系统和方法

版权声明

本专利申请的公开的一部分包含受到版权保护的材料。因为其出 现在专利商标局的专利文献或记录中，版权所有者不反对任何人对该 专利申请或专利公开的复制，但在其它方面保留所有的版权。

技术领域

本发明总体上涉及计算机系统和软件，并且特别涉及支持事务中 间件机器环境。

背景技术

利用企业IT架构提供各种服务的业务系统可能涉及许多复杂的 阶段。这些业务系统可能需要应对多种情形，比如为末端用户改变服 务合约，为新顾客提供新的服务合约，在不间断(non-stop)模式下 将早前服务升级到新服务，以及对于一些现有顾客保持更早前的服务。 此外，IT服务提供者可能希望并行地提供几个版本的服务，并且为特 定顾客提供特定变型。此外，一些服务请求者可能希望按照统一的方 式访问不同版本的服务，或者甚至在运行时间在不同版本的服务之间 进行切换，而其他人则可能不希望显式地应对不同服务版本。这正是 本发明的实施例所意图解决的一般领域。

发明内容

这里描述了用于在事务中间件机器环境中支持应用版本控制的系 统和方法。事务服务提供者可以调遣与多个服务版本相关联的至少一 项服务。所述系统可以将一项或多项应用划分成一个或多个应用区块， 其中每一个所述应用区块与所述至少一项服务的特定请求版本相关 联。随后，事务服务提供者允许所述请求区块中的服务请求者访问具 有与所述应用区块相关联的服务版本的所述至少一项服务。

在本发明的一个示例性实施例中，一种用于在事务中间件机器环 境中支持应用版本控制的系统包括事务服务提供者。所述事务服务提 供者包括：用以调遣与多个服务版本相关联的至少一项服务的调遣单 元；用以将一项或多项应用划分成一个或多个应用区块的划分器，其 中每一个所述应用区块与所述至少一项服务的特定请求版本相关联； 以及允许所述应用区块中的服务请求者访问具有与所述应用区块相关 联的服务版本的所述至少一项服务的访问单元。

在另一个实施例中，事务服务提供者还可以包括基于事务服务应 用配置确定对应于服务请求的服务版本的确定单元。

在另一个实施例中，事务服务提供者还可以包括适于从远程服务 接收针对所述至少一项服务的服务请求的接收单元。

附图说明

图1示出了根据本发明的一个实施例的在事务中间件机器环境中 支持应用服务版本控制的图示。

图2示出了根据本发明的一个实施例的在事务中间件机器环境中 支持隐式版本控制的图示。

图3示出了根据本发明的一个实施例的用于在事务中间件机器环 境中支持隐式版本控制的示例性流程图。

图4示出了根据本发明的一个实施例的在事务中间件机器环境中 支持版本情境的图示。

图5示出了根据本发明的一个实施例的支持布置在多进程(MP) 环境中的Tuxedo应用的图示。

图6示出了根据本发明的一个实施例的在事务中间件机器环境中 支持基于版本的路由(VBR)的图示。

图7示出了根据本发明的一个实施例的对应于在分布式事务中间 件机器环境中支持基于版本的路由(VBR)的示例性序列图。

图8示出了根据本发明的一个实施例的对应于在事务中间件机器 环境中支持基于版本的路由(VBR)的示例性流程图。

图9示出了根据一些实施例的事务服务提供者的功能方框图。

图10示出了根据本发明的一个实施例的事务服务提供者的示例 性方框图。

具体实施方式

在附图中作为举例而非限制示出了本发明，其中相同的附图标记 表示类似的元件。应当提到的是，在本公开内容提到“一个”或“一 些”实施例时不一定是指相同的实施例，而是意味着至少一个。

在这里描述了一种用于提供中间件机器或类似的平台的系统和方 法。根据本发明的一个实施例，所述系统包括高性能平台(例如64 位处理器技术)、高性能大存储器以及冗余InfiniBand和以太网联网 连同应用服务器或中间件环境(比如WebLogic套装)的组合，以便提 供包括大规模并行内存中网格的完整的Jave EE应用服务器综合体， 其可以被快速准备并且可以按需伸缩。根据一个实施例，所述系统可 以被布置成全机架、半机架或四分之一机架或者其他配置，其提供应 用服务器网格、存储区域网络以及InfiniBand(IB)网络。中间件机 器软件可以提供应用服务器、中间件和其他功能，比如WebLogic服务 器、JRockit或Hotspot JVM、Oracle Linux或Solaris以及Oracle  VM。根据一个实施例，所述系统可以包括经由IB网络与彼此通信的多 个计算机节点、IB交换机网关以及存储节点或单元。当被实施为机架 配置时，所述机架的未被使用的部分可以被留空或者由填充件占据。

根据本发明的一个实施例，在这里被称作“Sun Oracle Exalogic” 或“Exalogic”的系统是一种用于托管中间件或应用服务器软件(比 如Oracle中间件SW套装或WebLogic)的易于布置的解决方案。正如 这里所描述的那样，根据一个实施例，所述系统是一个“箱中网格(grid  in a box)”，其包括一个或多个服务器、存储单元、用于存储联网 的IB结构以及托管中间件应用所需的所有其他组件。通过利用例如真 实应用集群(Real Application Clusters)和Exalogic开放存储的 大规模并行网格架构，可以对于所有类型的中间件应用给出卓越的性 能。所述系统利用线性I/O可伸缩性给出改进的性能，其易于使用和 管理，并且给出关键任务可用性和可靠性。

根据本发明的一个实施例，Tuxedo是用于C、C++和COBOL的事务 处理系统或者面向事务的中间件或企业应用服务器。其是允许构造、 执行和管理高性能、分布式业务应用的软件模块集合，并且已被多种 多层应用布置工具用作事务中间件。此外，一种事务中间件系统(比 如Tuxedo系统)可以利用具有多个处理器的快速机器(比如Exalogic 中间件机器)和高性能网络连接(比如InfiniBand(IB)网络)。

后面对于本发明的描述将Tuxedo系统用作事务处理系统的一个 实例。本领域技术人员将认识到，在不做限制的情况下可以使用其他 类型的事务处理系统。

应用服务版本控制

根据本发明的一个实施例，事务中间件机器环境可以支持服务版 本控制，以便减少客户端和服务器开发努力。事务服务提供者(例如 Tuxedo)可以根据服务名称和服务所支持的版本调遣不同的服务。此 外，服务请求者(例如请求事务服务的客户端或服务器/服务)只能访 问支持相应版本的服务入口(service entry)。

图1示出了根据本发明的一个实施例的在事务中间件机器环境中 支持应用服务版本控制的图示。如图1中所示，事务中间件机器环境 100中的事务服务提供者119可以提供多种服务，比如事务服务A-B  111-112。事务服务A 111可以包括多个服务入口，例如版本I-III  121-123，事务服务B 112也可以包括多个服务入口，例如版本I-II  131-132。

此外，事务中间件机器环境100中的服务版本控制可以涉及不同 的人，比如客户端应用的开发者(例如客户端A-B 101-102)，运营 或管理团队，布置团队103，以及服务的开发者104。所述这些各方当 中的每一方都具有其自身不同的服务版本要求。

如图1中所示，客户端A 101可以访问事务服务A 111的版本I 121， 客户端B 102可以访问事务服务A 111的版本II 122和事务服务B 112 的版本II 132。因此，客户端应用A-B 101-102的开发者可以将客户 端请求划分到具有相同服务名称的不同事务应用服务版本中。此外， 客户端应用A-B 101-102的开发者可以切换当前请求情境，以便根据 客户端的输入将不同的业务逻辑应用于相同的事务应用。

此外，在运行时间，布置团队103可以在不间断模式下升级事务 服务A 111的版本III 123中的事务应用逻辑，并且同时继续应对版 本I-II 121-122中的早前服务逻辑。此外，服务开发者104可以在运 行时间升级事务服务B 112的版本I 131中的服务逻辑，而不干扰具 有相同服务名称的版本II 132的当前活跃服务。

隐式版本控制

根据本发明的一个实施例，事务中间件机器环境可以支持隐式版 本控制，其可以是配置驱动的并且可以提供使得用户支持应用版本控 制的一种灵活方式。

图2示出了根据本发明的一个实施例的在事务中间件机器环境中 支持隐式版本控制的图示。如图2中所示，事务中间件机器环境200 中的事务服务器201可以在不同版本(例如版本I-III 211-213)中 提供事务服务A 210。

根据本发明的一个实施例，可以使用一个或多个配置文件209来 支持隐式版本控制。举例来说，配置文件209可以定义管理分层结构 中的不同层级之间的分层结构关系。

如图2中所示，用户可以基于版本范围把各项应用划分成不同的 虚拟区块，例如应用区块A-B 203-204。每一个应用区块A-B 203-204 可以被配置成应对具有特定版本编号的服务请求。举例来说，应用区 块A 203可以应对具有请求版本A 223(例如版本I)的服务请求，应 用区块B 204则可以应对具有请求版本B 224(例如版本II)的服务 请求。

此外，用户可以在运行时间改变客户端请求版本和服务版本范围。 这样的改变可以经由管理接口单元(例如Tuxedo中的MIB接口/API 接口)做出，并且可以在运行时间立即生效。

此外，用户可以通过配置文件209启用/禁用应用版本控制特征。 如果应用版本控制被禁用，则可以对现有系统没有影响。如果应用版 本控制被启用，则系统可以提供使得用户设定客户端/服务的版本并且 在不同层级(例如在应用和/或分组层级)配置服务支持版本范围的一 种方式。

举例来说，在Tuxedo中，UBB配置文件和DMCONFIG配置文件都 可以被用于支持隐式应用版本控制。顾客可以通过在UBB配置文件的 OPTIONS(选项)节段中规定新的应用选项APPVER来启用应用版本控 制特征。此外，UBB配置文件和DMCONFIG配置文件可以包括例如 REQUEST_VERSION(请求版本)、VERSION_POLICY(版本策略)和 VERSION_RANGE(版本范围)之类的属性，以用于在所配置的Tuxedo 管理实体中规定版本和可允许的版本范围。

如果应用版本控制特征被启用，则用户可以在UBB配置文件和域 配置文件中配置与应用版本有关的信息。另一方面，如果应用版本控 制特征未被启用，则用户无法在UBB配置文件中或者通过MIB接口来 配置与应用版本特征有关的配置。此外，如果顾客在UBB配置文件中 禁用应用版本控制特征，则域配置中的应用版本信息可以不具有影响。

如图2中所示，客户端应用A-B 206-207可以针对提供在事务服 务器201上的事务服务A 210发出请求。用户可以经由配置文件209 控制客户端请求版本和服务范围。举例来说，在Tuxedo中，用户可以 在UBB配置文件中在域层级和分组层级配置与应用版本有关的信息。

UBB配置文件中的REQUEST_VERSION可以被用来确定发送请求的 客户端的版本。REQUEST_VERSION的值可以是用数字表示的，其在大 于等于0并且小于等于65535(USHRT_MAX)时是有效的。此外，对应 于REQUEST_VERSION的默认值可以是“*”，其表明请求版本可以被任 何版本范围接受并且可以调用任何版本的服务。

UBB配置文件中的VERSION_RANGE可以被用来确定对应于服务的 可允许版本请求的范围。举例来说，Tuxedo用户可以利用 “low_version_number-high_version_number(低版本编号-高版本 编号)”的格式在对应于服务选择的分组层级在Tuxedo应用上设定版 本范围以简化UBB配置，所述格式表明 low_version_number<＝VERSION_RANGE<＝high_version_number(低版 本编号<＝版本范围<＝高版本编号)。

UBB配置文件中的VERSION_POLICY可以被用来确定版本控制策 略。举例来说，一个值可以是“PROPAGATE(传播)”，其表明所述服 务在启动新的请求时应当传播传入请求版本而不是使用其自身的请求 版本。

在服务调遣期间VERSION_POLICY可以优先于REQUEST_VERSION， 也就是说如果对于一项服务配置了REQUEST_VERSION和 VERSION_POLICY属性全部二者，则所述服务在启动新的请求时可以传 播传入请求版本。

下面的列表1包括用于在Tuxedo配置文件中规定应用版本的各个 实例。

列表1

如图2中所示，远程域A 202中的远程服务A 220可以针对本地 域中的事务服务A 210的某一版本发出请求。此外，本地域中的事务 服务A 210可以请求远程域A 202中的远程服务A 220(即版本I 221 或版本II 222)。

根据本发明的一个实施例，用户可以使用配置文件209来配置对 应于导入服务的服务版本范围，以及配置来自远程域的服务请求版本。 举例来说，在Tuxedo中，用户可以通过在域配置文件中引入新的属性 REQUEST_VERSION、VERSION_RANGE和VERSION_POLICY来配置远程服 务。

DMCONFIG配置文件中的REQUEST_VERSION可以被用来定义如何将 来自特定远程域(例如远程域A 202)的传入服务请求版本映射到本 地域中的所配置请求版本。当用户在域配置文件中配置 REQUEST_VERSION时，域网关可以改变传入请求版本，否则域网关可 以传播传入请求版本。

DMCONFIG配置文件中的VERSION_RANGE可以被用来表明导入远程 服务的版本范围。导入远程服务的这一版本范围可以与相应的导出服 务的版本范围相同。否则，所述调用即使在本地域中可以被接受，其 在远程域处也可能会失败。

此外，DMCONFIG配置文件中的VERSION_POLICY可以被用来确定 版本控制策略。举例来说，一个值可以是“PROPAGATE”，其可以被用 来确定域网关是否将把来自指定远程域的传入客户端请求的请求版本 传播/映射到所配置的请求版本。版本策略可以覆写DMCONFIG配置文 件中的请求版本。也就是说当VERSION_POLICY和REQUEST_VERSION 全部二者都被配置时，版本策略可以取得优先。此外，如果所述特征 被启用并且用户没有在域配置文件中配置请求版本，则域网关可以默 认地将客户端请求版本传播经过该域网关。

下面的列表2是示例性Tuxedo域配置文件。

列表2

前面的域配置表明对应于来自REMOTEDOM1的服务请求的请求版 本不可由域网关改变，而对应于来自REMOTEDOM2的服务请求的请求版 本则可以由域网关改变到4。

此外，域网关可以导入具有被设定为1-3的版本范围的来自 REMOTEDOM1的远程服务R_SVC1，这表明只有具有处于该范围内的请求 版本的客户端才能在本地域中调用R_SVC1。域网关还可以导入具有被 设定为4-6的版本范围的来自REMOTEDOM2的远程服务R_SVC2，从而 使得只有具有处于该范围内的请求版本的客户端才能在本地域中调用 R_SVC2。

图3示出了根据本发明的一个实施例的对应于在事务中间件机器 环境中支持隐式版本控制的示例性流程图。如图3中所示，在步骤301 处，事务服务提供者可以调遣与多个服务版本相关联的至少一项服务。 此外，在步骤302处，所述系统可以将一项或多项应用划分成一个或 多个应用区块，其中每一个所述应用区块与所述至少一项服务的特定 请求版本相关联。随后在步骤303处，所述系统允许所述应用区块中 的服务请求者访问具有与所述应用区块相关联的服务版本的所述至少 一项服务。

根据该实施例，可以向客户端并行地提供各个版本的服务。所述 系统可以对于不同版本的服务快速地调度客户端请求。因此，所述系 统(其例如被实施在计算机系统中或者被实施为计算机系统)的操作 效率得以改进。

版本情境

根据本发明的一个实施例，可以由请求发起者根据其如何加入受 到版本控制的应用隐式地创建版本情境。

图4示出了根据本发明的一个实施例的在事务中间件机器环境中 支持版本情境的图示。如图4中所示，可以利用具有多个层级的管理 分层结构(比如具有多个分组A-B 411-412的域401)来管理受到版 本控制的应用400。

此外，可以利用域请求版本410来配置域401，同时可以利用分 组请求版本A 413来配置分组A 411。因此，分组A 411中的服务A1-A3  421-423可以具有与分组请求版本A 413一致的请求版本。

此外，由于分组B 412不具有指定的请求版本(或者具有未激活 的分组请求版本B 414)，因此服务B1-B4 431-434可以具有继承自 域请求版本410的服务版本编号。

根据本发明的一个实施例，可以在加入受到版本控制的应用时将 初始服务请求者隐式地置入版本情境中。因此，所述隐式版本控制可 以分层地取决于服务请求者如何加入受到版本控制的应用。此外，用 户可以使用版本情境来控制是否可以在服务请求的整个生命周期中传 播所述版本信息，其中包括后续的服务路由和调遣。

如图4中所示，客户端A 402可以加入分组A 411中的受到版本 控制的应用400，并且可以在其加入分组A 411时与版本情境432隐 式地关联。此外，客户端B 403可以加入分组B 412中的受到版本控 制的应用400。因此，客户端B 403可以在其加入分组B 412时与版 本情境433隐式地关联。

此外，当服务器404在运行时间发起新的服务请求时，可以利用 版本情境434对服务器404进行隐式版本控制，并且当服务器405在 运行时间发起新的请求时，可以利用版本情境435对服务器405进行 隐式版本控制。

根据本发明的一个实施例，隐式版本控制可以具有不同的例外。 举例来说，例如在调用将输入消息转发到指定服务的tpforward时， Tuxedo不可改变所转发的请求消息中的请求版本编号。

Tuxedo隐式版本控制实例

在Tuxedo中，在启动请求时，不同的服务请求者(比如各个服务 器和/或服务、原生客户端、工作站客户端以及JOLT客户端)可以根 据UBB配置隐式地获取版本情境值。举例来说，所述版本情境值可以 是运行时间值，其只有在Tuxedo客户端、服务器或服务作为发起者启 动请求时才可以根据UBB配置文件被评估。

图5示出了根据本发明的一个实施例的支持Tuxedo多进程(MP) 环境的图示。如图5中所示，Tuxedo应用可以被布置在具有多个机器 (例如MACH1501和MACH2502)的多进程(MP)环境500中。此外， 可以使用配置文件来配置MP环境500。

下面的列表3示出了示例性UBB配置文件。

列表3

如列表3中所示，可以在UBB配置文件的RESOURCE(资源)、GROUPS (分组)节段中配置REQUEST_VERSION、VERSION_POLICY和 VERSION_RANGE属性。

举例来说，利用VERSION_RANGE、REQUEST_VERSION和 VERSION_POLICY属性来配置一个分组GRP_L1。因此，该分组中的所有 服务器和服务的VERSION_RANGE、REQUEST_VERSION和VERSION_POLICY 可以被确定为属于(inhere)分组配置。其结果是，对应于GRP_L1 中的服务器SVR_L1 533和SVR_L2 541的VERSION_RANGE属性的值是 “1-40”。此外，对应于SVR_L1 533和SVR_L2 541的REQUEST_VERSION 属性的值是20；同时SVR_L1 533和SVR_L2 541全部二者都可以传播 传入请求版本。

另一方面，对于分组GRP_L2则没有配置版本控制属性，并且所述 版本控制属性可以被确定为属于域层级(如在RESOURCE节段中规定)。 因此，该分组中的所有服务器和/或服务的VERSION_RANGE是 “0-2000”；该分组中的所有服务器和/或服务的REQUEST_VERSION 是1。由于在域层级上没有VERSION_POLICY，因此该分组中的所有服 务器和/或服务可以使用请求版本1而不是传播传入请求版本。

可以根据有关的WSL服务器所属的分组的请求版本确定来自工作 站客户端的请求版本。否则，可以根据对应于域的请求版本(即WSL 分组和RESOURCES(资源)的REQUEST_VERSION值)确定来自工作站 客户端的请求版本。

如图5中所示，工作站客户端(例如/WS-01 511和/WS-01 521) 可以经由例如分别由服务器侦听者WSGRP_L1_1:WSL 517和 WSGRP_L1_2:WSL 518管理的WSH_01 514和WSH_02 515之类的处理程 序访问MACH1 501上的服务。此外，工作站客户端/WS-01 521可以通 过由服务器侦听者WSGRP_L1_2:WSL 525管理的处理程序WSH_01 523 访问MACH2 502上的服务。

因此，工作站客户端/WS-01511可以隐式地拥有与 WSGRP_L1_1:WSL 517相同的REQUEST_VERSION情境值，其由 WSGRP_L1_1的请求版本配置确定。在这里，由于WSGRP_L1_1的版本 编号被配置为“4”，因此对应于/WS-01 511的隐式版本情境值也可 以是4，这意味着当/WS-01 511中的工作站客户端启动请求时，其请 求版本值是4。

此外，由于没有对于WSGRP_L1_2规定REQUEST_VERSION关键字值， 因此/WS-02 512具有如RESOURCE(资源)节段中所规定的与本地域相 同的版本编号。因此，根据所述版本分层结构，/WS-02 512的版本情 境编号可以是1，这意味着当来自/WS-02 512的工作站客户端启动新 的请求时，所述请求的请求版本是1。

此外，可以通过例如JSH_01 516和JSH_01 524之类的不同处理 程序来应对来自/JC-01 513或/JC-01 5522上的不同Jolt客户端的服 务请求。

类似地，可以根据Jolt服务器侦听者(JSL)JGRP_L1:JSL 519 所属的分组JGRP_L1的请求版本确定对应于来自Jolt客户端(例如 /JC-01 513)的服务请求的请求版本。此外，可以根据JGRP_L2:JSL 526 所属的分组JGRP_L2的请求版本确定对应于来自Jolt客户端(例如 /JC-01 522)的服务请求的请求版本。

另一方面，如果没有为JSL分组规定请求版本，则对应于来自Jolt 客户端的服务请求的请求版本是基于如在RESOURCE(资源)节段中规 定的本地域的请求版本。

此外，当原生客户端启动新的请求时，如果该原生客户端对于特 定分组加入所述应用，则该原生客户端可以在运行时间从分组/域分层 结构树获得请求版本值。否则，原生客户端从域层级获得请求版本值。

如图5中所示，例如请求MACH1 501上的服务器XASVR_L1 532的 原生客户端可以对于指定分组(例如XAGRP_L1)加入所述应用。因此， 该原生客户端可以在运行时间从分组配置获得请求版本值，即11。另 一方面，如果原生客户端在没有指定分组的情况下加入所述应用，则 该原生客户端可以在运行时间从分组/域分层结构树获得请求版本值。

根据本发明的一个实施例，当服务器/服务启动新的请求时，所述 服务器/服务可以在运行时间从该服务器所属的分组层级获得请求版 本值，或者在分组层级未定义请求版本时从域层级获得请求版本值。

对于用户定义的服务器，可以通过服务器分组的REQUEST_VERSION 值和域层级下的RESOURCES(资源)中的REQUEST_VERSION值确定隐 式版本。当所述服务器在服务器初始化或服务器终止期间调用其他服 务时，这一版本可以被用作请求版本。

对于服务，可以通过服务器分组的REQUEST_VERSION值和域层级 下的RESOURCES(资源)中的REQUEST_VERSION值来确定隐式版本。 其还可能受到VERSION_POLICY配置的影响。当所述服务在服务生存期 期间调用其他服务时，这一版本可以被用作请求版本。如果所述服务 传播传入请求版本，则该服务在调用其他服务时将传入请求版本用作 初始请求版本。

此外，无法对系统服务器(比如DBBL 535、BBL 536和542、BRIDGE (桥接器)510和520、DMGRP:GWT 534以及事件代理)、TMS服务 器(比如TMS_XAGRP_L1 531)、TLISTEN进程551和561以及其他接 口进程(比如CLI_LI_1 552、CLI_LI_1 562、CLI_LI_2 553和CLI_LI_2  563)进行版本控制。这些系统服务器可以总是使用默认版本值(其是 任意值)。

此外，对于Tuxedo对话调用，可以在对话连接设立阶段期间(即 在tpconnect()中)设立请求版本和版本范围。在所建立的连接上的 对话规程中(即在tpsend()/tprecv()中)可能没有版本检查。对于 Tuxedo/Q，所述系统可以在FORWARD(转发)队列中支持版本概念， 客户端可以向/从所述队列发送tpenqueue()/tedequeue()消息。因 此，当客户端将消息置入FORWARD(转发)队列中时，所述FORWARD (转发)队列可以将排入队列的消息转发到支持客户端请求版本的服 务。

基于版本的路由

根据本发明的一个实施例，可以在事务中间件机器环境中支持基 于版本的路由(VBR)。

图6示出了根据本发明的一个实施例的在事务中间件机器环境中 支持基于版本的路由(VBR)的图示。如图6中所示，事务中间件机器 环境600中的事务服务提供者609可以在不同的事务服务器(例如事 务服务器A-B 601-602)上提供事务服务A 610。

举例来说，事务服务器A 601可以提供版本I-II 611-612的服务 入口(也就是具有版本范围1-2)，事务服务器B 602可以提供版本 III-IV 613-614的服务入口(也就是具有版本范围3-4)。

此外，事务服务提供者609可以接收来自不同的服务请求者(例 如服务请求者A-B 605-606)的服务请求。事务服务提供者609可以 把接收自服务请求者A-B 605-606的服务请求中的所请求的服务名称 与各个可用服务入口相匹配。如图6中所示，事务服务提供者609可 以找到事务服务器A-B 601-602，这是因为事务服务器A-B 601-602 二者都提供事务服务A 610。

随后，在能够找到与服务请求中的所请求的服务名称相匹配的一 个或多个服务入口之后，事务服务提供者609可以使用基于版本的路 由(VBR)620机制来做出服务路由决定。举例来说，VBR 620可以把 接收自服务请求者(例如服务请求者A 605或服务请求者B 606)的 服务请求的请求版本编号与对应于事务服务器A 601和事务服务器B 602全部二者的版本范围的两个边界值进行数值比较。

在这里，接收自服务请求者A 605或服务请求者B 606的服务请 求可能没有显式地规定请求版本编号。基于隐式版本控制配置，事务 服务提供者609可以确定与每一项服务请求相关联的所请求的服务版 本。如图6中所示，应用区块A 603中的服务请求者A 605与请求版 本A 615(例如版本I)相关联，而应用区块B 604中的服务请求者B 606则与请求版本B 616(例如版本III)相关联。

如图6中所示，VBR 620可以把接收自应用区块A 603中的服务 请求者A 605的服务请求路由到事务服务器A 601，其提供事务服务A  610的版本I 611。此外，VBR 620可以把接收自应用区块B 604中的 服务请求者B 606的服务请求路由到事务服务器B 602，其提供事务 服务A 610的版本III 613。此外，当具有匹配的所请求服务名称的 所有服务对于受到版本控制的服务请求都不适合时，VBR可以向调用 者返回“没有找到入口”错误。

此外，VBR 620可以与其他路由机制一同使用。举例来说，在Tuxedo 中，VBR 620可以与几种路由机制一同使用，比如DDR(数据依赖路由) 621、TAR(事务亲和性路由)622以及RAR(请求亲和性路由)623。

举例来说，可以利用类似于现有路由算法的那些功能来实施VBR  620。当存在多种路由机制时，Tuxedo可以选择满足所有标准的服务。 此外，当一同使用多种路由机制时，用户可以根据其对于这些路由机 制如何相互作用的理解来实施更加复杂的路由方案。

根据本发明的一个实施例，事务服务提供者(例如Tuxedo)可以 为用户给出多种服务选择和路由算法，从而使得用户可以规划、开发、 缩放、布置以及升级其应用。可以使用应用版本控制以便避免使用特 殊路由情境以及满足多种划分要求。举例来说，作为Oracle Fusion  Middleware系列中的基础设施产品的一部分，Tuxedo可以在核心框架 中支持服务版本控制概念。

图7示出了根据本发明的一个实施例的用于在分布式事务中间件 机器环境中支持基于版本的路由(VBR)的示例性序列图。如图7中所 示，事务中间件机器环境700可以包括几个事务服务器(例如服务器 1 712、服务器2 713和服务器1 3 714)，其可以向不同的客户端(例 如客户端711)提供各种服务(例如SVC1、SVC2和SVC 3)。

此外，可以使用一个或多个配置文件来配置事务中间件机器环境 700，比如Tuxedo UBB配置文件和Tuxedo DUBB配置文件。

下面的列表4是示例性Tuxedo UBB配置文件。

列表4

下面的列表5是示例性Tuxedo DUBB配置文件。

列表5

如图7中所示，在步骤701处，服务器1712启动并且广告具有 版本范围“1-2”的服务SVC1和SVC2；并且在步骤702处，服务器2713 启动并且广告具有版本范围“3-4”的服务SVC1、SVC2和SVC3。

在步骤703处，服务器3714启动并且可以例如通过调用“tpcall  SVC2”请求服务SVC2。基于前面的列表4，服务器3 714术语分组 “GRP3”，其请求版本被评估为“3”。因此，所述系统可以把所述服 务请求路由到服务器2 713，这是因为与该服务请求相关联的请求版 本“3”匹配到由服务器2 703广告的SVC2的版本范围。随后在步骤 704处，在服务器3 704可以广告具有版本范围“1-3”的服务SVC2 和SVC3之前，服务器2 713可以执行SVC2。

此外，在步骤705处，客户端711可以利用针对SVC1的服务请求 初始化事务，这例如是通过利用请求版本“1”调用“tpcall SVC1”。 所述系统可以将该服务请求路由到服务器1 712，其版本范围匹配接 收自客户端711的服务请求的请求版本“1”。

随后在步骤706处，服务器1 712可以执行SVC1，其又调用“tpcall  SVC3”。所述系统可以将该调用路由到服务器3 714。在步骤707处， 服务器3 714可以执行SVC3，并且可以向REMOTEDOM1 715调用服务 R_SVC1，这例如是通过利用请求版本3调用“tpcall R_SVC1”。因此， 所述系统可以将该服务请求路由到REMOTEDOM1 715，正如列表5中所 示出的那样。在步骤708处，REMOTEDOM1 715可以执行远程服务 R_SVC1。

此外，本地域可以接收来自远程域(例如REMOTEDOM1 715和 REMOTEDOM2 716)的服务请求。如图7中所示，REMOTEDOM1 715和 REMOTEDOM2 716二者分别在步骤709和710处都发起“tpcall SVC1” 的服务请求操作。

基于列表5中的配置，可以传播接收自REMOTEDOM1 715的服务请 求，其具有原始请求版本“2”。因此，所述系统可以将该服务请求路 由到服务器1 712。随后，所述系统可以实施步骤706-708，以便向 REMOTEDOM1 715中的服务请求者提供所请求的服务。

此外，接收自REMOTEDOM1 716的具有原始请求版本“6”的服务 请求可以被改变到具有请求版本“4”。因此，所述系统可以将该服务 请求路由到服务器2 703并且在步骤724处执行所请求的服务SVC1。

图8示出了根据本发明的一个实施例的用于在事务中间件机器环 境中支持基于版本的路由(VBR)的示例性流程图。如图8中所示，在 步骤801处，事务服务提供者可以利用具有不同服务版本的多个服务 入口调遣至少一项服务。此外，在步骤302处，事务服务提供者可以 确定与某一服务入口相关联的服务版本是否匹配与接收自服务请求者 的服务请求相关联的所请求服务版本。随后在步骤803处，事务服务 提供者允许服务请求者访问匹配与服务请求相关联的所请求服务版本 的服务入口。

根据一些实施例，图9示出了根据前面所描述的本发明的原理配 置的事务服务提供者900的功能方框图。所述器件的各个功能方框可 以通过硬件、软件或者硬件与软件的组合来实施，以便实施本发明的 原理。本领域技术人员将理解的是，图9中所描述的功能方框可以被 组合或分离成子方框，以便实施如前面所描述的本发明的原理。因此， 这里的描述可以支持这里所描述的功能方框的任何可能的组合或分离 或进一步的定义。

如图9中所示，本发明的一个示例性实施例提供事务服务提供者 900。事务服务提供者900可以被使用在如前面所描述的用于在事务中 间件机器环境中支持应用版本控制的系统中。事务服务提供者900可 以包括调遣单元910、划分器920和访问单元930。调遣单元910可以 操作来调遣与多个服务版本相关联的至少一项服务。划分器920可以 操作来将一项或多项应用划分成一个或多个应用区块。每一个应用区 块可以与所述至少一项服务的特定请求版本相关联。访问单元930可 以允许所述应用区块中的服务请求者访问具有与所述应用区块相关联 的服务版本的所述至少一项服务。

在另一个实施例中，事务服务提供者900还可以包括确定单元 940。所述确定单元940可以操作来基于事务服务应用配置确定对应于 服务请求的服务版本。

在另一个实施例中，事务服务提供者900还可以包括接收单元 950。所述接收单元950可以操作来从远程服务接收针对所述至少一项 服务的服务请求。

图10示出了根据本发明的一个实施例的事务服务提供者110的示 例性方框图。事务服务提供者110包括调遣器1010、划分模块1020 和访问控制器1030。调遣器1010调遣与多个服务版本相关联的至少 一项服务1040。划分模块1020允许将一项或多项应用划分成一个或 多个应用区块1050。每一个应用区块1050与所述至少一项服务1040 的特定请求版本相关联。访问控制器1030允许应用区块1050中的服 务请求者1060访问具有与应用区块1050相关联的服务版本的所述至 少一项服务1040。

本发明可以方便地利用一个或多个传统的通用或专用数字计算 机、计算器件、机器或微处理器来实施，其中包括一个或多个处理器、 存储器以及/或者根据本公开内容的教导编程的计算机可读存储介质。 本领域技术人员将认识到，熟练的程序员可以根据本公开内容的教导 很容易地准备适当的软件代码。

在一些实施例中，本发明包括作为其上/其中存储有指令的存储介 质或(多种)计算机可读介质的计算机程序产品，所述指令可以被用 来对计算机进行编程以便实施本发明的任何处理。所述存储介质可以 包括(但不限于)任何类型的盘(其中包括软盘、光盘、DVD、CD-ROM、 微驱动器和磁光盘)、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存 器件、磁性或光学卡、纳米系统(其中包括分子存储器IC)或者适合 于存储指令和/或数据的任何类型的介质或器件。

前面提供的关于本发明的描述是用于说明和描述的目的。其并不 意图进行穷举或者将本发明限制到所公开的确切形式。本领域技术人 员将认识到许多修改和变型。所述修改和变型可以包括所公开的各项 技术特征的任何相关组合。选择和描述所述实施例是为了最好地解释 本发明的原理及其实际应用，从而使得本领域其他技术人员能够理解 适合于所设想的具体用途的本发明的各个实施例和各种修改。本发明 的范围应当由所附权利要求书及其等效表述限定。