CN101945056A - 基于策略的jms中间件群的系统和/或方法 - Google Patents

Abstract

此处揭示的实施例涉及基于策略的JMS中间件群的系统和/或方法，尤其涉及，建立在发布-订阅模型(或其类似)上的应用整合技术。在具体实施例中，提供了发布应用，以及第一和第二中间件群。每一个中间件群包括多个中间件，且每一个中间件被配置为从发布应用向至少一个订阅应用中继消息。复合群连接与发布应用连接，而群连接则与复合群连接。发布应用产生的消息依据使用者定义的复合策略被发送给中间件群。基于第一策略层，消息被从复合群连接路由至至少一个群连接。基于第二策略层，消息被从至少一个群连接路由至至少一个中间件。

Description

基于策略的JMS中间件群的系统和/或方法

技术领域

本发明实施例在此公开的内容设计应用整合技术，尤其涉及，基于发布-订阅(publish-and-subscribe)模型(或与其类似的模型)的应用整合技术。在本发明的具体实施例中提供了在中间件群中的，基于客户(client)的以策略为导向的负载平衡特性组织的传递消息的中间件。本发明实施例中的负载平衡策略可以是“可分层的(layerable)”，这使得用户可以对复合且复杂的负载平衡特性进行定义。

背景技术和发明内容

如今的公司面临实现在其企业事务中的多类型整合的解决方案的挑战。这些挑战中的多数与应用整合(如，软件应用和/或其他系统之间的整合)问题有关，同时这些挑战也也具有类似的模式。

举例来说，第一个与上述描述有关的环境涉及从一个系统到多个其他系统的相似业务的增长，比如，订购状态的变化或是产品价格的变化。第二个环境涉及在两个或多个系统之间的相似业务进行同步以得到单个视图(single view)，比如，在几个应用中的客户、产品登记、产品订购、以及产品SKU信息的实时同步的环境中。这是最常见的需要整合解决方案解决的问题。在单向同步中，每一个资源常常既是同步中的潜在的起源又是目标。不存在作为初始数据资源的单独的资源。这样，任何资源发生的改变都应当反映到所有其他的资源中。第三个环境与将多个起源中的信息联合起来加入到通用的目标系统中有关，比如，将药店客户记录和药方的处理和网站数据联系起来形成中央应用和数据库。

目前可以利用多种工具来设计和实施解决方案以解决这些挑战，如，采用发布-订阅模型或与其类似的技术。发布-订阅模型是基于消息的解决方案类型中的一种，在基于消息的解决方案中消息以匿名的方式通过消息中间件(message broker)进行交换。产生共享信息的应用通过以发布至消息中间件的可识别文件的某种类型提供该信息。需要该信息的应用则订阅其需要的文件类型。

在运行阶段，消息中间件接收来自发布者的文件，然后将这些文件分发至订阅者。订阅应用(subscribing application)使用该文件来处理或执行对应的工作，并且可向发布应用(publishing application)发送或不发送响应。

在典型的系统中，整合服务器中运行的整合服务或应用向中间件发布文件。然后，中间件将这些文件路由到位于其他整合服务器的订阅者处。整合服务器和中间件共享迅速、高效的处理过程以便在整个系统中交换文件。

虽然这样的技术已经成功的用于为上述的各种环境中的问题提供解决方案，但是仍然还需要对其做进一步的改进。比如，整合服务器(integration server，IS)“触发子系统(Trigger System)”提供了用于消息处理(例如，异步消息处理)的丰富的基础结构。虽然，这个功能仅能用于基于专有的(如，中间件)消息协议的消息处理。这样，使用者现在需要进行艰难的设计决定，即在功能丰富的专有协议和标准的可互操作的消息协议(如，Java Message Service，即Java消息服务，简称JMS)之间择一使用。

解决该问题的一个途径涉及整合服务器中的JMS适配器(adapter)的使用。以便为整合服务器同时提供专有的“触发子系统”(由整合服务器提供用于专有消息处理)和独立的JMS适配器。

不幸的是，这种解决方案从某种意义上来说是不完整的。尤其是，不管标准的可互操作的消息处理的JMS适配器的可用性，“触发子系统”的功能并不能在与JMS的连接中被充分利用。想要在使用JMS适配器的同时扩展“触发子系统”的功能的使用者，必须定制执行(custom-implement)这些功能，在为每一个新的应用的应用中。这往往需要大量的配置和程序设计，并将导致过多的非标准的相同或/和相似功能的实施。由于JMS仍然处于标准化过程以便其可在网络服务上下文中进行使用，这个问题还会进一步加剧。本质上，这意味着，如果需要这些专有的中间件的相应的功能，那么需要在应用服务层一次又一次的执行这些功能。即使这些条件都能执行，它们也必然不是标准化的，因为，例如，公司的组织、流程、需求、基础设施等都是不同的。

这样，问题仍然在于，不存在一个单独的方法将现在的“触发子系统”和其所有的功能与基于标准的消息处理(如，通过JMS)联系起来。相应的，需要在功能丰富的专有协议和基于标准的可互操作的消息协议(如JMS)之间进行权衡。

需要考虑的是，在本领域中需要改进对上述涉及的和/或其他的一个或多个环境中对应用整合解决方案的技术进行改进。

如前述所述，克服这些和/或其他问题有关的技术的例子与提供消息层有关，该消息层可为解决应用整合问题提供丰富的功能设置，这可以通过在应用层外部存在的专有和开放的消息结构来实现。这样的消息结构可以是“触发器(triggers)”的形式，在具体的实施例中，这种触发器可以为这样的应用整合问题提供发布-订阅类型的解决方案。这些触发器可以是JMS触发器。

另一方面与可通过通用的触发子系统达到的平行子系统有关，该触发子系统作为相关的触发子系统上的附加值层。

还有一方面与潜在的完全嵌入的JMS有关，该JMS作为整合服务触发子系统中的专有消息协议的等同物，这样所有或潜在的所有的已存在的功能都可以被JMS使能。

还有一方面与消息层的使用有关，该消息层使得对JMS消息处理可以不使用整合服务器中的特定适配器。进一步的，该消息层可以避免对JMS触发器本身进行任何改变，并且/或可降低在应用服务层级对客户程序进行设计和/或执行的需要，在一些具体实施例中。

虽然这些中间件具有一些优点，但是仍然需要对其进行进一步的改进。比如，需要考虑对中间件进行改进以便扩展提供的负载平衡功能。实际上，本申请的发明人注意到，在最近的几年中，客户需要为其中间件应用提供失效备援(failover，或称故障切换)和负载平衡特性。

相应的，本发明的具体实施例中的一方面与使得中间件实现客户端的故障切换和负载平衡功能有关。在具体实施例中的负载平衡功能处于应用空间中，并且可对其进行扩展。

本发明的具体实施例的另一方面与使得负载平衡功能与中间件群一起工作有关。基于此，发布者和订阅者可与中间件群连接，中间件群中的中间件可以共享从发布者到订阅者的消息路由。

具体实施例的再一方面与提供通过一个或多个策略进行负载平衡功能有关，这些策略可能是“可叠堆的(stackable)”、“可分层的(layerable)”、或“复合的(compound)”。

本发明的具体实施例与应用整合系统有关。发布应用被配置为产生和发送消息。消息依照使用者定义的复合策略进行发送，该策略包括至少第一和第二策略层。提供第一和第二中间件群。每一个中间件群包括多个中间件，每一个中间件被配置成将消息从发布应用转发(relay，或称中继)到至少一个订阅应用。复合群连接与发布应用相连。多个群连接与复合群连接相连。复合群连接被配置为将消息按照第一策略层路由至至少一个群连接。每一个群连接被配置为将消息按照第二策略层路由至至少一个中间件。

本发明的具体实施例与应用整合系统中的消息路由方法有关。提供发布应用。提供第二中间件群。每一个中间件群包括多个中间件，每一个中间件被配置为将消息从发布应用转发到至少一个订阅应用。复合群连接与发布应用相连。多个群连接与复合群连接相连。通过发布应用产生消息。该消息按照使用者定义的包括至少第一和第二策略层的复合策略被从发布应用发送至中间件群。消息从复合群连接按照第一策略层路由至至少一个群连接。消息按照第二策略层从至少一个群路由至至少一个中间件。

本发明的具体实施例与调用应用整合系统中的目标服务的方法有关。提供第一和第二客户系统，这两个系统实施发布/订阅消息交换模型。提供至少一个中间件群，该中间件群包括多个中间件服务器。第一客户系统产生消息，该消息用于触发调用第二客户系统上的目标服务。该消息基于第一客户系统定义的策略从第一客户系统路由至在至少一个中间群中的至少一个中间件，再路由到第二客户系统。第二客户系统接收该消息。通过第二客户系统调用目标服务。

这些具体实施例和实施例的各方面可以分开使用，和/或进行不同的组合使用，以获得本发明的其他实施例。

附图说明

通过参考本发明实施例及其相关附图中的具体描述，可以更好和更全面的理解各个特点和优点：

图1是应用整合系统的组成示意图；

图2是当整合系统与中间件连接时，其如何向中间件发布或分发文件的示意图；

图3是当没有中间件时整合服务器如何发布文件的示意图；

图4是当请求/响应同步时，整合服务器向中间件发布文件并等待响应的示意图；

图5是整合服务器为已发布的文件进行订阅的路径的示意图；

图6是整合服务器为已分发至默认客户的文件进行订阅的路径的示意图；

图7是本地发布文档的发布和订阅路径的示意图；

图8是发布和订阅模型的整合解决方案中的两侧的示意图，其中，可发布的文档类型与相同中间件文档类型相连；

图9是当前的消息层的示意图；

图10是本发明实施例中的消息层的示意图；

图11是本发明实施例中的与产生中间件群有关的多个元素的示意图；

图12是本发明实施例中的基于负载平衡技术的公共应用接口的示意图；

图13～15是本发明实施例中的群连接、策略管理以及中间件选择的类的图表的示意图；

图16是本发明实施例中的负载平衡中间件JMS应用的结构示意图；

图17是本发明实施例中的负载平衡发布/订阅模型的具体实施有关的多个元素的示意图；

图18是本发明实施例中的基于循环(round robin)策略的负载平衡发布的流程序的示意图；

图19是本发明实施例中的当订阅者应用产生JMS连接时的群连接的示意图；

图20是本发明实施例中的采用中间件群的有保证的(guaranteed)多发送策略的具体示意图；

图21是本发明实施例中的执行了复合策略的负载均衡中间件JMS应用的结构的示意图；以及

图22～23是使用整合服务来调用发布服务和触发器的不同具体技术的示意图。

具体实施例

下面将对本发明实施例中的应用整合系统和操作方法进行描述。应当理解的是，下述的描述不应作为对本发明实施例的限制。实际上，下述描述的示例主要描述了通过一个发布-订阅方式解决实际应用中出现的与应用整合问题的有关技术，其可用在本发明实施例中的与消息层、触发器、以及触发子系统的连接中。

现在参考附图进行进一步说明，附图1是应用整合系统100的组成示意图。图中示意了多个整合服务器，每一个整合服务器都与中间件106通讯连接。其中，示意了第一整合服务器102、包括多个适配器108的第二整合服务器102’、以及包括多个适配器108’的整合服务器群102”。

总的来说，整合服务器是系统的中央运行阶段的组成组件。其作为需要整合的系统和应用的进入节点，并且也是系统的执行整合逻辑的主要引擎。其还提供了下层处理程序和设备，用于管理来自企业内部或/或外部的资源104(或资源群104’)的信息的有序处理。整合服务器102向中间件发布文档并接收来自中间件的文档。

本发明实施例中的中间件106形成了潜在的全局的可升级的消息传输主干。其提供了基于发布-订阅模型或其类似模型(例如，请求/响应、发布-等待等)的异步、基于消息的解决方案的执行基础架构。

中间件106在信息产生者(如，发布者)和信息消费者(如，订阅者)之间进行文档路由。这样，中间件106接收、排列、以及分发文档。中间件106保留其识别的注册文档类型。其还保留与接收这些文档类型有关的订阅者的列表。当中间件106接收发布的文档时，其为该文档类型的订阅者对该接收的文档进行排序。订阅者从其队列中取回文档。该动作常常会触发处理该文档的订阅者的系统上的动作(activity)。

系统100中可选择性包括多个(multiple)中间件106。多个中间件106可以按照组(称为区域)的形式进行操作，这使得几个中间件106可共享文档类型和订阅信息。

下述是对使用了发布-订阅模型的整合解决方案的基本组成模块的描述。这些组成模块包括，例如，文档、可发布的文档类型、触发器、服务、适配器通知、以及标准文档。

在基于发布-订阅模型的整合解决方案中，应用发布和订阅文档。文档是上述提及的组成组件用来封装和交换数据的对象。文档代表了资源传输至组成部分的数据的主体。通常，其代表业务事件诸如，发订单(例如，通过购买订单文档)、运送货物(例如，通过运送通知)、添加新员工(例如，通过新员工记录)等。

每一个发布的文档都包括封装。该封装更像电子邮件信息中的头部。封装记录诸如发送者地址、文档发送时间、序列号、和/或其他对路由或控制有用的信息。其还包括有关文档和其在系统中传送的信息。

每一个发布的文档都与可发布的文档类型有关。可发布的文档类型是已命名的类似图表的定义，其描述了可以被发布和订阅的特定的文档类型的结构。可发布的文档类型的实体可以在整合服务器内进行本地发布或是被发布至中间件。在包括中间件的公共环境中，每一个可发布的文档类型都必然是中间件的文档类型。中间件上的客户订阅可发布的文档类型。中间件使用可发布的文档类型来决定将文档分发至哪个客户。

在此处描述的本发明实施例的发布-订阅模型中，触发器建立对可发布的文档类型的订阅。触发器还明确将要处理通过该订阅接收的文档的服务。在触发器中，通过条件将一个或多个可发布的文档类型与服务关联起来。

