概率动态路由器-服务器网格路由的制作方法

专利名称：概率动态路由器-服务器网格路由的制作方法
概率动态路由器-服务器网格路由背景背景和相关领域计算机和计算系统已经影响了现代生活的几乎每一个方面。计算机一般地涉及工 作、休闲、医疗保健、交通、娱乐、家务管理等等。此外，可以由经由网络连接互连到其他计算系统的计算系统能力来增强计算系统 功能。网络连接可以包括但不限于经由有线或无线以太网的连接、蜂窝式连接或甚至通过 串行、并行、USB或其他连接的计算机到计算机连接。各连接允许计算系统访问其他计算系 统处的服务并快速地和高效地从其他计算系统接收应用程序数据。可以使用消息处理系统来在连网的计算机之间路由消息。消息处理系统的简单安 排包括在从客户端机器直接接收消息的单个机器上运行的服务。随着该服务所要求的资源 的量因消息的数量或者处理消息的平均成本的增长，构建可以应对该处理负载的单个机器 最终可能会变得不切实际地昂贵。一种常见做法是跨越若干机器而执行服务的多个实例， 以使得该处理负载在若干较廉价机器中分配。将该处理负载在若干机器中分配还可以用于 消除临界点以便改善总体系统可靠性。系统的并行效率衡量添加更多机器的效率如何。在并行效率是100%时，机器数量 翻番会使得每一机器的处理负载变为一半。并行效率可以是较小的百分数、0、或甚至是负 的。负的并行效率意味着添加机器的开销大于总的处理能力的增益。在各处理机器之间的 协调是通常引起差的并行效率的常见原因中的一个。例如，在包括若干服务的拓扑中，在消 息被路由到一服务之前，有必要保证该服务具有处理该消息所必要的状态信息。说明性地， 在拓扑中的特定的服务处可以加载带有特定电子商务购物车的状态信息的状态包。在该拓 扑处可以接收更新购物车(例如添加新的项目、移除项目、完成定单等等)的消息。如果该 拓扑中的多个服务可以处理购物车功能，则在该拓扑处可以存在对判断各服务中的哪一个 包括所讨论的特定购物车的状态包的需求。存在其中可以独立地处理各消息的服务的若干示例。消息独立性允许将消息发送 到任何可用的处理节点。还存在具有在各消息和各处理节点之间的明显关联的服务的示 例。明显关联允许以低协调水平将传入的消息路由到适当处理节点。明显关联的示例有， 网络连接恰好等于必须一起处理的消息集的边界。然而，存在其中需要关联开销来协调消 息和服务的若干示例。在此要求保护的本主题不限于解决任何缺点的实施例或仅在诸如以上所描述的 那些环境等的环境中操作的实施例。相反，此背景仅被提供为阐释其中可以实践在此描述 的一些实施例的一个示例性技术领域。概述在此描述的一个实施例针对使用不可靠的路由数据来路由消息的方法。该方法可 以在计算环境中的处理节点处实践。该方法包括从计算机可读通信介质接收消息。计算该 消息的一个或多个特性性质，以便判断用于该消息的处理的在一服务处的服务实例的状态 要求。作出尝试获得满足用于处理该消息的状态要求的适当的服务实例。当尝试获得满足用于处理该消息的状态要求的适当的服务实例在获得适当的服务实例中是成功的时，基于 该状态要求处理该消息。该方法包括判断尝试获得满足用于处理该消息的状态要求的适当 的服务实例在获得适当的服务实例中是不成功的。结果，使用路由信息不可靠的本地缓存 且在没有各处理节点之间的协调的情况下来重定向该消息，以便尝试使该消息到达具有适 当的服务实例或者可以成功地获得满足用于该消息的处理的状态要求的适当的服务实例 的服务器节点。提供本发明内容以便以简化形式介绍下面在详细描述中进一步描述的概念的选 集。本发明内容不旨在标识该所要求保护的本主题的关键特征或必要特征，也不旨在用来 帮助确定所要求保护的本主题的范围。另外的特征和优点将在下列的描述中阐明，且部分将可从该描述明显看出，或可 以通过在此的教导的实践来学习。可以借助于在所附权利要求中特别指出的装置和组合来 实现和获得本发明的特征和优点。本发明的特征将从下列的描述和所附权利要求变得更加 充分地明显，或者通过下文所阐明的本发明的实践来学习。附图简述为了描述可以获得上述的和其他的优点和特征的方式，将通过参考附图中所阐释 的具体的实施例来呈现以上简要描述的本主题的更加具体的描述。应理解，这些图仅描绘 典型的实施例且因此不被认为是对范围的限制，将通过使用附图借助于另外的特异性和细 节来描述和解释各实施例，附图中

