用于在事务中间件机器环境中支持基于版本的路由的系统和方法专利检索-消息中间件中间件软件专利检索查询-专利查询网

用于在事务中间件机器环境中支持基于版本的路由的系统和方法

阅读：1023发布：2020-08-25

专利汇可以提供用于在事务中间件机器环境中支持基于版本的路由的系统和方法专利检索，专利查询，专利分析的服务。并且本发明涉及一种可以在事务中间件机器环境中支持服务管理的系统和方法。事务服务提供者可以利用具有不同服务版本的多个服务入口调遣至少一项服务，并且确定与某一服务入口相关联的服务版本是否匹配与接收自服务请求者的服务请求相关联的所请求服务版本。随后，事务服务提供者可以允许服务请求者访问匹配与服务请求相关联的所请求服务版本的服务入口。，下面是用于在事务中间件机器环境中支持基于版本的路由的系统和方法专利的具体信息内容。

权利要求

1.一种用于在事务中间件机器环境中支持基于服务版本的路由的方法，包括：
通过事务服务提供者利用具有不同服务版本的多个服务入口调遣至少一项服务；
通过事务服务提供者基于与从服务请求者接收的服务请求相关联的配置文件的第一属性，确定是否要执行对所述服务请求的基于版本的路由；
响应于确定要执行所述基于版本的路由，通过事务服务提供者基于所述配置文件的包括所请求服务版本的第二属性，确定与一服务入口相关联的服务版本是否匹配所请求服务版本；以及
通过事务服务提供者基于确定所请求服务版本匹配与所述服务入口相关联的服务版本，经由所述服务入口将服务请求者路由至所述至少一项服务的所述服务版本。
2.根据权利要求1所述的方法，还包括：
通过事务服务提供者将服务入口的服务名称与接收自服务请求者的服务请求中的所请求服务名称相匹配。
3.根据权利要求2所述的方法，还包括：
当具有匹配名称的所有服务入口都无法匹配所请求服务版本时，向服务请求者返回错误消息。
4.根据任一在前权利要求所述的方法，还包括：
利用版本范围将应用划分成多个应用区块，其中所述版本范围表示服务的多个版本入口，并且其中每一个所述应用区块通过该应用区块的特定请求版本来与所述服务的特定服务版本入口相关联。
5.根据权利要求4所述的方法，还包括：
通过事务服务提供者将所请求服务版本编号与所述版本范围的全部两个边界值进行数值比较。
6.根据权利要求1到3中的任一项所述的方法，还包括：
允许服务请求者是客户端应用和远程服务的其中之一。
7.根据权利要求1到3中的任一项所述的方法，还包括：
利用以下各项的至少其中之一实施服务路由：
数据依赖路由算法；
事务亲和性路由算法；以及
请求亲和性路由算法。
8.根据权利要求1到3中的任一项所述的方法，还包括：
利用事务服务应用配置来确定与服务请求相关联的所请求服务版本。
9.根据权利要求8所述的方法，还包括：
利用至少一个配置文件来提供事务服务应用配置。
10.根据权利要求9所述的方法，还包括：
在运行时间利用管理接口改变事务服务应用配置。
11.一种非瞬时性机器可读存储介质，具有存储在其上的指令，所述指令在由计算机系统执行时使得所述计算机系统实施任一在前权利要求的方法。
12.一种用于在网络环境中支持基于服务版本的路由的系统，包括：
一个或多个微处理器；
运行在所述一个或多个微处理器上的事务服务提供者，其中所述事务服务提供者操作为：
利用具有不同服务版本的多个服务入口调遣至少一项服务；
基于与从服务请求者接收的服务请求相关联的配置文件的第一属性，确定是否要执行对所述服务请求的基于版本的路由；
响应于确定要执行所述基于版本的路由，并且基于所述配置文件的包括所请求服务版本的第二属性，确定与一服务入口相关联的服务版本是否匹配所请求服务版本；以及基于确定所请求服务版本匹配与所述服务入口相关联的所述服务版本，经由所述服务入口将服务请求者路由至所述至少一项服务的所述服务版本。
13.根据权利要求12所述的系统，其中：
所述事务服务提供者操作为将服务入口的服务名称与接收自服务请求者的服务请求中的所请求服务名称相匹配。
14.根据权利要求13所述的系统，其中：
所述事务服务提供者操作为在具有匹配名称的所有服务入口都无法匹配所请求服务版本时向服务请求者返回错误消息。
15.根据权利要求12到14中的任一项所述的系统，其中：
通过使用版本范围，应用能够被划分成多个应用区块，其中所述版本范围表示服务的多个版本入口，并且其中每一个所述应用区块通过该应用区块的特定请求版本来与所述服务的特定服务版本入口相关联。
16.根据权利要求15所述的系统，其中：
所述事务服务提供者操作为将所请求服务版本编号与所述版本范围的全部两个边界值进行数值比较。
17.根据权利要求12到14当中的任一项所述的系统，其中：
服务请求者是客户端应用和远程服务的其中之一。
18.根据权利要求12到14当中的任一项所述的系统，其中：
所述事务服务提供者操作为利用以下各项的至少其中之一实施服务路由：
数据依赖路由算法；
事务亲和性路由算法；以及
请求亲和性路由算法。
19.根据权利要求12到14中的任一项所述的系统，其中：
所述事务服务提供者操作为利用事务服务应用配置来确定与服务请求相关联的所请求服务版本。
20.根据权利要求19所述的系统，其中：
所述事务服务提供者操作为实施以下各项的至少其中之一：
利用至少一个配置文件来提供事务服务应用配置；以及
在运行时间利用管理接口改变事务服务应用配置。
21.一种用于在事务中间件机器环境中支持基于服务版本的路由的装置，包括用于实施如权利要求1到10中的任一项所述的方法的单元。