服务是工作(work)中的类似方法的单元。其包括整合服务器执行的程序逻辑。服务可被建立来执行工作，诸如，从文档中抽取数据、与后端资源相互影响、向中间件发布文档等等。当触发器被建立时，使用者可以定义用来处理被订阅的文档的服务。

每当适配器的资源上发生特定的事件时，适配器通知(adapter notification)总是通知系统。当资源中发生特定的事件时，适配器通知发布文档。每一个适配器通知包括相关的可发布的文档类型。触发器可以用来订阅与适配器通知有关的可发布的文档类型。与触发状态下的与可发布的文档类型有关的服务可，如，执行一些额外的处理、更新、和/或同步，如，基于适配器通知内容的。

标准文档是当文档在系统中传输时的可能的标准表现形式。标准文档作为各资源间的中间数据形式。例如，从企业接收购买订单的执行实例中，流程中的一个步骤可能是将购买订单文档转换为企业的标准购买订单格式。该格式被称为购买订单文档的“标准(canonical)”格式。该标准文档可被发布、发送、以及传输至处理购买订单的服务。

通过将文档转换为中性的中间格式，订阅者(如，适配器服务)仅仅需要知道如何将标准文档转换为所需的应用格式即可。如果不使用标准文档，那么每一个订阅者都必须可对每一个发布者的原始文档格式进行解码。

标准文档为可发布的文档类型。当建立发布服务时可使用标准文档，当建立触发器时其被订阅。在流服务(flow services)中，可以将文档从应用的原始格式映射为标准格式。

如图2～7所示，为订阅-发布路径的原理示意图。如前所述，整合服务器通过订阅和发布交换文档。一个整合服务器发布文档，而一个或多个整合服务器订阅并处理该文档。整合服务器通常与中间件交互来发布和订阅文档。举例来说，整合服务器可向中间件发布文档，整合服务器可从中间件取回文档，和/或整合服务器可在本地发布和订阅文档。

当整合服务器被配置为与中间件连接时，该整合服务器可以向中间件发布文档。然后，中间件将文档路由至所有的订阅者。如下所述为3种发布路径情况的示例：向中间件发布文档，当中间件不可用时向中间件发布文档，向中间件发布文档并等待响应(如，类似请求/响应场景)。如果没有为整合服务器配置中间件，所有的发布都可能变成本地发布，并且也不能实现向特定的接受者发布文档。以下将对该可能性进行详细描述。

如图2所示，为当与中间件连接时整合服务器如何发布和订阅文档的示意图。当整合服务器向已配置的中间件发送文档时，该整合服务器发布或分发该文档。当整合服务器发布文档时，其可能被广播发送往所有的订阅者。中间件将文档路由至所有已订阅了该文档的客户。当整合服务器分发文档时，该分发请求明确文档的接受者。中间件仅为特定的客户对文档进行排队。

整合服务器102中的发布服务202向分配器204发送文档(或当资源中产生事件时适配器通知发布文档，适配器监视)(步骤S201)。在整合服务器102向分配器204发送文档之前，验证文档的可发布的文档类型。如果文档是无效的，服务202返回指示无效错误的异常响应。分配器204从连接池206处获得连接208(步骤S202)。该连接池206是连接208的预先定义的集合，整合服务器102采用该连接向中间件106发布文档。为向中间件106发布文档，整合服务器102使用连接208作为默认客户的连接。分配器204向中间件106发送文档(步骤S203)。

中间件106为文档检查存储类型，以决定如何存储该文档(S204)。例如，如果文档为易失的(volatile)，则中间件106可将该文档存储在内存210。如果文档为有保证的(guaranteed)，则中间件106可将该文档存储在内存210和/或在磁盘212上。

中间件106将文档路由至订阅者(步骤S205)。如果文档已经发布(如，广播)，中间件106确认订阅者，并为每一个订阅者在客户队列(如，第一和第二客户队列214a～b)中生成该文档的副本。如果文档被分发，中间件106将文档置于特定分发请求中的客户的队列中(如，第一和第二客户队列214a～b)。如果该文档没有订阅者，则中间件106向发布者202返回确认，并接着丢弃文档。如果，存在文档的死亡信件(deadletter)订阅，则中间件106将文档置于包括死亡信件订阅的队列中(例如，第一和/或第二客户队列214a～b)。在中间件106中文档一直保留在队列中(如，第一和/或第二客户队列214a～b)直到订阅客户被拾获。可以预先设定存活时间，例如，通过用户设定。如果文档为有保证的，中间件106向分配器204返回确认信息以提示文档被成功的接收和存储(步骤S206)。分配器204将连接208返还给连接池206。整合服务器102向发布服务202返还控制以执行下一步骤(步骤S207)。

可以对可发布的文档类型和整合服务器102进行配置，这样当文档被发布时整合服务器102不会验证文档。同时，当整合服务器102发布文档发生传输错误时，审核子系统可记录该文档并将其标记为“失败(FAILED)”状态。传输错误是根据条件产生的错误，可被迅速的解决，例如，与网络连接的资源不可用或不可以连接到数据库。可使用监测器来发现和重发状态为“失败”的文档。

如图3所示，为当中间件不可用时整合服务器如何发布文档的原理示意图。简而言之，整合服务器102不断的检测其与中间件106之间的连接208，如果其确定已配置的中间件106不可用则可改变发布路径。如果没有与中间件106连接，整合服务器106可将有保证的文档路由至出站文档存储302。文档可保留在出站文档存储302中直到与中间件106的连接208重新建立起来。

整合服务器102中的发布服务202向分配器204发送文档(或当资源中发生事件时适配器通知发布文档，适配器监视)(步骤S301)。在整合服务器102向分配器204发送文档之前，验证文档的可发布文档类型。如果文档是无效的，服务202返回指示无效错误的异常响应。分配器204检测到中间件106不可用。相应的，存储该文档。例如，如果文档是有保证的，分配器204将文档路由至出站文档存储302中(例如，在磁盘上)。如果文档是易失的，分配器204丢弃文档，同时发布服务发出异常响应。整合服务器102执行发布服务中的下一步骤。

当整合服务器102重新建立起与中间件106的连接时，整合服务器102从连接池206处获得连接208(步骤S303)。整合服务器102自动从出站文档存储302中向中间件106发送文档(S304)。为更迅速的清空出站文档存储302，整合服务器102可以一次发送一批文档。应当理解的是，整合服务器102可使用单一连接208来清空出站文档存储302，例如，以保存已发布的命令。

中间件106为文档检查存储类型，如果确定文档为有保证的，则将该文档存储在内存210和磁盘212上(S305)。中间件106将文档路由至订阅者(步骤S306)。如果文档已经发布(如，广播)，中间件106确认订阅者，并为每一个订阅者在客户队列(如，第一和第二客户队列214a～b)中生成该文档的副本。如果文档被分发，中间件106将文档置于特定分发请求中的客户的队列中(如，第一和第二客户队列214a～b)。如果该文档没有订阅者，则中间件106向发布者202返回确认，并接着丢弃文档。如果，存在文档的死亡信件订阅，则中间件106将文档置于包括死亡信件订阅的队列中(例如，第一和/或第二客户队列214a～b)。在中间件106中文档一直被保留在队列中(如，第一和/或第二客户队列214a～b)直到订阅客户被拾获。可以预先设定存活时间，例如，通过用户设定。如果文档为有保证的，中间件106向分配器204返回确认信息以提示文档被成功的接收和存储(步骤S206)。分配器204将连接208返还给连接池206。中间件106向整合服务器102返回确认信息以提示文档被成功的接收和存储(S307)。整合服务器102向发布服务202返还控制以执行下一步骤(步骤S307)。整合服务器102从出站文档存储302中移除文档。

当中间件106不可用时，可以通过将已发布的文档置于出站文档存储302以保留该文档，整合服务器102被配置为替代的发出异常响应。当与中间件106的连接被重新建立时，整合服务器102可以将所有新的已发布的文档(例如，易失的和有保证的)发送至出站文档存储302，直至出站文档存储302被清空。这样，整合服务器102可以保持发表的次序。在整合服务器102清空出站文档存储之后，整合服务器102可以重新直接向中间件106发布文档。

如果整合服务器102具有一个确定的尝试次数来从出站文档存储302中向中间件106发送文档，当所有次的尝试均失败时，审核子系统可记录该文档并标记其状态为“多次尝试失败(TOO MANY TRIES)”。当整合服务器102发布文档时如果产生传输错误，审核子系统可记录该文档并标记其状态为“失败(FAILED)”。可以对可发布的文档类型和整合服务器102进行配置，这样，当文档被发布时整合服务器102不对其进行验证。可以使用检测器来发现和重发状态为“多次尝试失败”或“失败”的文档。

如图4所示，为整合服务器向中间件发布文档并等待响应(reply)的示意图，其中请求/响应为同步的。在发布-等待情况下，服务发布文档(如，请求)，然后等待响应文档。有时称之为请求/响应模型。请求/响应可以是同步或异步的。在同步请求/响应中，在等待响应时发布流服务停止执行。当服务收到来自特定客户的响应文档时，服务继续执行。在异步请求/响应中，在发布请求文档后发布流服务连续执行。即是说，发布服务在执行流服务中的下一步骤前不会等待响应。发布流服务调用单独的服务来取回响应文档。

发布服务202向分配器204发送文档(例如，请求)(步骤S401)。整合服务器102以独一无二的标识在文档封装中填入标记域，以用来与该请求的响应文档进行匹配。发布服务202进入等待状态。发布服务202不进行后续动作直到其收到来自订阅者的响应或是达到等待时间。整合服务器102可在其一发布文档时就开始对等待时间进行计时。在整合服务器102向分配器204发送文档之前，其可验证文档的可发布文档类型。如果文档是无效的，服务202可返回代表无效错误的异常信息。然后，服务202可在发出异常信息的同时解除阻塞(unblock)

分配器204从连接池206处获得连接(步骤S402)。该连接池206是连接208的预定集合，整合服务器102采用该连接向中间件106发布文档。为向中间件106发布文档，整合服务器102使用连接208作为请求/响应客户的连接。如果中间件106不可用，分配器204可将文档路由至出站文档存储302，如按照如前所述的方法。分配器204向中间件106发送文档(步骤S403)。

中间件106为文档检查存储类型，以决定如何存储该文档(S404)。例如，如果文档为易失的，则中间件106可将该文档存储在内存210。如果文档为有保证的，则中间件106可将该文档存储在内存210和磁盘212上。中间件106将文档路由至订阅者(步骤S405)。如果文档已经发布(如，广播)，中间件106确认订阅者，并为每一个订阅者在客户队列(如，第一和第二客户队列214a～b)中生成该文档的副本。如果文档被分发，中间件106将文档放置在特定分发请求的客户的队列中(如，第一和第二客户队列214a～b)。如果该文档没有订阅者，则中间件106向发布者202返回确认，并接着丢弃文档。如果，存在文档的死亡信件订阅，则中间件106将文档置于包括死亡信件订阅的队列中(例如，第一和/或第二客户队列214a～b)。在中间件106中文档被一直保留在队列中(如，第一和/或第二客户队列214a～b)直到订阅客户被拾获。可以预先设定存活时间，例如，通过用户设定。如果文档为有保证的，中间件106向分配器204返回确认信息以提示文档被成功的接收和存储(步骤S406)。分配器204将连接208返还给连接池206。

订阅者取回并处理文档(S407)。订阅者采用服务(图中未示)来组成和发布响应文档。该服务自动在响应文档封装的标记域填入与请求文档封装的标记域中填入的值相同的值。该服务还自动的确定请求客户作为响应文档的接受者。一个或多个订阅向中间件106发送响应文档(S408)。中间件106将该响应文档存储在，如，内存210处。中间件106将响应文档置于为发起该请求的整合服务器102设置的请求/响应客户队列402中。

发起该请求的整合服务器102从连接池206中获取请求/响应客户，并从中间件106中取回响应文档(S409)。整合服务器102利用响应文档的标记域与原始请求的进行匹配(S410)。整合服务器102将响应文档置于等待服务404的流水线(pipeline)中(S411)。等待服务重新执行。

如果请求服务为响应文档定义了可发布的文档类型，则响应文档需要符合该特定的与之类似的类型。否则，响应文档可以是任意的可发布的文档类型。需要注意的是，单个请求可以接收多个响应。发起请求的整合服务器102可以仅使用其从中间件106取回的第一响应文档。整合服务器102也可以丢弃其他所有的响应。对“第一”可以进行任意的解释。中间件106处理到达的响应的次序中可以不提供保证。

所有的响应文档都可被当做易失的文档。易失文档可以存储在内存210中，并且如果响应文档所处于的资源关闭了或者在响应文档传输过程中连接208丢失了该响应文档可能丢失。

如果在服务接收响应之前已经经过了等待时间，整合服务器102可结束请求，而该服务可返回空文档以提示请求超时。整合服务器102可执行流服务中的下一个步骤。如果响应文档在流服务重新执行之前后到达，整合服务器102可拒收该文档并产生日志记录消息说明由于没有线程在等待该文档所以拒收该文档。可发布的文档类型和整合服务器102可以被配置为，当文档发布时整合服务器102不验证文档。

当整合服务器与中间件连接时，文档在订阅侧经历的路径包括，例如，从中间件取回文档，在整合服务器上存储文档，以及处理文档。文档的订阅路径可能取决于文档是向所有的订阅者发布(例如，广播)还是直接向整合服务器分发。

如图5所示，为整合服务器订阅已发布的文档的路径的示意图。当发布或广播文档时，中间件针对每一订阅触发器将文档的副本置于客户队列中。每一订阅触发器将取回和处理文档。

整合服务器102中的分配器204采用服务线程来请求中间件106上的触发器的客户队列214a中的文档(S501)。需要说明的是，整合服务器102上的每一个触发器可具有处于中间件106上的相应的客户队列。线程为触发器取回批量文档(S502)。分配器204将文档置于触发器文档存储502中的触发器队列214a中(S503)。可将触发器文档存储502存储在，例如，内存210中。然后，分配器204释放用于取回文档的服务线程。