图1阐释包括路由器节点和用于处理消息的服务节点的网络环境；图2A阐释其中可以计算消息的各特性的环境；图2B阐释查询优化模块；图2C阐释在计算中间结果之前和之后变换数据；图2D阐释一些实施例的另外的特性计算细节；图3阐释处理消息的方法；以及图4阐释使用不可靠的路由数据来路由消息的方法。详细描述一些实施例针对其中在各消息和各处理节点之间存在某种不明显关联的服务。例 如，不明显关联的一个示例是基于这样的消息中的内容该消息的位置和格式取决于应用 程序定义的协议和/或该消息的值反映见于先前消息中的内容。一些实施例通过使得各处理节点容忍路由错误并采用乐观路由来降低不明显关 联的协调水平。在稍后的处理期间将探测错误的路由决定。响应于被错误地路由的消息， 丢弃部分完成的工作且再次以乐观方式来重新路由该消息。另外，可以将信息返回给错误 地路由消息的节点，以使得将有可能正确地路由该节点路由的将来的消息。尽管由于遭遇 了路由错误，一些消息会要求处理更多工作，但处理消息的平均成本下降了，这是因为可以 经常正确做出乐观路由，并且可以减少在各节点之间的协调。正如所述的，一些实施例允许通过使用最佳猜想且无需在各处理节点之间协调来 基于该消息的特性性质路由消息。这可以通过维持路由数据不可靠的本地缓存来完成。路 由数据不可靠的本地缓存可以包括，例如，在各消息特性、消息元数据特性或服务节点的其 他特性之间的关联。此外，该路由数据可以包括基于所接收的重定向消息的更新。例如，错误地接收消息的节点可以提供为该数据标识正确的节点的信息。各实施例还可以包括用于 决定如何基于该原始的消息传送机制或特性而处理该重定向消息的功能。进一步，路由可 以包括将负载平衡机制包括为用于最佳猜想路由的定义的部分。一些实施例可以包括由实例协调器基于消息的特性性质而实现的原子创建负载 原语。例如，作为原子创建负载操作的部分，可以在各特性和服务实例之间提供附加关联。 被执行为提供关联的查找可以基于多于一个特性。此外，可以通过使用服务实例的本地目 录来实现查找的优化。下面在此进一步包括这些实施例的更多详细描述。各实施例可以包括用于作为失败的创建负载操作的结果而生成重定向消息的功 能。在一些实施例中，可以使用目录服务或发现协议来决定重定向地址。此外，用于其他服 务实例的路由数据可以作为该重定向消息的部分被包括。现在参见图1，阐释互连各处理节点的网络100。可以使用计算硬件和软件来实现 各处理节点，如在此稍后定义的，计算硬件和软件包括适当的处理器、存储器设备、计算机 存储、在计算机可读介质上实现的计算机可执行指令等等。各处理节点中的一些能够执行 应用程序服务的实例。各处理节点中的一些在此被称为服务器节点，且由图1中所阐释的 示例服务器节点102和104来被阐释。各处理节点中的一些能够在各处理节点中间路由消 息。这些节点在此被称为路由器节点，且由路由器节点106阐释。随着时间的推移且在没 有协调的情况下，可以存在对节点数量、在各节点之间的连接或节点的角色(例如获得或 失去路由器或服务器能力)的改变。因此，网络的任何描述都表示特定时刻的快照。各处 理节点并不必定永久地被划分成路由器和服务器。具体地，处理节点可以起到两者(由路 由器-服务器节点110阐释，路由器-服务器节点110在此可以被称为路由器节点或服务 器节点)的作用或不起到两者中的任何之一的作用。包括一个或多个服务实例116在内的应用程序在网络100上执行，一个或多个服 务实例116在此一般地由116指代，且具体地由116-X指代，其中X是用于指示特定的服务 实例116的变量。应用程序可以持续地创建和破坏服务实例116。因而，当前的服务实例 116的集合可以不断地改变。服务实例116处理消息且随着时间的推移可以积累实例状态。 在本示例中，服务实例116每次只存在于各服务器节点中的一个。当服务实例116不位于 任何服务器节点时，其由所有服务器节点都可以访问的实例协调器112持有。实例协调器 112的一个典型的实现是持久地存储服务实例116的实例状态的数据库。应用程序可以不断地在各种处理节点处从外部源接收消息114。处理消息可以要 求现有的服务实例116的实例状态、要求之前从来没有处理过消息的新的服务实例116的 白板、或没有实例状态要求。各处理要求可以是应用程序的定义的部分，且因而视应用程序 不同而不同，且可能不容易从消息明显看出。一些实施例的一种功能是将消息定向到满足 消息的处理要求的服务器节点而不要求在各处理节点之间的过多的协调。在一些实施例 中，这可以通过计算特性来完成，特性可以被用来判断消息114的处理要求。可以使用例如在题为"Query-Oriented Message Characterization(面向查询的 消息表征)，，的美国申请第12/203，790号中所描述的技术来执行特性计算，该申请与此同 时提交，且通过引用以其整体合并于此。图2A-2D阐释对于一些实施例如何执行特性计算。 现在参见图2A，阐释一示例。图2A阐释查询引擎202。查询引擎202包括处理查询204的 功能，其中查询204是针对诸如包括可从其他源获得的消息数据或非消息数据210在内的消息114等的各种数据源的查询。具体地，一些实施例可以被实践为使得可以使用对消息 内容、元数据或其他信息的查询来指定消息特性。查询引擎可以包括对各种语言206的支 持。在一个具体的示例中，可以通过将XPath表达式用作查询语言来表达查询。通常，诸如XPath等的查询语言206具有用于访问有限的多种格式的且来自有限 的多种源的信息的天生功能，同时非天生地包括用于访问其他信息的功能。例如，XPath包 括用于访问诸如使用XML来格式化的消息等的XML结构化数据结构中的信息的天生功能， 但是可以不包括用于确定来自其他服务的其他信息的功能。尽管如此，可以通过包括扩展 212来将查询语言扩展成包括用于访问其他服务的功能。在XPath查询语言中，扩展被称为 选择器。另外，一些实施例可以包括使用对查询语言的扩展来规范化对不同的存储位置的 访问的功能。在一些实施例中，规范化对不同的存储位置的访问可以使用双方商定的数据 结构。可以通过合并各查询并同时或并行执行它们来执行对计算相同消息的多个特性的优 化，如下面更详细地描述。正如图2A中所阐释的，信息源可以包括消息114，消息114包括消息数据在内。消 息可以包括诸如信封数据、消息正文中的数据、消息的首部中的数据等等的信息。如上所 述，查询引擎202可以包括用于提取消息数据的功能。例如，在一个实施例中，查询引擎可 以包括支持用于从XML格式化消息中提取数据的XPath查询语言的功能。还可以或者替代 地可以使用其他查询语言206。值得注意的是，查询引擎202还可以包括用于调用各种应用 程序编程接口(API) 214的功能。API 214包括用于与各信息源交互以便从各源获得数据的 经编程的功能。值得注意的是，在一些方面，可以将各语言206认作API。图2A进一步阐释非消息数据210。非消息数据可以是来自多个不同的源中的任何 一个的数据，且可以包括关于消息数据的元数据或不直接地呈现该消息数据的其他数据。 与消息114中的数据相关联的元数据可以包括诸如指示用于发送消息114的协议的协议数 据、环境数据、本地性质、日时等等的信息。如先前所述，图2A阐释查询引擎202针对各数据源执行查询204。基于查询204， 查询引擎202生成可以是数据实例值的中间结果216。中间结果216可以包括数据的表或 数据的其他形式。例如，中间结果216可以包括诸如具体的日时(该日时可以与消息114 相关联或不相关联)、用于传输消息114的具体协议或其他信息等的信息。中间结果通常不 是无单位的结果，而是代表某种具体的单位。例如，中间结果216可以代表日时单位、协议 单位、传输单位或某种其他的具体单位。另外，各中间结果可以是一个或多个不同的数据类 型。例如，中间结果可以是整数、浮点、串或其他数据类型。另外，中间结果的集合可以具有 不同的数据类型的混合。例如，时间可以被表达为一个或多个整数，而协议可以被表达为一 个或多个串。时间整数和协议串两者都可以被包括在中间结果216的相同的集合中。中间结果216可以被特性计算模块220用来创建特性218。特性218可以是例如 使用散列算法或基于中间结果216计算数值的其他数值方法来计算的数值。例如，在一个 实施例中，特性218可以是表示全局唯一标识符的无单位的1 位散列数。可以使用被配 置成计算散列或诸如例如数值表示等的其他表示的计算机硬件和软件来实现特性计算模 块 220。如下面将更详细地讨论的，可以实践其中在消息特性218的计算和消息收发基础 设施之间进行协调的一些实施例。具体地，消息收发基础设施可以对它可以潜在地提供给查询204的信息编目。例如，消息收发基础设施可以提供关于传输的信息、关于协议的信息 等等。消息收发基础设施可以承诺信息在特定时间的可用性。在一些实施例中，该承诺与 在该消息收发基础设施处的某种动作的某种功能或性能相关。可以在特性计算模块220处 的特性计算之前执行对查询204的分析，以判断将需要什么信息。可以执行特性计算的优 化，以便在经受基于信息可用性的约束的更方便的时间执行用于特性计算的计算。如下面将更详细地讨论的，可以实践其中在查询之前和/或之后执行信息的变换 的一些实施例。再次参见图2A，阐释具有特殊性的更详细的示例。考虑希望计算其特性的消息 114。可以在不考虑现在或过去如何生成消息114的前提下预先假定这一消息114的存在。 因而，这可以是正被发送的、正被接收的或者甚至是与消息操作没有任何联系的被无中生 有地创建的消息。可以以各种格式来表示该消息。作为示例，考虑使用简单对象访问协议 (SOAP) 1. 2格式来表示的消息。这样的消息将具有用于消息信封、消息正文和任何数量的消 息首部的存储位置。该消息还可以使得在消息信封中不包含的元数据与之相关联，这些元 数据例如本地消息性质、传送性质或周围环境中的信息。此元数据可以由在210处阐释的 非消息数据表示。因而，数据源可以是指该消息内的信息的源或者该消息外的信息的源。为了计算消息114的特性，可以利用所有可用的信息源。特性的计算将通常仅要 求可用的信息的子集。此子集由包括一个或多个查询204的查询规范205描述。每一查询 包括一标识符和一查询过程。查询过程定义如何从可用的信息中提取值。作为查询规范205的示例，在一个实施例中，使用XPath表达式来指定查询过程。 例如，该消息可以是SOAP格式的采购定单，其片段如下所示
<s: Envelope〉
<s: Header〉
…消息中所包括的首部数据… </s: Header〉 <s:Body>
<po: PurchaseOrder pur ckaseOrderNumber= M123 "> …由应用程序定义的釆购定单数据...
</po Purchas eOrder> </s:Body> </s: Envelope〉XPath 表达式“/s Envelope/s Body/po PurchaseOrder/ipurchaseOrderNumber ” 指定消息的一部分。在本示例中，XPath表达式指定名为Envelope(信封)的元素内 的名为Body(正文)的元素内的名为PurchaseOrder(采购定单)的元素上的名为 purchaseOrderNumber (采购定单号)的属性的值。在本示例中，XPath表达式被命名为 "PONumber (采购定单号)”，以便创建在标识符PONumber和由评估该XPath表达式而得到 的事实之间的关联，(即表示采购定单单元123的号123)。
一旦向查询引擎202提供包括查询204和诸如消息114的必要的信息源和/或对 生成非消息源210数据的源的访问权在内的查询规范205，查询引擎202就计算在中间结果 216中阐释的已命名查询结果的表。在所阐释的示例中，根据已命名查询结果216来定义特性218的计算以从如何访 问或组织信息中抽象出计算过程。通过使得新的信息源与现有信息源统一或者通过用新的 访问方法扩展查询引擎，可以将新的信息源添加到系统。例如，标准XPath语言仅提供对消 息数据的访问。可以用新的函数扩展XPath语言以便访问非消息数据，正如由扩展212所 阐释的。在一个实施例中，HTTP Referer(引用物)首部不是消息数据的部分，但是可以 使用XPath表达式“KGetfrotocolDataO/Referer”来指定非消息数据210的部分以相 似的方式访问。在此情况中，消息内不含有协议数据中的Referer性质的值。尽管SMTP From (SMTP来自)首部来自不同的信息源，但也可是使用GetProtocolData (取协议数据) 函数来访问它。因而，可以根据开发者的方便来实现将信息分组到相同或不同的访问方法。现在参见图2B，现在将讨论查询引擎202的另外的细节，且尤其是关于优化查询 处理。如果针对诸如消息数据208和非消息数据210等的相同信息源执行多个查询204， 则当将这些查询合起来而非每次一个时，往往可能更高效地执行查询的集合。在一个实施 例中，为做到这一点，查询引擎202包括查询优化模块222，查询优化模块222在使用语言 206来执行经优化的查询规范2 之前首先将原始的查询规范205变换成经优化的查询规 范224(如图2A中所阐释的API 214)。经优化的查询规范2 在被处理时产生相同的查询 结果216的表。在一个实施例中，查询引擎202的查询优化器222将具有公共子表达式的各 查询结合在一起，以使得单个公共子表达式仅被评估一次。因而，作用于含有两个查询 “s Envelope/s Body/PurchaseOrderl，，禾口"/s Envelope/s Body/Purchase0rder2，，白勺查询 规范205的查询引擎202可以仅需要扫描消息114的Envelope元素和Body元素一次就满 足这两个查询。现在参见图2C，阐释查询引擎202关于在处理之前和之后变换数据的另外的特 征。在所阐释的实施例中，查询引擎202与其他组件2 和230组成处理流水线2 的部分。 这些组件2 和230分别作用于对该引擎的输入和输出。在组件2 处，在由该引擎读取 信息源之前，可以将一个或多个变换应用到各信息源，且在组件230处，在计算特性218 (见 图2A)之前，可以将一个或多个变换应用到各查询结果。信息源中的每一事实和每一指定 的查询结果可以使对其应用单独地精心制作的变换；或者，可以将各变换应用到一组事实 或查询结果。应用程序常常具有用于计算特性218的优选时间。对应用程序来说，取决于所做 出的决定的类型，通常希望尽可能迟地或者尽可能早地计算特性218。然而，直到所有必要 信息可用之前，应用程序不能计算该特性218，。当发送消息时会发生这种冲突的一个示例。 可能希望尽可能早地计算该特性，以使得在观察到对发送消息的任何响应之前该特性是已 知的。然而，直到部分地或完全地发送消息之前，计算该特性所必需的信息可能是不可用 的。直到很迟之前都不可用的信息的示例是在消息被写到线上时由传送系统指派的消息标 识符。
现在参见图2D，阐释解决这些问题的一个实施例的示例。为了推理出冲突，应该 知道特性计算将使用什么信息以及何时该信息将可用。在由应用程序232发送消息114之 前，反省消息收发基础设施234以便标识此特定配置将生成的各种信息。消息收发基础设 施234还可以作出关于何时每一事实将可用的一个或多个声明。各声明可以是各事实将在 特定的时间或处理阶段可用的承诺。也是在发送消息114之前，可以反省查询规范205(见 图2A)以确定此特定的查询规范205将请求的各种信息。图2D相对于时间线轴T阐释消息收发基础设施234。时间线轴T阐释时间在向 下方向上增加。在Tfffe，消息114从该应用程序232发送到消息收发基础设施234。在一 些实施例中，大约在消息114被发送的时候，将查询规范205中的查询204将要求的信息标 识符的列表与消息114关联起来。值得注意的是，各实施例可以被实现为在消息114被发 送之前、在消息114被发送的时候、或者在一些实施例中是在消息114被发送之后关联信息 标识符的列表。另外，将消息114与调用查询引擎202和特性计算模块220(见图2A)的回 调关联起来。组件236-1-236-N可以作用于消息114。当各组件(在这里概括地指236且 具体地由236-X代表，其中X是标识特定组件的数字)作用于消息114时，各组件概念性地 向在每一所标识的事实变为可用将被查询204要求的信息标识符的列表添加校验标记。在 一个实施例中，当有可能执行得到事实的值的具体过程时，该事实变得可用。此过程可以简 单地返回该事实的预先计算的值，或者替代地可以要求执行另外的计算。因而，尽管实审可 以在特定的时间为查询引擎202可用，但直到查询引擎202在稍后的时间请求该值之前，在 明确的意义上不可知道该事实的值，如果查询引擎202曾经这样选择的话。一旦所有所标 识的信息可用，则可以调用回调以便完成特性计算。在所阐释的示例中，图2D示出使关于 消息114的信息对查询引擎202可用。在时间T1，使由组件236-1提供的信息对查询引擎 202可用。在时间T2，使由组件236-2提供的信息对查询引擎202可用。在时间TN，使由组 件236-N提供的信息(这表示可以在该消息收发基础设施234中实现任何数量的组件236) 对查询引擎202可用。时间线轴T包括代表消息114被从消息收发基础设施234传出(例如通过该将消 息传输到通信线)的时间T{_。通信线可以是包括网络线缆或无线传输介质在内的不同数 量的介质中的任何一种。计算的完成可以早于或晚于消息被发送发生，这取决于由组件236 所作的承诺。在一个实施例中，回调的完成被用来解决在发送消息和接收消息之间的竞争。应 用程序232制止处理可能依赖于先前所发送的消息114的特性218的任何所接收的消息， 直到所有那些特性都已经被计算。下列讨论现在引用可以执行的若干方法和方法动作。应注意，尽管可以以某种次 序来讨论这些方法动作，或者在流图中将其阐释为以特定次序发生，但除非特别说明，否则 不必要求任何特定排序，或者由于一动作依赖于在执行该动作之前完成的另一动作而要求 特定排序。现在参见图3，阐释诸如图1中的节点102、110和104等的服务器节点的操作。图 3阐释方法300。方法300包括接收消息的动作(动作302)。可以从诸如网络介质、计算机 总线或其他通信介质等的计算机可读通信介质接收该消息(例如消息114)。方法300还包括计算该消息的各特性性质以便确定用于该消息的处理的一服务(例如服务102、104或110中的一个)处的服务实例(例如服务实例116中的一个)的状 态要求(动作304)。在一些实施例中，如以上在上面的图2A-2D以及所附描述中所阐释，可 以执行计算各特性性质。方法300还包括尝试获得满足用于处理消息114的状态要求的适当的服务实例 (例如服务实例116)。在308，判定框阐释取决于该尝试是否成功而执行的不同动作。当尝 试获得满足用于处理该消息的状态要求的适当的服务实例116在获得适当的服务实例116 中是成功的时，基于状态要求处理该消息(动作310)。或者，方法300可以包括判断尝试获 得满足用于处理该消息的状态要求的适当的服务实例116在获得适当的服务实例116中是 不成功的，且作为结果，使用路由信息不可靠的本地缓存且在没有各处理节点之间的协调 的情况下来重定向消息114(动作312)，以便尝试使得消息114到达具有适当的服务实例 116或者可以成功地获得满足用于该消息的处理的状态要求的适当的服务实例116的服务 器节点。尽管未在图3中阐释，但方法300还可以包括对消息114执行独立于服务实例116 的处理。独立于服务实例116的处理的示例是执行静态配置的协议和消息变换。现在更详细地阐释方法300的细节，在消息到达诸如节点102、104或110等的服 务器节点时，可以作出该服务器节点满足消息114的处理要求的初始假定。在对消息114 执行某种量的处理之后，该服务器节点达到进一步的处理要求服务实例116的点。为了标识适当的服务实例116，该服务器节点可以使用该消息和本地可用的状态 但在没有各处理节点之间的协调的情况下计算特性性质。例如，如果消息114到达服务器 节点110，则服务器节点110可以使用消息114和本地可用的状态但在没有其他处理节点 106、102和104之间的协调的情况下来计算特性性质。特性计算由应用程序定义。特性可 以是来自消息传送过程的信息、该消息的部分或者甚至整个消息本身。作为示例，该服务器 节点可以标识该消息是具有特定格式的采购定单请求、标识该采购定单格式包括在固定位 置处的采购定单标识符、以及提取该采购定单标识符以便形成该特性。然后，该服务器节点咨询实例协调器112，以便获得具有该特性的适当状态的适当 的服务实例116。此咨询可以包括由实例协调器112原子执行的若干动作具体地，该咨询可以包括判断是否已经存在与这一特性相关联的服务实例116。例 如，实例协调器112可以判断是否有适当的服务实例116存在于实例协调器112处或网络 100中的任何处理节点处。如果不存在具有该特性的服务实例116，则创建新的服务实例 116，且将服务实例116与该特性关联起来。如果存在具有该特性的服务实例116，则该咨 询可以包括判断服务实例116存在于何处。服务实例116可以已经存在于进行请求的服务 器节点(在本示例中是服务器节点110)处。如果服务实例116存在于实例协调器112处， 则服务实例116被传递到请求服务器节点110。如果服务实例116存在于诸如服务器节点 102或104等的某个其他服务器节点处，则实例协调器112可以拒绝该负载请求并将出错 消息传输给服务器节点110。出错消息包括该服务实例116当前存在于其处的服务器节点 (例如102或104)的标识符。还可以在其中可以对服务实例116放置锁的环境中实现各实施例。在这些实施例 中的一些中，可以包括用于在实例协调器112确定适当的服务实例116被网络中的各处理 节点中的一个锁定时向进行请求的处理节点提供关于锁所有者的信息的功能。在一个实施例中，实例协调器112可以将关于服务实例116上的锁的信息提供给进行请求的系统。作为获得服务实例116的部分，服务器节点110可以提供它希望使之与服务实例 116关联的一个或多个附加特性。尽管这些附加特性不被用作初始查找的部分，但在执行关 联之后，对附加特性中的一个的将来的查找将匹配服务实例116。如果服务器节点110包 括附加特性，则作为原子创建或负载过程的部分而执行这些关联，并且在一些实施例中，只 有当该创建或负载过程成功获得服务实例116时才执行这些关联。具体地，尝试从实例协 调器112获得适当的服务实例116可以包括发送一个或多个附加特性。对于获得服务实例 116的这种尝试，不考虑这些附加特性，但是，如果该处理节点在获得适当的服务实例116 的尝试中是成功的，则这些附加特性被添加到描述服务实例116的多个特性。作为示例，服 务器节点110可以使用从采购定单标识符导出的特性来查找服务实例116，并且提供从发 货人跟踪号导出的附加特性。将来，即使不知道采购定单标识符，也可以使用发货人跟踪号 来寻找服务实例116。因而，在一些实施例中，实例协调器将多个特性与各服务实例关联起 来。尝试从实例协调器获得适当的服务实例可以包括将各特性中的任何一个或多个发送给 实例协调器且无需发送与该服务实例相关联的所有特性。在所阐释的示例中，可以提供采 购定单标识符或发货人跟踪号中的任一个且无需提供其他标识符或号。在本发明的一些实施例中，实例协调器112接受多于一个的用于查找的特性，并 返回匹配各特性中的任何一个的服务实例116。在各特性不唯一地定义服务实例116时的 结果可以是基于特性规范的性质支持特定的服务实例116、基于服务实例116的性质支持 特定的服务实例116、或者因被含糊地指定而拒绝该查找操作。在一些实施例中，服务器节点110维护其当前拥有的服务实例116的本地目录。此 本地目录允许该服务器节点制止在不存在要执行的附加关联时咨询实例协调器112。在一些实施例中，如果服务器节点110成功获得服务实例116，则其将所接收的消 息114分派给应用程序的剩余部分。否则，服务器节点110构造含有由该实例协调器返回 的地址的重定向消息并指示该消息的发送方将该消息转发到此新地址。例如，假设实例协 调器112指示特定的服务实例116-3位于服务器节点104。服务器节点110可以构建指示 消息114应被转发到服务节点104的重定向消息120，该重定向消息120被发送到路由器节 点106(路由器节点106将消息114发送给服务器节点110)。在一些实施例中，新地址不是物理机器地址。例如，它可以是要在消息的发送方已 知的目录中查找的逻辑地址或服务名称。作为另一示例，可以使用动态发现协议而非目录 服务来决定该新地址。在一些实施例中，不同于提供路由该消息所严格要求的信息，实例协调器112提 供用于服务实例116的路由信息以便改善总体路由质量。来自服务器节点110或其他路由器节点的重定向消息可以含有在各特性性质和 各处理节点之间的一个或多个附加关联。附加特性性质并不必与当前正被处理的消息相 关。可以根据该一个或多个附加关联更新不可靠的本地缓存。下列描述一般地包括关于路由器节点(例如路由器节点106和110)的功能的进 一步细节。另外，可以包括关于处理重定向消息120的各细节。图4阐释方法400。方法400包括接收一消息(动作40 。可以从计算机可读通 信介质接收该消息。方法400还包括计算该消息的各特性性质以便判断对用于该消息的处理的一服务处的服务实例116的状态要求(动作404)。方法400包括使用路由信息不可靠 的本地缓存且在没有各处理节点之间的协调情况下，判断该消息的可能路线(动作406)。 根据该消息的可能路线，将该消息定向到服务器节点或另一路由器节点。可以执行方法400以便执行独立于服务实例116(见图1)的处理。独立于服务实 例116的处理的示例是执行静态配置的协议和消息变换。在诸如节点110等的路由器-服务器节点的情况中，该服务器节点可以是同一处 理节点的服务器组件。在一些方面中，路由器节点的操作类似于服务器节点的操作。然而，代替向诸如实 例协调器112等的权威来源咨询服务实例116，诸如路由器节点106等的路由器节点咨询潜 在地不可靠的本地路由数据。例如，路由器节点106可以包括含有潜在地不可靠的本地路 由数据的路由表118-2。路由器节点106可以不时地患有健忘症，这使得它忘记路由数据 中的一些或所有；或者，由于错误的猜想而包括了错误的路由数据。不存在以及时方式或甚 至确实告知路由器节点106各处理节点已经被添加到网络100或从网络100移除、各处理 节点已经改变改变它们的类型或者与其他处理节点的连接性、或者服务实例116从一个位 置移动到另一位置的期望。路由器节点106使用路由表118-2中的路由数据来作出正确路 线的最好的猜想判断。最好猜想可以基于先前所路由的消息114和来自先前在重定向消息 120中接收的实例协调器112的路由数据等。在一些实施例中，最好猜想包括诸如循环负载平衡等的负载平衡机制，或将各消 息定向到被认为未充分利用的各处理节点。当路由器节点106接收其先前所路由的消息114的重定向消息120时，路由器节 点106决定如何处理路由故障。取决于传送机制、特性和路由数据，路由器节点106本身可 以转发消息114。在其他情况中，路由器节点106可以将重定向消息120返回给原始的发 送方。例如，尽管未在图1中阐释，但另外的路由器节点可能已经将消息114传输到路由器 节点106。路由器节点106可以使用表118-2中的不可靠的本地路由数据来判断该消息应 被发送到路由器节点110。路由器节点110可以判断消息114被错误地发送到路由器节点 110。响应于此判断，路由器节点110将重定向消息120发送给路由器节点106。在一些实 施例中，路由器节点110还可以发送指示哪个节点被认为是消息114的正确处理节点的信 息。可以从本地路由表118-1的不可靠信息或者从来自实例协调器112的可靠协调信息导 出这种指示哪个节点被认为是消息114的正确处理节点的信息。响应于该重定向消息，路 由器节点106可以将消息114转发给重定向消息120中所指示的处理节点。在一些实施例中，如果可能，路由器节点总是返回重定向消息。从单工消息源接收 到的消息被转发，而从双工消息源接收到消息返回重定向消息。本发明的各实施例可以包括或利用包括计算机硬件在内的专用或通用计算机，如 下面更详细地讨论。本发明的范围内的实施例还包括用于运载或存储计算机可执行指令和 /或数据结构的物理介质和其他计算机可读介质。这样的计算机可读介质可以是可由通用 或专用计算机系统访问的任何可获得的介质。存储计算机可执行指令的计算机可读介质是 物理存储介质。运载计算机可执行指令的计算机可读介质是传输介质。因而，作为示例而 非限制，本发明的各实施例可以包括至少两种截然不同的计算机可读介质物理存储介质 和传输介质。
物理存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光学盘存储、磁盘存储或其他 磁存储设备、或者可以用来存储以计算机可执行指令或数据结构的形式的所期望的程序代 码方法且可由通用或专用计算机访问的任何其他介质。“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子 数据的一个或多个数据链路。当在网络或另一通信连接(硬布线、无线或硬布线或无线的 组合)上将数据传递或提供给计算机时，该计算机适当地将该连接看作是传输介质。传输 介质可以包括可以用来运载以计算机可执行指令或数据结构的形式的所期望的程序代码 方法且可由通用或专用计算机访问的网络和/或数据链路。以上的组合也应被包括在计算 机可读介质的范围内。进一步，一旦到达各种计算机系统组件，以计算机可执行指令或数据结构的形式 的程序代码方法就可以被自动地从传输介质传递到物理存储介质(或反之亦然)。例如， 在网络或数据链路上所接收的计算机可执行指令或数据结构可以被缓冲在网络接口模块 (例如，“NIC”)内的RAM中，且然后，最终被传递到计算机系统RAM和/或被传递到在计算 机系统处的较不易失性物理存储介质。因而，应理解，物理存储介质可以被包括在还利用 (或甚至主要利用)传输介质的计算机系统组件中。计算机可执行指令包括例如弓I起通用计算机、专用计算机或专用处理设备执行某 些功能或功能组的指令和数据。计算机可执行指令可以是例如二进制数、诸如汇编语言等 的中间格式指令或甚至源代码。尽管已经用对结构特征和/或方法论动作来说专用的语言 描述了本主题，但应理解，在所附权利要求中界定的本主题不必限于以上所描述的所描述 的特征或动作。相反，所描述的特征和动作是作为实现权利要求的示例形式而公开的。本领域的技术人员应明白，可以在具有多种类型的计算机系统的网络计算环境中 实践本发明，这些多种类型的计算机系统包括个人计算机、台式计算机、膝上型计算机、消 息处理器、手持式设备、多处理器系统、基于微处理器的或可编程的消费性电子设备、网络 PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。还可以在分布式 系统环境中实践本发明，分布式系统环境中，通过网络而(被硬布线数据链路、无线数据链 路、或硬布线和无线数据链路的组合)连接的本地计算机系统和远程计算机系统两者均执 行任务。在分布式系统环境中，程序模块可以位于本地存储器存储设备和远程存储器存储 设备两者。可以在不偏离其精神或必要特性的前提下以其他具体形式实现本发明。在所有方 面，所描述的实施例都应被认为仅仅是说明性的且不是限制性的。因此，本发明的范围由所 附权利要求而非由前述的描述来指示。在权利要求的等效性的意义或范围内的所有改变都 应被包含在它们的范围内。
权利要求
1.在计算环境中的处理节点处，一种使用不可靠的路由数据来路由消息的方法，所述 方法包括从计算机可读通信介质接收消息(动作302)；计算所述消息的一个或多个特性性质，以便判断用于所述消息的处理的、服务处的服 务实例的状态要求(动作304)；尝试获得满足用于处理所述消息的所述状态要求的适当的服务实例，其中当尝试获得 满足用于处理所述消息的所述状态要求的适当的服务实例在获得适当的服务实例中是成 功的时候，基于所述状态要求处理所述消息(动作306)；判断尝试获得满足用于处理所述消息的所述状态要求的适当的服务实例在获得适当 的服务实例中是不成功的，且作为结果，使用路由信息不可靠的本地缓存且在没有各处理 节点之间的协调的情况下来重定向所述消息，以便尝试使得所述消息到达具有适当的服务 实例或可以成功地获得满足用于所述消息的处理的所述状态要求的适当的服务实例的服 务器节点(动作308和310)。
2.如权利要求1所述的方法，其特征在于，还包括在计算所述消息的一个或多个特性 性质之前对所述消息执行独立于所述服务实例的处理。
3.如权利要求2所述的方法，其特征在于，尝试获得满足用于处理所述消息的所述状 态要求的适当的服务实例包括尝试从实例协调器获得适当的服务实例，其中所述实例协调 器存储网络中未被所述网络中的各处理节点持有的所有服务实例。
4.如权利要求3所述的方法，其特征在于，还包括当所述实例协调器判断在所述实例 协调器处或者在所述网络中的所述处理节点中的任何处不存在适当的服务实例时创建新 的适当的服务实例的动作。
5.如权利要求3所述的方法，其特征在于，还包括当所述实例协调器判断所述适当的 服务实例被所述网络中的所述各处理节点中的一个锁定时向进行请求的处理节点提供关 于锁所有者的信息的动作。
6.如权利要求3所述的方法，其特征在于，所述实例协调器将多个特性与各服务实例 关联起来，且其中尝试从实例协调器获得适当的服务实例包括发送一个或多个附加特性， 对于获得服务实例的这一尝试，不考虑所述附加特性，但是，如果所述处理节点在获得适当 的服务实例的尝试中是成功的，则所述附加特性被添加到描述所述服务实例的所述多个特 性中。
7.如权利要求3所述的方法，其特征在于，所述实例协调器将多个特性与各服务实例 关联起来，且其中尝试从实例协调器获得适当的服务实例包括将所述各特性中的任何一个 或多个发送给所述实例协调器，且无需发送与所述服务实例关联的所述各特性中的全部。
8.在计算环境中的处理节点处，一种使用不可靠的路由信息来路由消息的方法，所述 方法包括从计算机可读通信介质接收消息(动作402)；计算所述消息的一个或多个特性性质，以便判断用于所述消息的处理的、服务处的服 务实例的状态要求(动作404)；使用路由信息不可靠的本地缓存且在没有各处理节点之间的协调的情况下，基于所述 状态要求确定所述消息的可能路线(动作406)；以及根据所述消息的所述可能路线将所述消息定向到服务器节点或另一路由器节点(动 作 408)。
9.如权利要求8所述的方法，其特征在于，将所述消息定向到服务器节点包括将所述 消息定向到所述处理节点的服务器组件。
10.如权利要求9所述的方法，其特征在于，将所述消息定向到服务器节点包括引用存 在于所述处理节点处的服务实例的本地目录。
11.如权利要求8所述的方法，其特征在于，确定所述消息的可能路线包括使用用于路 由消息的负载平衡机制。
12.如权利要求8所述的方法，进一步包括从所述服务器节点或其他路由器节点接收指示所述消息应被发送到不同的处理节点 的重定向消息；以及更新所述不可靠的本地缓存以便指示带有所述消息的一个或多个特性性质的各消息 应被路由到所述不同的处理节点。
13.如权利要求12所述的方法，其特征在于，来自所述服务器节点或其他路由器节点 的所述重定向消息含有各特性性质和各处理节点之间的一个或多个附加关联，所述附加特 性性质与当前正被处理的所述消息不相关，所述方法还包括根据所述一个或多个附加关联 更新所述不可靠的本地缓存的动作。
14.如权利要求12所述的方法，其特征在于，还包括判断如何通过将所述消息定向到 所述不同的处理节点来响应于所述重定向消息。
15.如权利要求12所述的方法，其特征在于，还包括判断如何通过将重定向消息提供 给从其接收所述消息的所述系统来响应于所述重定向消息。
16.如权利要求12所述的方法，其特征在于，还包括使用目录服务协议来解析所述重 定向消息。
17.如权利要求12所述的方法，其特征在于，还包括使用发现协议来解析所述重定向消息。
18.如权利要求8所述的方法，其特征在于，还包括在计算所述消息的一个或多个特性 性质之前对所述消息执行独立于所述服务实例的处理。
19.如权利要求8所述的方法，其特征在于，还包括在计算所述消息的一个或多个特性 性质之后对所述消息执行独立于所述服务实例的处理。
20.在一个计算环境中，一个被配置成在网络中路由消息系统，所述系统包括一个或多个处理器；存储被配置成由处理器执行以便实现各计算机模块的计算机可执行指令的计算机可 读存储介质，其中所述各计算机模块包括被配置成计算消息的一个或多个特性性质(114)以便判断用于所述消息的处理的、服 务处的服务实例的状态要求的计算器模块O20)；实例协调器模块112，其中所述实例协调器112存储网络中未被所述网络中的各处理 节点(102，104，106，110)持有的所有服务实例116。服务节点模块(102，110，104)，其中所述服务节点模块被配置成尝试获得满足用于处 理所述消息(114)的所述状态要求的适当的服务实例(116)，其中当尝试获得满足用于处理所述消息的所述状态要求的适当的服务实例在获得适当的服务实例中是成功的时，基于 所述状态要求处理所述消息；以及路由器模块(106，110)，其中所述路由器模块被配置成使用路由信息不可靠的本地缓 存且在没有各处理节点之间的协调的情况下定向所述消息，以便尝试使得所述消息到达具 有适当的服务实例或者可以成功地获得满足用于所述消息的处理的所述状态要求的适当 的服务实例的服务器节点。
全文摘要
使用不可靠的路由数据来路由消息。一种方法包括从计算机可读通信介质接收消息。计算该消息的各特性性质，以便判断用于该消息的处理的、服务处的服务实例的状态要求。进行获得满足用于处理该消息的状态要求的适当的服务实例的尝试。作出尝试获得满足用于处理该消息的状态要求的适当的服务实例在获得适当的服务实例中是不成功的判断。作为结果，使用路由信息不可靠的本地缓存且在没有各处理节点之间的协调的情况下来重定向该消息。
文档编号H04L12/56GK102144373SQ200980135193
公开日2011年8月3日 申请日期2009年8月13日 优先权日2008年9月3日
发明者E·S·平特, J·A·泰勒, J·D·布朗, K·拉曼, N·A·艾伦, S·R·巴特雷斯 申请人:微软公司