说明书全文

用于在事务中间件机器环境中支持基于版本的路由的系统和

方法

技术领域

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

背景技术

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

发明内容

[0005] 这里描述了用于在事务中间件机器环境中支持服务管理的系统和方法。事务服务提供者可以利用具有不同服务版本的多个服务入口调遣至少一项服务，并且确定与某一服务入口相关联的服务版本是否匹配与接收自服务请求者的服务请求相关联的所请求服务版本。随后，事务服务提供者可以允许服务请求者访问匹配与服务请求相关联的所请求服务版本的服务入口。

[0006] 本发明的一个示例性实施例提供一种用于在网络环境中支持网络管理的系统，其包括事务服务提供者。所述事务服务提供者可以包括调遣单元、匹配单元和访问单元。调遣单元可以适于利用具有不同服务版本的多个服务入口调遣至少一项服务。匹配单元可以适于确定与某一服务入口相关联的服务版本是否匹配与接收自服务请求者的服务请求相关联的所请求服务版本。在另一个实施例中，匹配单元可以适于把服务入口的服务名称与接收自服务请求者的服务请求中的所请求服务名称相匹配。访问单元可以适于允许服务请求者访问匹配与服务请求相关联的所请求服务版本的服务入口。

[0007] 在另一个实施例中，事务服务提供者还可以包括返回单元，其适于在具有匹配名称的所有服务入口都无法匹配所请求服务版本时向服务请求者返回错误消息。

[0008] 在另一个实施例中，事务服务提供者还可以包括划分器，其适于将一项或多项应用划分成一个或多个应用区块。每一个应用区块与所述至少一项服务的特定请求版本相关联。

[0009] 在另一个实施例中，事务服务提供者还可以包括比较单元，其适于实施所请求服务版本编号与所述版本范围的全部两个边界值之间的数值比较。

[0010] 在另一个实施例中，事务服务提供者还可以包括版本确定单元，其适于确定与服务请求相关联的所请求服务版本。

[0011] 在另一个实施例中，事务服务提供者还可以包括配置提供单元，其适于利用至少一个配置文件来提供事务服务应用配置。

[0012] 在另一个实施例中，事务服务提供者还可以包括配置改变单元，其适于在运行时间利用管理接口改变事务服务应用配置。附图说明

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

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

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

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

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

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

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

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

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

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

具体实施方式

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

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

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

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

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

[0028] 应用服务版本控制

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

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

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

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

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

[0034] 隐式版本控制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0049]

[0050] 列表1

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

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

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

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

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

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

[0057]

[0058] 列表2

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

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

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