分配器204从服务线程池(图中未示)中获得线程，从触发器队列214a中拉取文档，并评估在触发器中的文档的条件(S504)。如果为触发器配置了仅发生一次(exactly-once)的处理流程，则整合服务器102可先确定文档是否为已经被触发器处理过的文档的副本。在这种情况下，仅当文档是新的的时候，整合服务器102才会连续处理文档。

如果文档符合触发器条件，分配器204执行与该条件有关的触发器服务(S502a)(S504)。如果文档不符合触发器条件，整合服务器102可丢弃文档，向中间件106返回确认信息，并将服务线程返回至服务线程池。整合服务器102也可产生日志记录消息记录该文档没有与条件匹配。

触发器服务执行至结束(如，成功或错误)(S506)。如果触发器服务502a成功的执行了，整合服务器102向中间件106返回确认信息(例如，如果这是有保证的文档)。然后，整合服务器102从触发器服务214a中移除文档的副本，并将服务线程返回至服务线程池。如果产生服务异常，触发器服务502a以错误结束，整合服务器102拒收文档。如果文档是有保证的，整合服务器102向中间件106返回确认信息。整合服务器102从触发器队列214a中移除该文档副本，将服务线程返回至服务线程池中，并发送错误文档以指示产生了错误。如果在触发器服务执行期间产生了传输错误，服务获取该错误，将其覆盖(wraps)并重新作为异常丢弃，然后，整合服务器102等待重试间隔时长(该重试间隔可以被预先定义和/或由用户定义)并使用原始文档作为输入重新执行该服务。如果整合服务器102达到最大重试次数(也可以被预先定义和/或由用户定义)，并且触发器服务502a由于传输错误仍然失败了，整合服务器102将最后一次失败作为服务错误处理。

当收到确认信息后，中间件106可从有保证的存储212中移除文档的副本。整合服务器102可仅为有保证的文档返回确认信息。如果整合服务器102在确认有保证的文档之前关闭或重连与中间件106的连接，则当服务重启或连接重新建立时，整合服务器102可从中间件106处重新获得该文档。这样，文档可被重新分发。如果触发器服务产生了基于错误的审核数据并包括审核记录中输入流水线的副本，监测器可用来在稍后的时间重新调用触发器服务。

在触发器中，文档可能满足一个以上的条件。然而，整合服务器102可能仅执行与第一被满足的条件相关的服务。触发器的处理模式决定了整合服务器102以连续的还是同时的方式处理触发器队列中的文档。在连续处理中，整合服务器102按照文档在触发队列中的次序一次处理一个文档。在同时处理中，整合服务器102一次处理其可处理的多个文档，但是不一定按照文档在队列中的顺序处理。需要说明的是，在同时处理中，整合服务器102一次可处理的文档数目取决于可用线程的最大数目，这在具体实施例中可由用户来配置。

如果在文档取回或存储中发生传输错误，审核子系统可记录该文档并标记其状态为“失败”。传输错误是根据条件产生的错误，可能稍后被解决，例如，与网络连接的资源不可用或不可以连接到数据库。可使用监测器来发现和重发状态为“失败”的文档。并且，触发器可被配置为如果发生重试失败则暂停(suspend)或在稍后的时间里重试。当整合服务器102达到重试的最大次数并且触发器仍然失败(由于异常)时可产生重试失败。

如图6所示，为整合服务器订阅发往默认客户的文档的路径的示意图。发布服务可通过指定文档的目的地来分发文档。例如，发布服务可指定取回文档的中间件客户。当中间件接收到分发的文档时，其仅将该文档的副本置于指定的客户的队列中。通常，文档分发至默认客户。默认客户是当整合服务器第一次配置其与中间件的连接时由中间件客户为该整合服务器产生的。需要说明的是，如果发布服务指定了单独的触发器作为文档的目的地(例如，发布服务指定了触发器客户ID作为目的地ID)，文档的订阅路径与发布文档的路径一样。

整合服务器102中的分配器请求来自中间件106上的默认客户队列中的文档(S601)。需要说明的是，默认客户可能是为整合服务器102产生的中间件客户。仅当发布者向整合服务器的客户ID分发文档时，中间件106才将文档置于默认客户的中间件队列602中。线程以批量的方式取回分发至默认客户的文档(S602)。线程一次取回的文档数目由，举例来说，默认的文档存储的重填水平和容量、以及中间件106上的默认客户的可用文档数目决定。

分配器204将文档的副本(例如，存储于内存中)置于默认文档存储604中(S603)。分配器204确定订阅文档的订阅者，并将文档副本路由至每一个订阅者的触发器队列214a～b(S604)。在分发文档的情况中，整合服务器102将文档存储在触发器队列214中。触发器队列214位于存储在磁盘上的触发器文档存储502中。整合服务器102将文档的副本从默认文档存储604中移除并，如果文档是有保证的，向中间件106返回确认信息(S605)。中间件106将文档从默认客户队列602中移除。

分配器204从服务线程池中获取线程，从触发器队列214a中拉取文档，并评估在触发器中的文档的条件(S504)。如果为触发器配置了仅发生一次(exactly-once)的处理流程，则整合服务器102可先确定文档是否是已经被触发器处理过的文档的副本。在这种情况下，仅当文档是新文档时，整合服务器102才会连续处理文档。

如果文档符合触发器条件，分配器204执行与该条件有关的触发器服务502a、504b(S607)。如果文档不符合触发器条件，整合服务器102向触发器队列214a～b发送确认信息，丢弃文档(例如，从触发器队列214a～b中移除该文档)，并将服务线程返回至服务线程池。整合服务器102也可产生日志记录消息记录该文档没有与条件匹配。

触发器服务执行至结束(如，成功或错误)(S608)。如果触发器服务502a、504b成功的执行了，整合服务器102向触发器队列214a～b返回确认信息(例如，如果这是有保证的文档)，从触发器队列214a～b中移除该文档，并将服务线程返回至服务线程池。如果产生服务异常，触发器服务502a、504b以错误结束，整合服务器102拒收文档，从触发器队列214a～b中移除该文档，将服务线程返回至服务线程池，并发送错误文档以指示产生了错误。如果文档是有保证的，整合服务器102向触发器队列214a～b返回确认信息。触发器队列214a～b从存储中移除该文档副本。如果在触发器服务执行期间产生了传输错误，服务获取该错误，将其覆盖(wraps)并重新作为异常丢弃，然后，整合服务器102等待重试间隔时长(该重试间隔可以被预先定义和/或由用户定义)并使用原始文档作为输入重新执行该服务。如果整合服务器102达到最大重试次数(也可以被预先定义和/或由用户定义)，并且触发器服务由于传输错误仍然失败了，整合服务器102将最后一次失败作为服务错误处理。

整合服务器102可将分发文档存储在位于磁盘上的触发器文档存储502中。整合服务器102可将发布文档存储在位于内存中的触发器文档存储502中。如果在处理存储在磁盘上的触发器文档中的有保证的文档之前整合服务器102关闭了，整合服务器可以在重启后从触发器文档存储502中重新获取文档。易失的文档可存储在内存中，在重启后不可恢复。

如果服务产生了基于错误的审核数据，并包括审核记录中的输入流水线的备份(副本)，监测器可用来在稍后的时间重新调用触发器服务。如前所述，文档可能满足一个以上的触发器中的条件。然而，整合服务器102可能仅执行与第一被满足的条件相关的服务。

触发器的处理模式决定了整合服务器102以连续的还是以同时的方式处理触发器队列中的文档。在连续处理中，整合服务器102按照文档在触发队列中的次序一次处理一个文档。在同时处理中，整合服务器102一次处理其可处理的多个文档，但是不一定按照文档在队列中的顺序处理。

如果在文档取回或存储中发生传输错误，审核子系统可记录该文档并标记其状态为“失败”。可使用监测器来发现和重发状态为“失败”的文档。并且，触发器可被配置为如果发生重试失败则暂停(suspend)或在稍后的时间里重试。当整合服务器102达到重试的最大次数并且触发器仍然失败(由于异常)时可产生重试失败。

如图7所示，为本地发布文档的发布和订阅路径的示意图。本地发布涉及在整合服务器102内发布文档的处理过程。在这种情况中，只有位于同一整合服务器上的订阅者可以接收和处理文档。在本地发布中，文档保留在整合服务器内。中间件不参与该过程。当发布文档的服务中指示文档应当在本地发布，或当整合服务器没有被配置为与中间件连接时，会产生本地发布。

整合服务器102中的发布服务202向分配器204发送文档(S701)。在整合服务器102向分配器204发送文档之前，其可验证文档的可发布文档类型。如果文档是无效的，服务可返回代表无效错误的异常信息。分配器204或者确定哪一个触发器订阅文档并在每一个订阅者的触发器队列214中放置文档的副本，或者在触发器文档存储502(例如，位于磁盘上)中保存本地发布的文档，如果文档没有订阅者则丢弃文档(S702)。

分配器204从服务线程池中获得线程，从触发器队列214中拉取文档，并评估在触发器中的文档的条件(S703)。如果为触发器配置了仅发生一次(exactly-once)的处理流程，则整合服务器102可先确定文档是否是已经被触发器处理过的文档的副本。在这种情况下，仅当文档是新的时候，整合服务器102才会连续处理文档。如果文档符合触发器条件，分配器204执行与该条件有关的触发器服务502/504/506(S704)。如果文档不符合触发器条件，整合服务器102向触发器队列214发送确认信息，丢弃文档(例如，从触发器队列214中移除该文档)，并将服务线程返回至服务线程池。

触发器服务执行至结束(如，成功或错误)(S705)。如果触发器服务502/504/506成功的执行了，整合服务器102向触发器队列214返回确认信息(例如，如果这是有保证的文档)，从触发器队列214中移除该文档，并将服务线程返回至服务线程池。如果产生服务异常，触发器服务502/504/506以错误结束，整合服务器102拒收文档，从触发器队列214中移除该文档，并将服务线程返回至服务线程池。如果文档是有保证的，整合服务器102向触发器队列214返回确认信息。如果在触发器服务执行期间产生了传输错误，服务获取该错误，将其覆盖(wraps)并重新作为异常丢弃，然后，整合服务器102等待重试间隔时长并使用原始文档作为输入重新执行该服务。如果整合服务器102达到最大重试次数，并且触发器服务502/504/506由于传输错误仍然失败了，整合服务器102将最后一次失败作为服务错误处理。

可以对可发布的文档类型和整合服务器102进行配置，以使得当文档被发布时整合服务器102不对其进行验证。整合服务器102可将本地发布的文档存储在位于磁盘的触发器文档存储502中。如果在处理存储在磁盘上的触发器文档中的有保证的文档之前整合服务器102关闭了，整合服务器可以在重启后从触发器文档存储502中重新获取文档。，在重启后整合服务器102不会恢复易失的文档。如果服务产生了基于错误的审核数据，并包括审核记录中的输入流水线的备份(副本)，监测器可用来在稍后的时间重新调用触发器服务。

文档可能满足一个以上的触发器中的条件。然而，整合服务器102可能仅执行与第一被满足的条件相关的服务。触发器的处理模式决定了整合服务器102以连续的还是以同时的方式处理触发器队列中的文档。在连续处理中，整合服务器102按照文档在触发队列中的次序一次处理一个文档。在同时处理中，整合服务器102一次处理其可处理的多个文档，但是不一定按照文档在队列中顺序处理。触发器可被配置为如果发生重试失败则暂停(suspend)或在稍后的时间里重试。当整合服务器102达到重试的最大次数并且触发器仍然失败(由于异常)时可产生重试失败。

以上是对发布-订阅方案的总体步骤的描述。简而言之，在发布侧，用户为将要被发布的文档产生可发布的文档类型，并产生处理来自发布侧发布的文档的服务。在订阅侧，用户产生发布文档的服务和触发，该触发将输入文档与处理文档的服务关联起来。

具体来说，建立整合解决方案的第一步在于定义问题并确定如何采用发布-订阅模型解决问题。当设计该解决方案时，确定需要被发布/订阅的文档将会是有益的一步。该信息在产生可发布的文档类型时是有用的。相似的，确定文档应当如何被发布也是有用的一步。该信息在产生发布文档的服务时是有用的。最后，确定如何处理文档也是有用的一步。该信息在产生处理文档的服务时是有用的。

在第二步中，确定产品的配置。在一些情况中，需要开发环境(development environment)来镜像产品环境。需要考虑的因素包括是否所有的文档的发布和订阅都在单一的整合服务器上进行，或是否使用多个整合服务器；如果使用了多个整合服务器，是否需要配置群；以及，在产品环境中是否使用中间件。在第三步中，产生可发布的文档类型。这是，在确定将要被发布的文档后，在发布侧，产生可发布的文档类型。

在第四步中，使可发布的文档类型可用。产生处理文档的服务和订阅文档的触发，订阅侧通常需要定义了将要被发布的文档的可发布的文档类型。当开发环境是单个的整合服务器时，发布侧和订阅侧都处于单个的整合服务器上。这样，总的来说，不需要进行使可发布的文档类型对其他开发者而言可用的动作。在用于发布侧的可发布文档类型产生后，可发布的文档类型马上可用于订阅侧的使用。然而，当开发环境包括多个整合服务器及与其一起的中间件时，发布侧和订阅侧分别处于与中间件连接的单独的整合服务器上。这样，当产生了可发布的文档类型，中间件上自动产生相应的中间件文档类型。使可发布的文档类型对其他开发者也是可用的。这可以通过从中间件文档类型产生可发布的文档类型来实现。这也可以通过使用封装副本(package replication)向与其他整合服务器共同工作的开发者分发可发布的文档类型来实现。在这种情况下，当其他开发者收到封装时，他们可以安装该封装，然后通过从中间件拉取他们同步文档类型。

在第五步中，在发布侧，产生将文档发布至中间件或是在相同的本地整合服务器的服务。在第六步中，在订阅侧，产生将处理入局文档的服务。当产生处理文档的服务时，在对发布文档的可发布文档类型的输入标志中可包括文档目录。通过这种途径，在可发布文档类型中定义的域可用于索引文档中的数据。

在第七步中，定义了触发(器)。在订阅侧，产生触发，以将一个或多个可发布的文档类型与处理发布文档的服务联系起来。为将可发布的文档类型与服务联系起来，可在触发器中产生条件以定义订阅的可发布的文档类型和当该类型的文档到达时调用的服务。通过增加定义发布文档的内容的标准的过滤器可以进一步的精简该条件。当触发被保存时，整合服务器使用触发中的条件来定义对可发布的文档类型的订阅。触发器设计的进一步细节和配置在后续部分进行描述。

在第八步中，同步可发布的文档类型。当在整合解决方案中包括中间件时，每一个可发布的文档类型具有在中间件上的相应的中间件文档类型。如图8所示，为发布-订阅模型解决方案的两侧，其中，可发布的文档类型与相同的中间件文档类型相联系。在发布-订阅解决方案中，发布侧和订阅侧都使用相同可发布的文档类型802。当向中间件106发布文档804时，发布侧使用可发布的文档类型802来定义被发布的文档的类型。订阅侧引用在触发器808中的可发布的文档类型来指示订阅的文档的类型。为使整合解决方案正确的运行，在发布侧和订阅侧的可发布的文档类型802应当引用相同的中间件文档类型806。

以下描述在开发环境中如何使可发布的文档类型与相同的中间件文档类型相符合。在开发环境中涉及一个整合服务器时，当整合解决方案涉及产品时，发布侧和订阅侧可以在与中间件连接的不同整合服务器上。这样，有必要同步的产生与可发布的文档类型有关的中间件文档类型。相应的，在发布侧，在同步时，将可发布的文档类型推送至中间件以在中间件上产生中间件文档类型。可使用封装副本来产生和分发包括可发布的文档类型的封装。在订阅侧，安装包括发布者产生的可发布的文档类型的封装。在同步时，从中间件拉取文档类型以更新可发布的文档类型。

当开发环境涉及与中间件一起的多个整合服务器时，由于开发中使用了中间件，所以在发布侧和订阅侧中的可发布的文档类型可能已经与相同的中间件文档类型相符合了。尽管如此，可使用所有文档类型的简单同步来保证可发布的文档类型与中间件文档类型同步。

以下将描述与触发器有关的具体细节。触发器建立对可发布文档类型的订阅，并明确如何处理这些可发布的文档类型的实例。当触发器建立时，会产生一个或多个条件。条件将一个或多个可发布的文档类型与单个服务联系起来。可发布的文档类型作为触发器的订阅片块(subscription piece)。服务器处理片块。当触发器接收器订阅的文档时，整合服务器通过调用在条件中定义的服务来处理文档。

建立触发器的过程与以下基本阶段有关。产生位于整合服务器上的新触发器。在该阶段，在整合服务器上产生了新的触发器，在该整合服务器上将进行开发和测试。为触发器产生一个或多个条件。在该阶段，可发布的文档类型与服务关联，产生施加于入局文档的过滤器，选择联合的类型(join types)。设置触发器特性。在该阶段，设置配置该触发器的运行阶段环境的参数，例如，触发器队列容量、文档处理模式、触发器服务重试限制、以及仅进行一次的处理。在触发器上可进行测试和调试。

处理触发器接收文档的服务被称为触发器服务。通常，条件详细定义了单独的触发器服务。在使能触发器之前，在相同的整合服务器上必须已经存在触发器服务。另外，触发器服务的输入标志需要包括对可发布的文档类型的文档目录。该文档目录的名称是可发布的文档类型的完全合格的名称。可发布的文档类型的完全合格的名称需要符合一系列的格式，比如为，folder.subfolder：PublishabelDocumentTypeName。

当保存了触发器，整合服务器可以评估该触发器，并详细定义触发器中的条件，以保证触发器是有效地。如果整合服务器确定触发器或触发器中的条件无效，则会向用户显示错误信息，并使触发器无效。在具体的实施例中，当如下条件中的每一个都是真实的时候，触发器可被当作是有效地：触发器包括至少一个条件；触发器中的每一个条件指定了独一无二的名称；触发器中每一个条件指定了服务；触发器中的每一个条件指定了一个或多个可发布的文档类型；如果触发器中的多个条件指定了相同的可发布的文档类型，在每一个条件中作用于可发布的文档类型的过滤器都是相同的；作用于可发布的文档类型的过滤器的语法是正确的；并且，触发器包括不超过一个的联合条件。

总的来说，触发器可以仅订阅可发布的文档类型。多个触发器(以及在触发器中的多个条件)可以引用相同的可发布的文档类型。在运行阶段，对于每一个触发器，整合服务器调用为第一条件指定的服务，该第一条件与可发布的文档类型标准相符合。

如图9所示，为提供了在前述系统中、之间的通讯的当前消息层900的组成示意图。消息层900的特定方面(aspects)可位于整合服务器(或整合服务器的实例)与中间件上，作为单独的执行体，并且/或者其可以出现在任何提供者上，在本发明的具体实施例中。在消息层900中，提供应用服务902作为客户执行体。消息提供者(例如，专有物(proprietary)或JMS模式中的中间件功能，另一个JMS提供者)可选择的从接近(access)提供者的客户中区别。在这种情况下，客户可以是整合服务器或客户程序或应用，例如，嵌入到提供者的客户图书馆中。这样的客户图书馆可包括消息API层(例如，API中间件和/或JMS API)中的JAR文件。在本发明的具体实施例中，消息层(例如，JMS适配器和触发器层，通过应用编码)中的高层可位于整合服务器上。

触发器层904使能上述的中间件触发器服务，其与如前所述的整合服务器中间件触发器子系统和设备906相互作用。这些层使能到达专有物(例如，中间件)消息API层908的通路。通过JAR文件可以分发或/和执行中间件API。这样，消息层900的右侧通过专有物消息层提供与整合服务器或整合服务器实例910进行交互的丰富的特性，以提供应用整合解决方案。

如前所记录的，基于开放的、标准的消息协议提供互操作性和/或通讯，通过适配器的应用可使能合适的消息协议(例如，JMS消息)。这样，在消息层900的左侧，提供了JMS适配器层912用于与JMS API层914进行接口，通过使用JDK提供的标准JMS接口可使上述使能。这样，消息层900的左边提供了互操作性和/或开放的消息特征，其可通过JMS相关层与整合服务器实例910交互，以提供应用整合的解决方案。

从图9中可以了解，当前的消息层900并不包括触发器子系统，为消息协议的左边。这样，建立于JMS适配器上的应用就缺少中间件触发子系统的扩展性能。这样，采用当前的消息层900，使用者必须在互操作性和标准消息之间进行抉择，并且处理在一边，更重要的是，专有物消息和处理在另一边。

在本发明的具体实施例中，解决该问题的方案涉及将完全嵌入JMS作为整合服务器触发器子系统中的专有物消息协议中的等同物，这样所有或潜在的所有已存在的功能都可由JMS实现。

相应的，如图10所示，为本发明实施例中的相应的消息层1000的组成示意图。与图9中的消息层900相比，本发明实施例中的消息层1000可位于整合服务器(或整合服务器的实例，如图9所示)和中间件上，作为单独的执行体(在图10中未示这种情况)。其可以出现在任何提供者上，如，支持JMS消息的提供者上。不管怎样，通过使用本发明实施例中的消息层1000，可以在没有使用供于整合服务器的特定的适配器就可以使能JMS消息。进一步的，在本发明的具体实施例中，这样的消息层1000可以使避免对JMS触发器本身进行任何改变成为可能(例如，使常规格式下的标准JMS消息的使用成为可能)，和/或可降低对客户程序的需求和/或在应用服务水平层面的执行，在本发明的具体实施例中。

如图10所示，消息层1000的左侧基本上是右侧的镜像。特别的，提供JMS触发器层1004作为中间件触发器层904的对应物，JMS子系统1006(用于产生JMS适配器912)作为中间件触发器子系统906的对应物。同时还提供了相同的JMS消息API层914和专有物中间件消息API层(proprietary broker messaging API layer)908。在消息协议1000中包括提供了通用触发器功能的触发器子系统1002。提供触发器子系统1002作为在单独触发器子系统之上的增值(value-added)层，因而使能平行子系统的功能。

在本发明的具体实施例中，通过采用如下的具体措施使能触发器子系统1002。第一，扩展整合服务器触发器的名称空间实体，并将其调整为包括特性，并特别按照JMS消息设置。触发器的名称空间是已命名的对象，其使得配置时可以考虑等待消息需要多长时间以及当收到消息时如何处理这些消息。其可以，如，作为文件夹的已命名的层次结构进行组织。举例来说，下述的结构表征了作为业务应用应当如何处理订单文档(当文档被接收时)的指令：bussapp.processpo：handlineincomingprocessingorder。名称空间可以组织为树状，可以在其节点进行配置。

第二，可扩展和调整整合服务器触发器管理(administration)功能以使其包括可选择的特定的JMS(例如，交替的限流方案)。在调整进入系统的消息上这种管理功能是有用的(例如，在降低系统溢出的产生上)。管理可以在全局进行或/和在触发器层进行。对功能的举例包括调节/延迟触发器接受和/或处理。

第三，可为JMS扩展和调整整合服务器触发器群模型。需要说明的是，该群，例如，在负载平衡中提供的，可以提供可伸缩性(scalability)和耐久性(survivability)的增长。在本发明的具体实施例中，可在一个或多个整合服务器上使用相同的触发器。

第四，可为JMS扩展和调整整合服务器触发器联合机制。在联合操作中，如果处理流程一次调用所有文档的处理，触发器会等待多个文档。第五，可为JMS扩展和调整整合服务器触发器次序的服务执行机制。如果涉及多个文档，次序的服务执行保证了依次序的处理。第六，可为JMS消息提供整合的交易操作(transaction handling)的执行。交易操作涉及将处理队列与交易绑定。然后，可调配处理队列以供整个交易的使用，或如果交易中的操作失败，则中止(roll back)改变。

在本发明的具体实施例中，当将中间件作为JMS提供者自身使用时，可以为实例提供特定的客户扩展。例如，可以使能单独步骤(如，JNDI)的配置，多服务失效备援(failover)(例如，共享的客户模式)，和/或流型的大消息处理。实际上，本发明实施例中的配置功能简化了现有技术中的对客户程序和执行的需求。本发明的具体实施例编程提供了基于菜单的配置工具以替代具体的编程过程。

消息处理标准流涉及预处理、处理、以及后处理。预处理涉及消息的取得和估值，这包括，例如，群支持、副本检测、交易初始化、以及类似功能。处理涉及服务调度，这可包括，例如，本地过滤器处理、应用的并发、联结和次序的服务执行评估、以及类似功能。后处理涉及消息确认，其包括，例如，错误和重试操作、交易完成、及其类似。

这些配置技术提供特定的例证性的优点。例如，由于在整个触发器中消息操作和处理是地址化(addressed)的，所以整合服务器中建立的功能可以被改变(leveraged)。由于在本发明的具体实施例中的触发器结构是独一无二的，所以基于JMS的发送机制也是如此。更进一步的，通过合适的协议传统的中间件虽然提供丰富的特性集合但降低了互操作性，而JMS消息提供互操作性但减少了特性，本发明的具体实施例既提供在标准消息协议的基础上的互操作性同时还提供了丰富的特性集合。这样，提供消息层的扩展以降低(而且有时是消除)对，消息层、适配器、和/或使用这种客户消息层和/或适配器的应用，的客户开发的需要。如此，可以避免重复的重新编码(该重新编码通常是以非标准的方式完成)，同时，在基于配置的方式中还可提供相同或更好的功能。

即，大致的优点包括丰富的增强的完全的可互操作的基于标准的(如，基于JMS)的消息处理，替代或在专有物中间件以外可使用交替的(例如，JMS)消息提供者的能力，与一个以上消息提供者同时连接的能力(如，一个中间件和/或任意个的JMS提供者)。触发器子系统所提供的特定的优点可包括，在本发明实施例中公布的收听者的配置(为一个或多个JMS目的地)(例如，队列或主题)，用于服务负载控制的配置的并发性(例如，可用于每一触发器(per-trigger)和/或全局的线程)，全局和每一触发器运行阶段管理(例如，控制、暂停和重新开始、容量管理等)，一次和仅一次的处理(例如，有保证的处理、副本检测、错误重试等)，自动传输错误操作和恢复(例如，为暂时的不可用的后端应用)，消息处理的群支持(例如，提供可测量性、可用性和失效备援特性)，对大文档的基于流的消息处理(例如，降低内存溢出)，基于联合(其在业务处理模型的执行中有用)的条件消息处理，次序的消息序列的次序服务执行，整合的本地和XA交易支持，消息的客户侧队列(例如，以支持JMS提供者的不可用性)，本地过滤器(例如，超过限制的JMS选择器容量)，等等。

虽然上述的本发明实施例中中间件具有优点，但是还可以对其进行进一步的改进。例如，应该理解到，可以对中间件进行改进，以提供扩展的负载平衡特性。实际上，当前应用的发明人已经注意到，在过去的几年里，客户需要为其中间件应用获得失效备援和负载平衡特性。相应的，本发明实施例中的中间件执行客户侧失效备援和负载平衡功能。本发明实施例中的负载平衡功能可在应用空间范围内也可以扩展。

更具体的，上述的负载平衡特性可以作用于一组中间件(此处称为中间件群)。发布者和订阅者可与中间件群连接，中间件群中的中间件可以共享从发布者到订阅者的消息路由。例如，在具体实施例中的发布者可选择运行在中间件群中的任意的中间件来发布消息，订阅者可以从该中间件接收相同的消息。

在本发明的具体实施例中，负载平衡特性的执行可作为上述的JMS中间件API的扩展。进一步的，具体实施例有利于使得监控和跟踪负载平衡流通数据称为可能，例如，通过嵌入工具或数据库。举例来说，可使用JMS API记录器来记录消息。记录的消息可能或不能可见或可估测于监控的目的。需要理解的是，可进行其他的执行实例，本发明的技术方案不应局限于本实施例或任何具体的实施例。