[0062] 版本情境

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

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

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

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

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

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

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

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

[0071] Tuxedo隐式版本控制实例

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

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

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

[0075]

[0076]

[0077] 列表3

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

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

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

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

[0082] 如图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上的服务。

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

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

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

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

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

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

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

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

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

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

[0093] 此外，无法对系统服务器(比如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)进行版本控制。这些系统服务器可以总是使用默认版本值(其是任意值)。

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

[0095] 基于版本的路由

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

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

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

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

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

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

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

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

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

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

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

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

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

[0109]

[0110] 列表4

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

[0112]

[0113] 列表5

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

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

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

[0117] 随后在步骤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。

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

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

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

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

[0122] 从前面的实施例可以看出，可以向客户端并行地提供各种版本的服务，并且所述系统可以将客户端请求快速地路由到不同版本的服务。因此，所述系统(其例如被实施在计算机系统中或者被实施为计算机系统)的操作效率得以改进。

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

[0124] 如图9中所示，本发明的一个示例性实施例提供事务服务提供者900。事务服务提供者900可以被使用在如前面所描述的用于在事务中间件机器环境中支持应用版本控制的系统中。事务服务提供者900可以包括调遣单元910、匹配单元920和访问单元930。调遣单元910可以适于利用具有不同服务版本的多个服务入口调遣至少一项服务。匹配单元920可以适于确定与某一服务入口相关联的服务版本是否匹配与接收自服务请求者的服务请求相关联的所请求服务版本。在另一个实施例中，匹配单元920可以适于把服务入口的服务名称与接收自服务请求者的服务请求中的所请求服务名称相匹配。访问单元930可以适于允许服务请求者访问匹配与服务请求相关联的所请求服务版本的服务入口。

[0125] 在另一个实施例中，事务服务提供者900还可以包括返回单元940，其适于在具有匹配名称的所有服务入口都无法匹配所请求服务版本时向服务请求者返回错误消息。

[0126] 在另一个实施例中，事务服务提供者900还可以包括划分器950，其适于将一项或多项应用划分成一个或多个应用区块。每一个应用区块与所述至少一项服务的特定请求版本相关联。

[0127] 在另一个实施例中，事务服务提供者900还可以包括比较单元960，其适于实施所请求服务版本编号与所述版本范围的全部两个边界值之间的数值比较。

[0128] 在另一个实施例中，事务服务提供者900还可以包括版本确定单元970，其适于确定与服务请求相关联的所请求服务版本。

[0129] 在另一个实施例中，事务服务提供者900还可以包括配置提供单元980，其适于利用至少一个配置文件来提供事务服务应用配置。

[0130] 在另一个实施例中，事务服务提供者900还可以包括配置改变单元990，其适于在运行时间利用管理接口改变事务服务应用配置。

[0131] 图10示出了根据本发明的一个实施例的事务服务提供者110的示例性方框图。事务服务提供者110包括调遣器1010、确定模块1020和访问控制器1030。事务服务提供者110被配置成接收来自服务请求者1060的服务请求。

[0132] 调遣器1010利用具有不同服务版本的多个服务入口1050调遣至少一项服务1040。确定模块1020确定与某一服务入口1040相关联的服务版本是否匹配与接收自服务请求者
1060的服务请求相关联的所请求服务版本。访问控制器1030允许服务请求者1060访问匹配与服务请求相关联的所请求服务版本的服务入口1050。

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

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

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

标题	发布/更新时间	阅读量
信息处理方法、装置、电子设备及存储介质	2020-05-11	49
基于消息中间件的异步会计核算与交易分离方法及系统	2020-05-12	499
数据处理方法、装置、电子设备及存储介质	2020-05-12	304
自动化扩容缩容的控制方法、装置、存储介质及处理器	2020-05-13	950
数据采集交换引擎	2020-05-13	263
一种动态剪裁发布订阅关系的LVC网关	2020-05-08	138
数据库日志同步方法、装置、计算机设备及可读存储介质	2020-05-12	256
基于数据传输服务的软硬件解耦设计的系统设计方法	2020-05-08	795
基于设备全生命周期的信息监控系统	2020-05-11	578
一种外联业务处理高并发请求的系统和方法	2020-05-14	288