具体实施例中的负载平衡功能可有益于允许使用者应用来增加系统的吞吐量，例如，在快速的发布者和慢速的订阅者的情况中。在这样的情况中，例如，发布者可与多个组成群的中间件连接，基于发布策略(如，循环，等)发布文档，并且所有的订阅这可与群中的所有中间件连接。多个订阅者可共享消息处理负载，这可增强整个系统的表现。此外，如果其中一个中间件停止(例如，变为不可用、超过容量、或其他情况的失效等)，其他的中间件可接手该停止的中间件的消息分发。这样，可见，本例中的执行可基于中间件群提供客户侧的失效备援功能。当多发布者中存在相同的消息时，本例中的执行可以帮助平衡发布者的工作负载，并同时提供失效备援支持。在本发明的具体实施例中还提供了基于主题的消息分发，和在中间件群内的中间件流通负载。

本发明具体实施例中的失效备援特性可以以有限至的方式处理活跃的/活跃的和活跃的/消极的失效备援情况。即是说，当中间件的整个群依据循环策略共享消息分发时，例如，达到了活跃的/活跃的失效备援。当中间件基于粘性算法(sticky algorithm)分发消息时，例如，其中仅当前一中间件停止时下一中间件才会接管消息分发，可执行活跃的/消极的失效备援。在本发明的具体实施例中，如果发生了失效备援，已经处于失效中间件上的文档可以保留在特定的中间件队列中，直到特定的中间件的功能恢复。

具体实施例中的负载平衡特性可以与子类一起执行，该子类是已经存在的JMS连接、会话(session)、和客户类的扩展。例如，当应用产生与群连接工厂连接的JMS时，可生成群连接实体(实例)。该连接发起与组成群的中间件的多个物理连接。当群连接上产生会话时，可将基于该物理连接填入多个群会话。JMS连接执行可将一个插孔(socket)与一个中间件连接，多个与不同中间件连接的物理连接将群连接功能合并为通用的连接，等。

如图11所示，为本发明实施例中的与中间件群的产生有关的各种元素的示意图。为了使用具体实施例中的负载平衡特性，可产生包括多个中间件106的中间件群1102。如图11所示，中间件群1102被置于发布/请求客户端(如，图中的左侧)与订阅/响应客户端(如，图中的右侧)之间。两个客户端都包括整合服务器102(或，其实体/实例)，还包括与JMSAPI的接口914。可生成连接工厂(connection factory)，该连接工厂包括组成群的中间件的子集和相应的群策略。用户接口工具1104(例如，由webMethods/Software AG提供的myWebMethods Server或MWS)使得用户可先选择群，然后选择一个或多个中间件的列表。MWS 1104可使得用户可确定对于特定的负载平衡群应当采用哪一种负载平衡策略。换句话说，用户可定义包括多个中间件的中间件群，然后为已经产生的群确定特定的负载平衡策略。用户接口可被图解的或命令行的方式驱动。

如图11中所示，与NWS 1104配对提供的JNDI提供者1006可包括目的地和连接工厂数据。当产生JMS连接时，JMS API 914可可选择的使能或使无效负载平衡，该负载平衡基于中间件群定义的存在以及负载平衡策略。如果连接工厂中仅定义了一个中间件，例如，所有的消息发布和接收可能都是普通的JMS消息。如果连接工厂与中间件群(如，多个中间件)相关，并定义了负载平衡策略，例如，中间件可作为整体工作并根据负载平衡策略分发消息。

在发布操作中，可检查中间件群标志。如果设置了该标志，则文件可能不会被发布至群远端中间件(cluster remote broker)。

在具体实施例中，具有许多不同的用于定义负载分发策略的算法。以下描述其中的几个策略。应当理解的是，这些策略的范围从简单的循环算法到更加复杂的算法，并且，此处描述的具体实施例不应被局限为任何具体的策略。

·在循环(round robin)负载平衡策略中，群连接中的第一中间件处理第一发布操作，第二中间件处理第二发布操作，并以此类推，直到所有的中间件都进行了处理。该队列重复再重复。循环算法的一个好处在于，发布操作被平等的分布于群中的可用中间中，以一个次序的方式。

·在“粘性的”负载平衡策略中，客户将会向第一中间件进行发布直到该中间件失效，该中间件失效后迫使客户切换到下一中间件。

·在随机分配中，发布操作可指派给任何在群中中间件组上随机抽取的服务。在这种情况下，中间件中的一个可能被分配需处理很多消息，而其他的服务确是空闲的。然而，久而久之，总的来说可期望每一个中间件都取得相近的负载的分担。

·“文档大小(document size)”策略基于消息的大小路由该消息。可以测量对象的大小，例如，通过将排列为比特(byte)流并检查该流的长度。以下的代码可用于检测对象的大小，例如：

Pulic static byte[] sizeof(object obj)throws java.io.IOException

{

ByteArrayOutputStream byteObject＝new ByteArrayOutputStream{}；

ObjectOutputStream objectOutputStream＝

new ObjectOutputStream(byteobject)；

ObjectOutputStream.writeObject(obj)；

ObjectOutputStream.flush()；

ObjectOutputStream.close()；

byteObject.close()；

return byteObject.toByteArray()；

}

应当理解的是，由于对每个消息进行排列以测量其大小，这个过程可影响运行阶段的表现。

·有权重的循环策略可适应，例如，具有不同处理能力的中间件服务器。在有权重的循环算法中，为每一个目的地(在本例中，为中间件服务器)分配表征，相应于列表中的其他中间件的，中间件服务器的表现的值。该“权重”确定了可向该特定的中间件服务器发送多少更多(或更少)个消息，相比于列表中的其他服务器。可提供用户接口来确定群中的每一个服务器的权重。例如，客户可确定相关的赋给每一个中间件服务器实体的权重，如果为负载平衡选择了基于权重的策略的话。

群中的每一个中间件服务器可，例如，接收一定比例的消息，该比例与消息的权重有关：％＝((中间件服务器的权重)/(在群中的所有服务器的权重的和))*100。

附加地或可替换地，消息向每一个中间件服务器的分发可以是实时权重的函数(与仅仅是一个平均值相反)。提供以下的示例以进行说明：

例1：如果群中的所有中间件都具有相同的权重，那么他们将承担同等比例的负载。如果一个中间件服务器的权重为1而所有其他的中间件服务器的权重为2，则权重为1的中间件服务器承担的负载为其他任何服务器的一半。

例2：假定，在有权重的循环环境的开发中，具有三个中间件被分别的衡量(benchmarked)和配置。进一步假定，第一个中间件可以处理100个消息/秒，第二个可以处理300个消息/秒，而最后一个中间件可处理25个消息/秒。在这种情况下，可以为其分配权重为：

中间件          权重

中间件1         权重4

中间件2         权重12

中间件3         权重1

采用该策略，当发布每17个消息时，4个消息将被发送至中间件1，仅仅向中间件3发送一个消息。

·“多发送(multi-send)”策略可支持两种子选择，称为，“尽力而为(best effort)”和“有保证的(guaranteed)”。在尽力而为多发送子选择中，JMS API可尝试将消息发布至所有或群中尽可能多个的中间件。即使只有一个中间件收到了该消息，也可以认为该发布/发送操作成功了。向群的中间件发布的消息实际上可以是非交易性的(non-transactional)。相比之下，在有保证的多发送子选择中，JMSAPI采用XA交易可向M个中间件(即群中的中间件)中的N个发布消息(参见下述)。在这种情况中，群中的每一个中间件可作为单独的XA资源，而如果M个中间件(即群中的中间件)中的N个接收到了消息，则认为该发布操作成功了。

对于多发送尽力而为策略，JMS客户可使用标准的JMS发布/发送语义来向群中的所有中间件发送消息。消息产生者可向目的地发送或发布消息。

一旦发送或发布步骤的调用成功的返回，则可以假定中间件已经接收到了消息。在产生者侧，确认信息的通知与主题发布者的发布步骤、或队列发送者的发送步骤的成功调用有关。如果其没有接收到JMS异常(JMSException)，则表明对JMS客户的多发送操作成功了。

以下是多发送尽力而为的代码的例子：

try {

 //Assumption：

 clusterFactory.setBrokerCluster(new String[]{“Broker

   #|@|oca|host：6849”，

 “Broker2@|oca|host：6949”})；

 clusterFactory.setClusterName(“T1”)；

 clusterFactory.setClusterPolicy(WmClusterPolicyManager.MULTISEN 

    D_BESTEFFORT)

 connection＝((WmConnectionFactory)

   clusterFactory).createConnection()；

 connection.start()；

 session＝publisherConnection.createSession(false，

   Session.AUTO_ACKNOWLEDGE)；

 MessageProducer producer＝session.createProducer(queue)；

 TextMessage message＝session.createTextMessage(“Testing Multi 

   Send”)；

 //This will attempt to send the message to all the brokers in

   The above cluster

 Producer.send(message)；

 System.out.println(“Multi Send is successful”)；

}catch(JMSExceptione){

   //this means the multi  send best effort failed to publish to 

     even one broker in the cluster

}

从上述实施例可知，JMS发送并发布语义，该语义可用于向群中所有的中间件发布消息。本质地，JMS API可同步的向所有中间件发送消息并产生异常，虽然消息不能分发至至少一个中间件。

对于多发送有保证的策略，JMS API可向客户(本例中为整合服务器)提供APIgetXAConnections()，并会返回XA连接(Connection)的N数字(N number)。整合服务器可使其为交易的一部分并可执行发布操作。这有助于保证向群中的N个中间件发布消息的成功。如果存在失败，该策略可“回滚(rollback)”并尝试再次发送。JMSAPI中的getXAConnection的每一个后续呼叫(subsequent call)可发送另一个N个中间件的组合，该N个中间件为群活跃中间件列表中的中间件。JMS API可保留有关M×N组合连接的列表。

·例如，如果有配置在群中的3个中间件B1、B2、B3，其策略为多发送有保证的策略且为3个中的2个有保证，JMS API可保留B1-B2、B2-B3、B3-B1连接列表。

·在具体的实施例中，可在循环模式中保存XA连接组合列表。这有助于保证，在群中的中间件之间平衡负载。

·在与不可用的中间件B1有关的异常中，该列表可以与列表中的B1-B2一起更新，而剩下的则可以被设为不活跃。

需要注意的是，可以为或不为采用多发送有保证策略的连接工厂提供XA连接。

JMS API可发送三种异常。“成功(Success)”可表示客户成功的向n个服务器发送了消息。“部分成功(Partial success)”则表示向一些服务器发送成功但是没有达到n个服务器都成功了。“失败(Failure)”表示向所有的服务器的发送都失败了。

JMS API可包括独立的API以供客户询问中间件是否可用，例如，使用isAvailable()函数，其指示了所需数量的中间件是否可用于发布。需要注意的是，该功能可用于所有的策略类型。

在具体实施例中，执行副本消息检测是有用的。例如，可以理解，当采用多发送策略时，执行副本检测是有用的。如前所述，在多发送语义中，客户想JMS API发送消息。然后，JMS API建立于群中所有中间件的连接。基于多发送JMS策略，JMS API可向群中的多个(该个数可以与其最多可以向其发送的中间件的数目相同)中间件发送消息。订阅者可以采用同样或不同的连接工厂来与中间件群连接。JMS API可建立与群中所有中间件的连接以从每个中间件取回消息。由于采用的多发送策略的特性以及由发布客户进行的执行，这些中间件可具有相同的消息。

在多发送语义中为避免副本，可执行副本消息检测来保证没有消息被发送两遍，在中间件群环境中。可为JMS消费者客户，例如JMS API，采用这种检测机制。副本消息检测可影响JMS消息ID，在发送或发布操作中，可从JMS API中的产生者自动的产生。可设置JMS消息ID使其代表通用唯一标识(Universally Unique Identifier，UUID)。当执行副本消息检测特性时，可在连接工厂中使能JMS消息ID，虽然其可在其他上下文中被无效。例如，可使用Java SE 5中的java.util.UUID类来产生UUID，即通过简单的调用类中的UUID.randomUUID()函数。

如下所述，在消息的确认中，JMS API可在连续的ID上进行确认，该ID来自中间件(其从该中间件为接收消息)，并进行在群众的剩余中间件上的待定确认。待定确认可以在JMS消息上的UUID集合上表现。这有助于保证，在其他中间件上的副本消息不会被发送至订阅者。

在具体实施例中，可可使用记录进行负载平衡。已记录的消息的种类可包括，例如，消息何时被发布/重发布，消息何时被接收，错误何时产生，连通性何时改变，等等。需要注意的是，可存在很多原因导致中间件不可达。需要理解的是，在具体实施例中有时在负载平衡解决方案中提供“最好的猜测(best guess)”。

以上描述的策略可以看作是“简单的”策略，在这个范围，一个策略有效的控制中间件群的负载平衡行为。然后，如上所提及的，具体实施例可“分层(layer)”多个策略，一个在另一个之上。这样，“简单的”策略可以被分层，以便定义“复合(composition)”策略。换句话来说，可对复合策略进行定义和实施，使其作为多层群策略，在具体实施例中。为使用该负载平衡特性，使用者可定义单个的群策略。这些来自JNDI提供者的子辈群连接工厂对象可进行分组，例如，组成复合连接工厂。复合连接工厂也可包括负载平衡策略定义，其确定消息如何通过中间件群进行分发。例如，如果连接工厂与多个群连接工厂对象有关，并且定义了负载平衡策略，则群可以作为一个整体进行工作，并根据负载平衡策略分发消息。

在如下例子中，负载平衡策略可用于域复合连接工厂的连接中。当然，需要说明的是，可以将其他负载平衡策略与下述的负载平衡策略一起使用，或替换其使用。

·在循环负载平衡策略中，将第一发布操作分配给复合群连接中的第一群连接，第二发布操作分配给第二群，以此类推，直到所有的群都被遍历，按此顺序重复。在此上下文中的循环算法的优点包括发布操作以次序的方式平等的在可用群中分配。

·在粘性的负载平衡策略中，JMS API需将消息发布至第一群，除非该群不再可用。仅当第一群失败时，消息才会被切换到下一个群。

·在多种子尽力而为(seed-best effort)策略中，JMS API须将消息发布至所有群或由复合群连接工厂定义的群子集中。如果消息被分发至至少一个群，则认为发布/发送操作成功了。

为使能中间件服务器集群(clustering)，可对上述的中间件进行改变。例如，中间件服务器可支持群的产生。在这点上，集群中可不需要文档转发，由于订阅者可能与群中的所有中间件连接。相应的，当中间件加入群时，可对其适当的进行通知，例如，以禁用群中的文档转发。另一个例子涉及对文档转发的变化。在这点上，由于订阅者可能与群中的所有中间件连接，向任一中间件发布文档即足以保证订阅者可收到该文档。相应的，可以不需要文档向另一中间件进行转发。

另一个设计上的可能的改变涉及文档的预确认(pre-acknowledgement)。该特性可降低(或甚至阻止)副本文档分发的可能性，当采用多发送策略时，如前所述。本质上，JMS客户可以向另一中间取回和发送预确认，这样其他中间件可以丢弃文档的副本。在中间件中为支持该特性，发布者可设置UUID。然后，中间件即可识别两种预确认类型。第一种预确认为，客产已经接收了至少一个文档的复制件。在这种情况中，中间件可抑制发送文档的另一个复制件，但保存文档以防在处理和确认文档之前与客户失去连接。第二种预确认为，客户已经接收并处理/确认了文档。在这种情况下，中间件可从其队列中删除文档，因为已经不再需要该文档了。

在具体实施例中，这种预确认特性可以降低(而且有时候可阻止)发送副本消息的可能性，例如，当发布者采用多发送策略发送文档时。然后，在具体的实施例中，并不能保证这种“非副本(no duplicaties)”行为；相应的，客户自己也有检测副本的机制。

如前所提及的，通过在中间件中施行预确认的两种类型，来提供预确认特性。第一，暂时的预确认将促使中间件保留文档，而不将其发送给客户。这种行为有助于保证不向客户发送不必须要的副本文档。第二，确定的预确认可指示，客户已经接收并成功的处理了文档，在这种情况下，中间件可以从队列中删除文档。

在具体细节中，中间件客户队列可维持两个集合，称为，tentative_pre_ack和ckconfirmed_pre_ack。这些集合可存储UUID(例如，数据类型“串”的)，当其被客户预确认。在发布/订阅时，中间件可检测这些集合，同时，中间件可进行合适的动作(例如，丢弃事件，跳过事件等)。

UUID标记的文档可以几种方式被暂时的预确认。第一，例如，发布者可设置封装域(如，“preack”)为“暂时的(tentative)”，这可在发布期间由中间件读取，同时文档被标记为预确认的。第二，例如，客户可进行明确的呼叫(例如，JMS二进制协议)并通知中间件暂时的预确认。在这点上，可采用中间件二进制协议(例如，协议V6(ProtocolV6))支持新的呼叫以通知中间件预确认。

为有助于预确认特性的实施，发布者可设置文档中的暂时的预确认封装域，为除一个以外的所有的中间件。如果这样配置，则意味着，仅一个中间件将向订阅者发送文档，而其他的中间件将仅在队列中保持副本文档。当从客户接收确认时，向中间件发送规则的确认(例如，依照JMS API通过发送“ack”)，该中间件为从其获取文档的中间件，并且可向所有其他的中间件发送预确认的确认。

在中间件侧，在发布操作中中间件可检测确认的预确认集合，并且如果文档已经被客户预确认则跳过对文档进行排队。当将文档添加到客户队列时，可进行检测。在将事件插入客户队列之前可以不向其他地方增加检测，例如，诸如内部发布、将来的发布、将来的事件更新、以及在队列浏览时插入事件。

在订阅操作中，中间件可先检测暂时的预确认集合并，如果文档已经暂时地去人了，跳过(而不是删除)文档。如果已经确认了确认，删除文档。可使用事件处理类来确定事件是否已经被与确定了。相似的，可采用类来确定是否要跳过事件。

另一个可能的设计的改进设计提供两个或多个群之间的中间件群入口。该特征可，例如，支持单个中间件失效情况中的失效备援，也支持采用多发送策略时的多冗余路径。

中间件群入口可允许在群对之间的多个入口连接。相应的，在具体实施例中，可避免入口连接之间的单点的失败。可在系统中增加冗余，例如，这样可以恰当的处理多发布语义。以下为中间件群入口的例子：

·假定有第一群，群C1，其包括三个中间件。即，C1＝{A，B，C}。进一步假定，有第二群，群C2，具有两个中间件。即，C2＝{X，Y}。

·基于这种假设，C1和C2之间的可能的入口连接集合可以是子集{G}＝{(A，X)，(A，Y)，(B，X)，(B，Y)，(C，X)，(C，Y)}。

·可能的入口连接的集合{G’}，其是{G}的子集，包括明确的元素和基数|G’|＜＝|m×n|，且有m＝|C1|，n＝|C2|。

需要注意的是，允许在群对之间产生多入口。还需要注意的是，入口删除需要发送细节信息，以精确的定义被移除的链接。在任何事件中，中间件发布路径可发现第一活跃入口连接并将事件转发至相应的远端中间件队列。当在另一端接收到转发的事件时，其可被处理。可对基于多中间件协议发送的元数据的任何更新进行处理，虽然元数据和运行阶段文档可以不被转发回其起始的群，例如，以避免在非循环图中产生循环回路。

具体实施例中的负载平衡特性可以设计为应用解决方案，该方案与中间件协议和存储实施无关。例如，具体实施例中的负载平衡特性可以建立在中间件API顶端，这样足以忍受大量的中间件服务器代码的改变和/或为未来特性增强的可扩展性。

使能具体实施例中的负载平衡特性的示例的运行阶段组成部分包括群连接、中间件选择器、以及策略管理器。群连接可实施为从发布者或订阅者到中间件群的逻辑连接。其可与中间件连接集合一起实施，例如，该连接作为从客户到中间件群的抽象连接。中间件选择器可以为检测运行中间件并为相连的发布者或订阅者选择中间件(或多个中间件)的组件。策略管理器可管理策略的产生、持续、以及在运行阶段的解释。这些负载平衡组件中的每一个可以以Java类的形式执行，例如，当发布者或订阅者生成与中间件群的连接时对其进行调用。这些类可位于相同的Java处理中，作为在具体实施例中的发布者或订阅。

在具体实施例中，每一个发布者或订阅者连接可与仅仅一个群连接通讯。群连接启动多个线程以进行活跃中间件的检测，基于策略的中间件选择，与群中的单个中间件的连接管理，等等。当JMS应用产生与连接工厂的JMS连接时，会产生群连接，该连接工厂包括中间件群定义。此处的这些连接工厂涉及群连接工厂。群连接具体可为JMS连接的子类。可利用该连接产生JMS发布者和订阅者，类似于利用JMS API产生发布者和订阅者时的方法。然而，群发布者的发布方法和群订阅者的接收方法可被覆盖以结合负载平衡逻辑。当应用关闭或破坏连接时，群连接管理的相应的群连接和中间件连接也被关闭或破坏。

产生订阅者的订阅的方法也可以在群连接会话的子类中实施。这些新方法可为订阅者建立向群中所有中间件的订阅，例如，对用户的经验是透明的。

中间件选择器可称为群连接，例如，以选择和连接下一可用的中间件。这将会发生在下述情况，例如，在产生初始连接之前，在消息被发布之间，在连接失败时，产生重连接之前，等等。中间件选择器可包括线程，该线程周期性的更新群的中间件状态表。可在群连接之间共享该状态表。这个中间件选择器的轮询阶段可以被配置为，例如，与策略选择相连。

中间件选择器可调用策略管理器，例如，以取回策略信息和运行阶段中间件选择标准。可在策略管理器中封装策略的格式和实施，例如，该策略管理器，相应的，为提供策略存储接口和策略算法的运行阶段操作的程序(例如，Java程序)。可从元数据存储中向Java对象中装载策略。可以基于，例如，元数据存储接口，对策略进行串行化或并行化。可为订制的策略提供嵌入接口，并调用策略执行的运行阶段接口来发现基于群中的中间件的选择标准。

具体实施例中的负载平衡技术可为存在的JMS应用向负载平衡JMS应用提供平稳的过渡，而不需要改变代码，同时还可减少对连接工厂的配置改变的数目。具体实施例中的负载平衡技术中提供的具体公共应用接口包括策略管理器接口和记录器嵌入接口，如图12中所示。换句话说，图12中示意了具体实施例中的负载平衡技术中提供的公共接口。如图12的例子中所示，这些类包括WmConnectionFactoryImpl 1202，WmClusterPolicyManager 1204，WmClusterPolicy 1206，WmClusterTrackable 1208，以及WmClusterTracker 1210。相应的，在以下对这些类进行描述。

向现有的WmConnectionFactoryImpl中增加两个属性。

·brokerCluster：为Java String数组，包括根据连接工厂定义的所有的中间件(Broker)。将中间件次序(Order of the Broker)保留为用户定义的次序。

·clusterPolicy：根据连接工厂定义的负载平衡策略的名称。

·需要注意的是，还可包括额外的属性来支持其他的策略，例如，setMultiSendCount作为多发送有保证策略的属性，有权重的循环策略中的每一个中间件的权重(weights)。如上所述，可提供额外的公共方法来支持其他的属性。

WmConnectionFactoryImpl具有如下设置和获取功能：

·setBrokerCluster：为连接工厂赋予作为群的中间件列表。

·getBrokerCluster：获取根据连接工厂定义的群中间件的列表。

·setClusterPolicy：取回负载平衡策略的名称。

·getClusterPolicy：定义与连接工厂的连接一起使用的负载平衡策略。

·isClusterPolicy：如果该连接工厂与中间件群有关则返回真，否则，返回假。

WmClusterPolicyManager为负载平衡组成组件进行策略管理。其可从其他接近策略元数据存储的程序调用获得。可调用WmClusterPolicyManager以，例如，发现已存在的策略以及产生用户的订制的策略。基于此，WmClusterPolicyManager接口(Interface)包括如下方法：

·getPolicyManager：查找用于该应用的策略管理器。

·getClusterBrokerInfo：为连接的客户返回群中间件集合，基于当前策略。如果没有指定的中间件，则返回空集合，群连接异常处理器将视其为连接错误。

·getAvailablePolicyNames：为该应用取回可用的策略名称。

·insertPolicy：产生并插入订制的策略。

·deletePolicy：从可用策略列表中移除策略。

·getPolicy：基于策略名称查找运行的策略实体。

WmClusterPolicy定义的一个方法，getNextBrokers()，其用于返回连接的中间件的优先的集合，基于指定的中间件群。

WmClusterTrackable提供用于诊断的嵌入到跟踪工具中的方法：

·setTracker：从负载平衡应用中调用该方法以配置跟踪工具或负载平衡中使用的数据库。跟踪器重应当运行WmClusterTracker接口。如果没有设置跟踪器，则负载平衡不会写任何数据。

·setTrackerCategories：定义记录的动作数据的类型。

WmClusterTracker提供记录消息的方法：

·Track：如果需要对动作进行跟踪则写入记录。

·setTrackerCategories：使应用配置记录的动作的类型。

如图13～15所示，描述了群连接、策略管理器、以及中间件选择器的类的一个具体示意图。如图13所示，群连接的组成组件包括如下类：

·WmClusterConnectionImpl：当在群连接工厂上产生JMS连接时组件该类，该类作为负载平衡功能(函数)的启动程序。其执行WmClusterTrackable接口，并且其为处理群连接功能的WmConnectionImpl的组成部分。

扩展WmConnectionImpl的几个子类以提供群行为。这些子类包括，例如：

WmClusterQueueConnectionImpl，WmClusterTopicConnectionImpl，

WmClusterXAConnectionImpl，WmClusterXAQueueConnectionImpl，以及

WmClusterXATopicConnectionImpl。

·WmClusterConnectionWorker：为WmConnectionImpl的子类。其时在负载平衡中的工作者类(worker class)，其管理与中间件的客户连接。

WmClusterConnectionImpl可包括多个WmClusterConnectionWorker实体。

·WmClusterConnectionExceptionHandler：监听并处理连接的相关失败，并更新中间件群状态表。

·WmClusterSessionImpl类：WmSessionImpl的子类，其覆盖用于产生负载平衡的中间客户的会话方法。其还提供负载平衡发布的发布方法。

各种各样的会话实施方案的群扩展包括：

WmClusterQueueSessionImpl，WmClusterTopicSessionImpl，

WmClusterXASessionImpl，WmClusterXAQueueSessionImpl，以及

WmClusterXATopicSessionImpl。

·WmClusterMessageConsumerImpl：WmMessageConsumerImpl的子类，其为负载平衡订阅者实施接收方法。

·WmMessageProducerImpl子类：WmMessageProducerImpl的子类集合，实施群集(clustering)行为。包括WmClusterQueueSenderImpl和WmClusterTopicPublisherImpl。

·WmClusterQueueBrowserImpl：WmQueueBrowserImpl的子类，为将所有物理队列集合为一个群队列的逻辑的实施。可实施新的消息浏览器类。

群连接组成部件还定义了两个接口：

·WmClusterTrackable：允许嵌入式追踪器的接口。WmClusterConnectionImpl实施该接口。

·WmClusterTracker：嵌入式追踪工具或数据库应用实施的接口。

策略管理器，例如，通过提供对中间件选择器为中间件选择标准采用的策略的操作(handlers)，来处理策略的维持和发现。如图14所示，其包括下述类：

·WmClusterPolicyManager：作为策略工厂工作的抽象类。其装载和保存属于相关元数据存储的策略。

·WmClusterPolicy：提供策略的嵌入接口的抽象类。其实施负载平衡算法的通用行为。

·具体策略管理者(Concrete Policy Manager)类：WmClusterPolicyManager的子类，诸如WmClusterJNDIPlicyManager，其实施达到具体元数据存储的细节。

·具体策略(Concrete Policy)类：WmClusterPolicy的子类，诸如WmClusterRoundRobinPolicy，其实施特定的算法或规则，用于选择要连接的运行阶段的中间件。

如图15所示中间件选择器用于查找要连接的下一中间件集合。中间件选择器包括如下主要的类：

·WmClusterBrokerSelector：查询策略管理器，分析群中间件状态信息，以为群连接提供可选择的中间件。

·WmClusterBrokerMonitor：为运行阶段信息，周期性的轮询群集的中间件。该轮询间隔可由使用者订制，例如，作为连接工厂属性。

·WmClusterBrokerInfo：保持关于群中的中间件的运行阶段信息，其可以是持续的或非持续的。

图16示意了具体实施例中的负载平衡中间件JMS应用的整体结构。如图16所示以及在上述所提及的，负载平衡中间件JMS应用有三种行动者(actor)类型，包括发布者应用1602、中间件群1102、以及订阅者应用1606。JMS负载平衡订阅者和发布者1604和1608以与普通的JMS发布者和订阅者相同的方式工作，例如，以与连接1610和1612相关的方式工作，分别的，并处理消息的发布/订阅。上述的很多“发布/订阅(pub/sub)”行为也应用到负载平衡的具体实施例中。具体实施例中的负载平衡特征可被自动使能，例如，当JMS应用启动与中间件群连接工厂的JMS连接时。负载平衡类可运行于与应用相同的虚拟机器(例如，JavaVirtual Machine或JVM)中，而负载平衡的组成组件的机制对应用来说是透明的。

如图16所示，负载平衡发布者1604和订阅者1608与以中间件群1102形式存在的中间件106集合连接。中间件群1102中的中间件106作为一个整体工作，以共享工作负载并提供负载平衡。在JMS API中可提供负载平衡功能的实施，其由发布者应用1602或订阅者应用1606调用。

群连接1610和1612可在群1102的两侧工作。发布者应用1602与群连接1610连接，且每一个群连接1610都与群1102中的一个或多个中间件106连接，基于采用的策略。相似的，订阅者应用1606也可与群连接1610连接，其与群1102中的每一个中间件106连接。这些与中间件106的直接连接可由群连接组件来维持。

现在描述具体实施例中的运行阶段行为。具体的，在运行阶段可通过JMS连接使能负载平衡功能，该功能改变连接和发布/订阅流。

从发布者应用中，应用代码调用连接的产生。这会启动群连接和其相关类的产生，例如，以管理与中间件群的连接。在生成连接过程中，群连接首先咨询中间件选择器以发现要连接的第一中间件集合。当应用产生会话时，安置群会话。对群会话的发布调用群连接，以更新当前的连接。在循环策略的情况中，例如，在消息被发布前，群连接与下一中间件连接。

如果中间件不可用，更新中间件状态表，负载平衡将会在进行连接时跳过该中间件。

当使用者应用关闭JMS连接时，相关的群连接被关闭，而相关的负载平衡类也被破坏。

图17与图11和16类似，图17为具体实施例中的与负载平衡发布/订阅模型有关的各元素的示意图。具体的，图17示意了经由整合服务器102的请求，例如，经由pub.jms.send方法，相应的，该方法调用JMS API 914。在请求/发布客户侧，经由JMS API 914建立与每个中间件106的连接，该中间件106配置在中间件群1102中(例如，如图17左侧所示)。在响应/订阅侧(如，图17中的右侧所示)，整合服务器102包括被配置来调用一个或多个触发服务502的触发器(如，JMS触发器)。在响应/订阅侧的整合服务器102，类似于在请求/发布客户侧上的整合服务器，与配置在中间件群1102中的中间件106连接。循环策略如何在图16和17中示意的原理结构中实施的细节将根据图18和19进行解释。

图18示意了在具体实施例中的依据循环策略的负载平衡发布的流程。类似的，当订阅者应用产生JMS连接时，产生群连接，如图19所示。产生群会话以代替规则的JMS会话。当订阅者应用构建订阅者时，群连接产生助手(helper)类实体，例如，以处理与群中所有中间件的连接。在负载平衡应用中，放置群消费者子类实体。

在所有订阅者中放置订阅，并在领域(territory)中间件中强置仅处于本地的订阅。当消费者接收消息时，所有群消费者接收来自所有中间件的消息。从中间件接收的消息可以有或者没有预定的次序。

群连接、群会话、以及群消费者可被破坏，当订阅者应用关闭连接或结束时。

具体实施例中提供了在群环境中的交易消息的供应。例如，在具体实施例中可提供在JMS群集的环境中的JTA/XA的供应。基于此，JMS实施可起到在分发交易中的资源管理器的作用，其作用的方式可与数据库处理分发交易类似。在典型的脚本中，应用服务器起到交易管理器的作用，作为在两个或多个JMS会话和/或数据库资源之间的两阶段提交(two phase commit，简称2PC)交易。下表提供了示例的设计的变化使能在具体实施例中的JMS群环境中的XA全局交易的实施：

类(Class)	方法(Method)	描述(Description)
			WmXAConnectionFactoryImpl	Javax.jms.XAConnectioncreateXAConnection()throwsjavax.jms.JMSException	通过使用mXAConnectionFactoryImpl JMS提供者实施JTS支持，其可用来产生群集的XA连接和XA会话
WmClusterXAConnectionImpl	public XASessioncreateXASessionthrows JMSException	这将会返回WmClusterXASessionImpl实体。WmClusterXASessionImpl封装与群中的每一个中间件连接有关的子辈会话
			com.webmethods.jms.loadbalance.connection.WmClusterXASessionImpl	public XAResourcegetXAResource()	向调用者返回XA资源。该被返回的XAResource采用WmClusterXASessionImpl代表作为整体的群，而不是在群中的独立的中间件会话。交易管理者为参与全局交易的每一个连接获取XAResource。通过获取其XAResource可以控制对XAResource的交易分配。交易管理者使用XAResource将会话分配给交易；准备及确认在交易上的工作；等等

public void start(Xid xid，intflags)throwsXAExceptionpublic void end(Xid xid，intflags)throwsXAException

对参与分发交易的XAResource，使用start方法与交易对象一起将XAResource实体加入列表，使用end方法从列表中清楚。该方法启动在xid中定义的交易分支侧的工作。如果定义了TMJOIN，该start用于加入资源管理器预先发现的交易。交易管理器采用start方法将全局交易与资源连接起来，并且其使用end方法断开交易与资源的连接。资源管理器可支持将全局交易与所有在其数据上执行的工作连接起来，该数据为start和end方法之间调用的数据。在群集的环境中，WmClusterXASessionImpl中的start方法将其授权给群中的独立的中间件的子辈Xasession/XASession。所有属于该全局交易的消息被路由至群中的单个

		中间件，这是由群策略(循环、粘性的)确定的。在XASession上的下一个全局交易消息将被分发给下一个中间件。每一个交易分支接收一个准备-确定的(prepare-commit)调用的集合，在2阶段确认(2PC)过程中，该设计是合适的。WmClusterXASessionImpl将会保持xid的哈希图(HashMap)和处理特定交易的子辈中间件会话。这在调用start()时置入，并应用到随后的XA方法，类似结束、准备、确认以了解该中间件会话和这样的中间件连接，在该中间件连接上将处理当前交易命令。
			WmClusterXASessionImpl	public int prepare(Xidxid)throws XAException	请求资源管理者为在xid中定义的交易的交易命令作准备。该方法将内部地确定在群中的正确的(right)中间件会话，该中间件处理该特定的交易并发布基于相应的连接的准备。

	public void rollback(Xidxid)throws XAException	通知资源管理器重新运行在交易分支一边上的工作。该方法将内部地确定在群中的正确的中间件会话，该中间件处理该特定的交易并发布基于相应的连接的重新运行。
				public void commit(Xidxid，boolean onePhase)throws XAException	确认xid定义的全局交易。该方法将内部地确定在群中的正确的中间件会话，该中间件处理该特定的交易并发布基于相应的连接的确认。
	public Xid[]recover(intflag)throwsXAException	从资源管理器获取已准备的交易分支的列表。该方法将内部地确定在群中的正确的中间件会话，该中间件处理该特定的交易并发布基于相应的连接的恢复。
				public void forget(Xidxid)throws XAException	告知资源管理器遗忘(forget)关于启发式的已完成的交易分支。该方法将内部地确定在群中的正确的中间件会话，该中间件处理该特定的交易并发布基于相应的连接的遗忘。

BooleanisSameRM(XAResourcexares)

调用该方法以确定，被目标对象代表的资源管理器实体是否与被参数xares表征的资源管理器实体相同。如果下层的群集的连接对象对于两个资源都是相同的，返回真。

图20示意了，采用中间件群的有保证的多发送策略的实施中使用的组件的具体实施例。图20包括与图17中相似的元素和连接。不同的是，图20中采用了有保证的多发送策略，其中3个中间件中的2个提供有保证的消息传输。当整合服务器102向JMS API 914发送消息时，在JMS API 914和中间件群1102中的中间件106之间3个连接中的2个位XAR(XAR资源)连接。相似的，发布/请求整合服务器102(图20中的左侧)包括交易管理器2002。该交易管理器2002被配置为从JMS API 914接收确认XAR调用。

如图21所示，为具体实施例中的实施复合策略的负载平衡中间件JMS应用的组成结构示意图。图21与图16类似，不同的是，图21示意了策略的“分层”，其中一层在另一层之上，例如，通过提供复合的群连接，该复合群连接连接两个或更多个群连接。进一步的，如图21所示，发布者1604和订阅者1608a与定义了复合群的群1102a和1102b的集合连接。这些群1102a和1102b作为一个整体工作并共享工作负载，相应的提供负载平衡和/或副本依赖，例如，基于已实施的复合群策略。

JMS负载平衡发布者和订阅者已于普通的JMS发布者和订阅者相似的方式工作，即他们与连接和处理消息的发布和订阅有关的方式。具体来说，发布者应用1602的发布者可与基于第一策略的复合群连接2102连接。复合群连接2102可，相应的，与多个群连接1610a和1610b连接。这些群连接1610a和1610b可基于第二策略(或多个不同策略)进行工作，这样进一步的负载平衡可以基于每一个群A和B 1102a和1102b执行。通过和/或嵌入在复合群连接2102中实施策略，第一群连接1610a，以及第二群连接1610b可具有相同或不同的策略，在本发明的不同具体实施例中。

使用者可对连接工厂进行具体配置。基于使用者的配置可包括或需要如下步骤，例如：

·决定复合群策略，该策略确定消息如何被分发至整个群。例如，使用者可选择多发送尽力而为策略来复制在每个群中的消息。用于负载平衡的复合群策略可为，例如，循环和粘性的策略。

·将子辈群连接工厂与复合连接工厂连接。每一个子辈群连接工厂可代表一个群，而群策略管理其接收的消息是如何被分发至该群的中间件的。

·每当JMS应用启动与复合群连接工厂的JMS连接时，使能负载平衡特性(例如，自动地)。

·使能在群两侧的复合群连接。发布者可与复合群连接相连，该复合群连接，相应的，基于策略将任务委派到子辈群连接中。维持在群中的所有中间件连接的群连接可进一步基于其策略将消息分发至恰当的中间件。该策略可以是，例如，循环、粘性的、多发送尽力而为的、文档大小的、有权重的，等等。

在具体实施例中，使能复合群策略不影响JMSAPI接口。在以下例子中对其细节进行描述。

WmConnectionFactoryImpl可包括如下属性，这些属性适用于复合群：

·CopyOnWriteArrayList<WmConnectionFactory>_compositeClusterConnFactories-复合中间件群定义作为子辈群连接工厂的次序列表。WmConnectionFactoryImpl的实体及其策略和中间件群定义可保存在该属性中，当使用者产生了复合连接工厂时。

·private String_clusterPolicyName-在复合群连接工厂中定义的负载平衡策略的名称。可能的值包括，例如，ROUND_ROBIN、STICKY、RANDOM  或MULTISEND_BESTEFFORT。

·private boolean_isCompositeFactory-定义连接工厂是否是复合因素。

WmConnectionFactoryImpl可包括如下新的设置和取得函数：

getCompositeChildConnFactories(CopyOnWriteArrayList<WmConnectionFactory>)	为复合连接工厂分配子辈群连接工厂的列表
		publicCopyOnWriteArrayList<WmConnectionFactory>	返回被分配给复合连接工厂的子辈群连接工厂的列表
getCompositeChildConnFactories()
		Boolean is CompositeChildConnFactory()	如果该连接工厂与复合群定义连接，则返回真；否则，返回假

在数据包中，复合群连接组件可包括如下类(例如，com.webmethods.jms.loadbalance.connection.composite)。群连接组件，如前所述，在多中间件中进行负载平衡，这是设计时要考虑的。该组件可扩展为复合群以在群中进行负载平衡。

·public class WmCompositeClusterConnectionImpl扩展

WmClusterConnectionImpl和实施WmClusterTrackable。当基于复合群连接工厂产生JMS连接时，构建WmCompositeClusterConnectionImpl，并作为负载平衡功能的启动进行服务。其遵循复合模式，并扩展子辈类WmClusterConnectionImpl。

所有的JMS连接功能都可被委派给基于策略的子辈群连接的实施。

WmCompositeClusterConnectionImpl的几个子类可被扩展以提供群集行为。这些子类可包括，例如，WmCompositeClusterQueueConnectionImpl，WmCompositeClusterTopicConnectionImpl，WmClusterXAConnectionImpl，WmCompositeClusterXAQueueConnectionImpl，以及WmCompositeClusterXATopicConnectionImpl。

·WmCompositeClusterConnectionWorker是WmClusterConnectionImpl的子类。其为负载平衡中的工作者类，管理与群的连接。

WmCompositeClusterConnectionImpl维持

WmCompositeClusterConnectionWorker实体的哈希图，该实体提向每一个子辈群连接工厂对象提供信息。这有助于使能启动，将被并行执行的发布任务，为每一个子辈群连接。

·WmCompositeClusterSessionImpl为WmClusterSessionImpl的子类，并覆盖用于负载平衡的产生中间件客户的会话方法。其还提供用于负载平衡发布的发布方法。

各种会话实施例中的群集的扩展可包括，例如，WmCompositeClusterQueueSessionImpl  ，WmCompositeClusterTopicSessionImpl  ，WmCompositeClusterXASessionImpl，WmCompositeClusterXAQueueSessionImpl，以及WmCompositeClusterXATopicSessionImpl。

·WmCompositeClusterMessageConsumerImpl是WmMessageConsumerImpl的子类，其实施用于负载平衡订阅者的接收方法。

·WmCompositeMessageProducerImpl子类是WmClusterMessageProducerImpl的子类集合，其实施群集行为。这包括，例如，

WmCompositeClusterQueueSenderImpl和

WmCompositeClusterTopicPublisherImpl。

·WmCompositeClusterQueueBrowserImpl是WmQueueBrowserImpl的子类，其实施将所有物理队列集合为一个群队列的逻辑。

在具体实施例中，策略管理者可包括如下与复合策略一起使用的类和/或功能：

·WmClusterPolicy-提供策略的嵌入接口的抽象类。其实施负载平衡算法的一般行为。

·getNextPublishCluster-查找下一群以发布消息作为每一复合群策略。

·具体策略类(Concrete Policy classes)-WmClusterPolicy的子类，如，WmClusterRoundRobinPolicy。其实施特定的算法或规则以选择要连接的运行阶段群。

如前所述，在具体实施例中描述了一些失效备援脚本。下述为失效备援脚本和其被处理的方式的具体描述。

·在第一个例子中，如果中间件服务器在群初始化时停机并在发布时随即启动，在活跃的中间件列表中的中间件被用于在运行阶段的发布。

·在第二个例子中，如果在发布操作中重启动中间件，则其不会被用于发布直至其成功并完整地重启。在该阶段，中间件群列表中的剩下的中间件可被用于发布并共享工作负载。

·在第三个例子中，如果在发布操作时中间件服务器停机，JMS客户API保持不停的尝试与中间件服务器进行重连接。属性“com.webmethods.jms.reconnectAttempts”定义JMS客户API尝试与中间件重连接的次数。在尝试次数之内，如果中间件服务器在运行中，则其会被用于发布。可配置的重连接间隔(reconnectInterval)属性可定义重连接尝试之间的间隔，在具体实施例中。

·在第四个例子中，如果在重连接次数之内中间件服务器为不可用的，则其不可用于发布直到重启JMS客户/应用。使用者可适当地设置重连接尝试值，如果其希望使用变为可用后的原故障服务器进行发布。

·在具体实施例中默认的重连接尝试值可为1，虽然在特定的实施例中可以设置或重置该值。例如，可产生调用WmJMSConfig.setReconnectAttempts(int reconnectAttempts)的函数(function)，或可在wmjms.properties的配置文件中设置属性“com.webmethods.jms.reconnectAttempts”的值。

在具体实施例中，JMS API连接结构可被修改为向群连接中委派处理，当该连接与群连接工厂连接时。

如前所述，需要理解的是，在具体实施例中使用者可在群中安装中间件、自动地同步群中的元数据、实施路由策略、动态的扩展体系结构，等等。在具体实施例中，使用者可扩展中间件的体系结构而不需重启任何服务器，实质上提供动态群和自动元数据交换，其中，该动态群可以定义或重新定义为通过“热部署(hot deploying)”向群中增加中间件而不需要请求重启。在具体实施例中，由于路由策略可以分层或复合，使用者可向单个主题或队列实施多个策略。相应的，可基于非常简单的基础建立的模块的设置支持非常复杂的消息传输模式。

图22～23示意了使用整合服务器调用发布服务或/和触发器的不同的技术。在图22～23中示意了相同的使用情况，称为，通过整合服务器上的单个服务发布三个消息(例如，JMS消息)，向三个不同中间件中的每一个发送一个消息，调用一个触发器，并使用一个服务以最终处理消息。在图22中，客户2202尝试调用发布服务A。为完成该动作，客户2202使用任意的系统(本例中为系统A)2204发布消息。然后，通过依据于已选择的策略的群连接，将该消息传递给基于策略的中间件群2206中的每一个中间件2208a～c(在本例中的脚本需要向所有三个中间件2208a～c发送消息)。适当的中间件2208调用与消息有关的服务。相应的，基于客户侧的按策略的负载平衡方案，单个消息可路由至多个中间件。此外，采用图22中的方案，可增加多个整合服务器和多个中间件；当然，仍然可调用单个发布服务和触发器。

不同于图22中的例子，图23涉及与硬件负载平衡器2304相连的客户2302。该硬件负载平衡器2304不是基于客户的。在任何事件中，为向每一个中间件2208a～c传递相同的消息，相同的消息被分发给每一个相连的系统2204a～c。换句话说，硬件负载平衡器向三个不同的系统发送三个分开的消息以通过三个不同的中间件调用单个服务。最终，通过三个中间件中的一个调用服务。

需要理解的是，图22的设置是对图23的设置的改进。这种改进是可行的，例如，这是因为在客户处进行策略的定义，通过使用这些负载平衡策略而不必依赖硬件负载平衡器的中间件群完成向/经过中间件的消息路由，以及特定的系统-中间件组成。

这也使获得更多好处变得可能。例如，实施保证的多发送功能变得可能，例如，使保证“所有或都没有”的向中间件集合的分发形式的逻辑变为可能，除XA编程模型和标准的JMS1.1能力之外。另一个例子是，复合群策略提供在多中间件中进行消息确认的能力。还有一个例子是，基于策略的消息路由使得当前策略可在以后被扩展和建立。例如，虽然可向基于简单定义策略(例如，循环、粘性的、多发送尽力而为、多发送有保证的、随机等策略)的群中的中间件发布消息，可对这些策略进行组合或分层以提供进一步的复合策略。

在另一个例子中，客户侧的API可用于配置中间件群中的中间件，为元数据同步做准备。消息产生者和消费者可使用群中的可用中间件来发送和接收消息并，在有失败事件时，可以使用剩下的中间件而不需影响发布-订阅活动，如果在策略中进行了这样的定义的话。相对的，在标准JMS的实施中，如果发生失败的话客户通常需要重新连接服务器。尽管硬件群集是另一种的选择，但是需要理解的是，其需要启动另一个具有相同元数据的节点，而直到节点已经启动服务客户请求否则该系统不可用。

在另一个例子中，可从群中增加或移除中间件而不需要调整客户程序。而，客户程序可查找群连接工厂(例如，使用JNDI)并进行发布-订阅活动。相对的，在标准JMS的实施中，通常需要为所有的中间件定义单独的连接，如果增加或更新了新的服务则通常必须定义新的连接。在具体实施例中，当向群中增加新节点时，可减少(而且有时完全消除)对将被定义的新的JNDI连接对象的需求。

需要理解的是，上述描述的类、方法、属性等等为具体的例子。换句话说，可以在不同的具体实施例中提供相同和/或不同的类、方法、属性等等。例如，可提供另一公共方法来组建群和复合连接工厂。

应当理解的是，此处使用的术语：系统、子系统、服务、程序化的逻辑电路和类似的对象可以由任何合适的软件、硬件、固件和/或类似物的组合来实现。

此处所描述的是目前认为的与本发明相关的最可行和优化的实施例，以上所述的实施并不构成对该技术方案保护范围的限定。任何在上述实施方式的精神和原则之内所作的修改、等同替换和改进等，均应包含在该技术方案的保护范围之内。

Claims (25)

1.一种在应用整合系统，包括：

发布应用，被配置为产生和发送消息，所述消息依据使用者定义的复合策略发送，所述复合策略包括至少第一和第二策略层；

第一和第二中间件群，每一个所述中间件群包括多个中间件，所述每个中间件被配置为从发布应用中继消息到至少一个订阅应用；

与所述发布应用连接的复合群连接；以及

与所述复合群连接连接的多个群连接；

其中，所述复合群连接被配置为依据所述第一策略层向至少一个所述群连接路由消息，以及

每一个所述群连接被配置为依据所述第二策略层向至少一个中间件路由消息。

2.如权利要求1所述的系统，其特征在于，每一个所述策略层基于下述策略中的一种：(a)循环负载平衡策略，(b)粘性的负载平衡策略，其中向特定的中间件进行发布直到产生失败，当产生失败时向不同的该特定的中间件的另一中间件进行发布，(c)随机分配，(d)文档大小策略，其中基于文档大小向不同的中间件路由消息，(e)有权重的循环策略，其中为每一个中间件分配权重，该权重表征中间件相对于其他中间件的服务执行程度以及与其他中间件相比被发送给每一中间件的消息的相对数量，以及(f)向多个中间件发送消息的多发送策略。

3.如权利要求1所述的系统，其特征在于，所述第一策略层与所述第二策略层不同。

4.如权利要求1所述的系统，其特征在于，至少一个所述策略层基于向多个中间件发送消息的多发送策略。

5.如权利要求4所述的系统，其特征在于，所述多发送策略为尽力而为的多发送策略，在所述尽力而为的多发送策略中如果至少一个所述中间件接收到消息则认为成功。

6.如权利要求4所述的系统，其特征在于，所述多发送策略为有保证的多发送策略，在所述有保证的多发送策略中仅当M个中间件中的N个接收到消息时认为成功，其中，N为使用者定义的常数，M为相关群中的中间件的数目。

7.如权利要求4所述的系统，其特征在于，所述多发送策略包括副本消息检测，通过比较与所述消息有关的通用唯一标识UUIDs进行副本消息检测。

8.如权利要求4所述的系统，其特征在于，所述多发送策略包括在所述中间件中至少一些中的消息确认。

9.如权利要求1所述的系统，其特征在于，进一步包括至少一个订阅应用，所述订阅应用被配置为接收来所述发布应用的消息并依据所述消息引发要被执行的服务。

10.如权利要求1所述的系统，其特征在于，进一步包括：

与每一个所述订阅应用连接的订阅复合群连接；以及

与所述订阅复合群连接连接的多个订阅群连接；

其中，每一个所述订阅复合群连接依据第一订阅策略层被配置为向至少一个所述订阅群连接路由确认消息，以及

每一个所述订阅群连接依据订阅策略层被配置为向至少一个中间件路由所述消息。

11.如权利要求1所述的系统，其特征在于，所述消息为JMS消息。

12.在应用整合系统中的消息路由方法，包括：

提供发布应用；

提供第一和第二中间件群，每一个所述中间件群包括多个中间件，所述每个中间件被配置为从发布应用中继消息到至少一个订阅应用；

连接复合群连接与所述发布应用；

连接多个群连接与所述复合群连接；

根据所述发布应用产生消息；以及

依据使用者定义的包括至少第一和第二策略层的复合策略从所述发布应用向所述中间件群发送消息，所述消息依据所述第一策略层被从所述复合群连接路由至至少一个所述群连接，所述消息依据所述第二策略层被从至少一个所述群连接路由至至少一个所述中间件。

13.如权利要求12所述的方法，其特征在于，每一个所述策略层基于下述策略中的一种：(a)循环负载平衡策略，(b)粘性的负载平衡策略，其中向特定的中间件进行发布直到产生失败，当产生失败时向不同的该特定的中间件的另一中间件进行发布，(c)随机分配，(d)文档大小策略，其中基于文档大小向不同的中间件路由消息，(e)有权重的循环策略，其中为每一个中间件分配权重，该权重表征中间件相对于其他中间件的服务执行程度以及与其他中间件相比被发送给每一中间件的消息的相对数量，以及(f)向多个中间件发送消息的多发送策略。

14.如权利要求12所述的方法，其特征在于，所述第一策略层与所述第二策略层不同。

15.如权利要求12所述的方法，其特征在于，至少一个所述策略层基于向多个中间件发送消息的多发送策略。

16.如权利要求15所述的方法，其特征在于，所述多发送策略为尽力而为的多发送策略，在所述尽力而为的多发送策略中如果至少一个所述中间件接收到消息则认为成功。

17.如权利要求15所述的方法，其特征在于，所述多发送策略为有保证的多发送策略，在所述有保证的多发送策略中仅当M个中间件中的N个接收到消息时认为成功，其中，N为使用者定义的常数，M为相关群中的中间件的数目。

18.如权利要求15所述的方法，其特征在于，进一步包括通过比较与所述消息有关的通用唯一标识UUIDs检测副本消息。

19.如权利要求15所述的方法，其特征在于，进一步包括对所述中间件中至少一些中间件的消息的接收进行确认。

20.如权利要求21所述的方法，其特征在于，进一步包括提供至少一个订阅应用，所述订阅应用被配置为接收来所述发布应用的消息并依据所述消息引发要被执行的服务。

21.如权利要求12所述的方法，其特征在于，所述消息为JMS消息。

22.如权利要求12所述的方法，其特征在于，进一步包括在应用整合系统运转时部署增加的中间件和/或发布应用。

23.如权利要求12所述的方法，其特征在于，进一步包括重新定义复合策略。

24.一种在应用整合系统中调用目标服务的方法，所述方法包括：

提供第一和第二客户系统，所述系统一起实施发布/订阅消息交换模型；

提供至少一个中间件群，所述至少一个中间件群包括多个中间件服务器；

通过所述第一客户系统产生消息，所述消息为调用在所述第二客户系统中的目标服务的触发器；

依据所述第一客户系统定义的策略，将所述消息从所述第一客户系统经由在至少一个所述中间件群中的至少一个所述中间件服务器路由至所述第二客户系统；

在所述第二客户系统接收所述消息；以及

通过所述第二客户系统调用所述目标服务。

25.如权利要求24所述的方法，进一步包括：

在应用整合系统运转时部署增加的中间件和/或客户系统；以及

根据应用整合系统的组成更新元数据。

Images