CN101416209A - 基于策略的消息聚集框架 - Google Patents

Abstract

由始发应用程序生成的消息基于配置策略被聚集成批量消息。该配置策略包含用于将消息聚集成批量消息的业务逻辑。一旦批量消息聚集完成，它就被格式化为单个流输出并且发送至被设计成接收消息的目标应用程序。消息也可被聚集成由始发应用程序控制的批量消息。该消息包括由始发应用程序设置以发出批量消息完成的信号的指示符。一旦批量消息完成，它就被格式化为单个流输出并且发送至被设计成接收消息的目标应用程序。

Description

基于策略的消息聚集框架

背景

在当今的全球经济中，公司经常需要集成来自各种源的应用程序、系统和技术。通常，这些公司创建用于通过电子手段并以最少的人工干预从一个计算机应用程序到另一个计算机应用程序的、按照达成协议的消息标准的结构化信息的计算机到计算机的交换的系统。消息标准的示例包括用于与健康护理相关的临床和管理数据的健康等级7(HL7)；用于关于产品、资产、服务以及位置的信息的标识和通信的GS1系统；用户财务数据的SWIFT；以及用于按照用于传送各种商业交易数据的达成协议的消息标准交换结构化信息的EDI。

如图1所示，商业企业可以按各种消息格式与各种合伙人进行通信。例如，该商业企业可以按XML格式与顾客进行通信；该商业企业可以按EDI或平面文件消息格式与供应商应用程序进行通信；该商业企业可以按SWIFT消息格式与财务应用程序进行通信；并且该商业企业可以按某一其他工业标准消息格式与后勤应用程序进行通信。

不幸的是，消息的种类和数量使通信变得复杂并造成了典型商业企业中的效率低下。虽然用于聚集消息的解决方案可以用自定义软件代码来编写，但是这些解决方案增加了企业中的复杂性和成本并且只适于特定情况。

概述

本发明的各方面克服了已知的结构化消息的计算机到计算机交换中的一个或多个缺陷。一种可扩展的、基于策略的消息聚集框架将消息聚集成批量消息，该批量消息准许多个消息作为单个输出流来发送至目标应用程序。

在一个方面中，本发明涉及基于策略的消息聚集，其中聚集基于包含用于将消息聚集成批量消息的业务逻辑的策略。在另一个方面中，本发明涉及基于应用程序的消息聚集，其中源应用程序在消息中设置指示符，该指示符标识将被批量化的消息并且在批量化完成时发出信号。

因为典型的商业企业生成关于关键业务通信的许多消息，所以包含本发明的各方面的消息聚集系统是可靠且可扩展的。同样，可以实现消息聚集以通过累积消息并且在用于发送该消息的通信介质的成本最低时发送该消息来降低成本，并且通过经由一次发送一束消息来降低发送各单个消息所涉及的开销以提升性能。

具有用于消息聚集的计算机可执行指令的计算机可读介质包含本发明的其他各方面。或者，本发明的各实施例包括各种其他方法和装置。

提供本概述以便以简化的形式介绍将在以下详细描述中进一步描述的一些概念。该概述不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

其它特征的一部分将是显而易见的，一部分将在下文中指出。

附图简述

图1是示出根据现有技术的结构化消息的计算机到计算机交换的流程图。

图2是示出根据本发明的实施例的用于消息聚集的计算系统环境的框图。

图3是示出根据本发明的实施例的消息聚集的示例性流程图。

图4是示出可在其中实现本发明的合适的计算系统环境的一个示例的框图。

在全部附图中，相应的附图标记指示相应的部分。

详细描述

进一步参考各附图，图2示出了用于消息聚集的计算系统环境的一个实施例。可以实现消息聚集以满足多种业务需求。例如，商业企业以各种消息格式与各种合伙人进行通信。消息聚集允许在容纳指定时刻的通信的同时以降低的成本提升性能。在该示例中，商业企业可具有每周从供应商订购供应品的策略。应用程序可以允许该企业通过生成定址到供应商的消息来全周订购供应品。本发明的各实施例准许在该商业企业处将这些消息聚集成批量消息以便每周发送至该供应商的应用程序以供履行处理。

作为另一个示例，想象企业正从顾客接收大量购买订单。为了满足每个顾客的购买订单，该企业从合伙公司订购物品并且该企业使用EDI来将订单传送给该合伙公司。但是，与该合伙公司的连接只在一天中的特定时间可用。因此，该商业企业需要累积对于该合伙公司的所有订单并且在一天中的正确时间期间发送这些订单。此外，企业经常需要为与合伙公司的连接时间支付费用。在这种情况下，将所有消息捆绑在一起并且大约每几个小时打开一次连接，并且一次发送该单个消息束是有利的。此外，本发明的各方面准许聚集各种消息格式的消息，诸如XML、EDI、平面文件、SWIFT、或某一其他工业标准消息格式。

如图2所示，源应用程序202生成并发送消息。本领域的技术人员熟悉发送定址到发送端口的消息。根据本发明的各方面，消息引擎204接收每条消息并且与消息地址中的发送端口相关联的一个或多个批量化器206接收并聚集消息。在一个实施例中，源应用程序202和目标应用程序212通过端点与消息引擎204进行通信。端点是位置的逻辑表示(例如，以URL形式表达)，其为接收到或已发送的数据提供物理地址。在该实施例中的端点是双向的，并且使用这些端点来将消息送入消息引擎204以及从消息引擎204中获得消息。

在另一个实施例中，消息引擎204还将消息写入数据存储208。如果批量消息中的消息彼此独立，则本发明的各方面可基于由业务配置策略定义的所选参数来汇编消息。例如，批量配置策略包含用于确定批量消息中的消息数量、批量消息中的累计字节数、批量消息中的消息类型、和/或用于累积消息的时间段的业务逻辑。

在一个实施例中，批量化器206在发送端口上配置(例如，BatcherType(批量化器类型)和BatcherLocation(批量化器位置))。例如，可为此利用适配器框架代码库并且实现用于存储该配置和其他发送端口配置信息的接口。附录A示出包括批量化器接口的包含本发明的各方面的用于外向批量化的消息通信框架的示例性实现。

在另一个实施例中，消息引擎204维护一个或多个批量化器206的实例状态402(见图4)。实例状态402包括与批量化器206相关联的发送端口以及已被定址到该发送端口的消息列表。实例状态402可被存储在数据存储208中。实例状态用于在系统故障的情况下检索与每个批量化器实例相对应的消息。

如果与特定发送端口相关联的批量化器206不存在，则消息引擎204将创建它。通过动态地创建每个批量化器206，按需创建批量化器，这提升了消息聚集系统的可扩展性。此外，批量化器206的动态创建通过消除空闲批量化器的开销并且准许消息引擎204只为活动的批量化器206管理实例状态402而有助于系统性能。

通过将实例状态402以及消息存储在数据存储208中，批量消息可以在系统故障的情况下恢复。在一个实施例中，在重启后，消息引擎204能够访问在故障时正在进行中的批量消息的实例状态402。对于每个实例状态402，消息引擎204创建批量化器206的一个实例。对于在实例状态402的消息列表中的每条消息，消息引擎204将该消息重新发送至批量化器206。一旦该列表中的消息已被重新发送至批量化器206，该批量消息就将是与其在故障时相同的状态。

例如，实例状态402是存储应用程序实例(在该情况下，为Assembler(汇编器)/Batcher(批量化器)实例)的状态的地方。尽管对应于应用程序实例的消息被存储在数据存储中，但还是需要存储关于该应用程序实例的状态的信息以使得该应用程序能够检索该实例信息以在故障后继续处理。订阅独立于实例状态。订阅表定义接收满足特定条件的消息的服务列表(由服务ID来标识)。当消息被发布到消息块(例如，数据存储108)时，该消息块评估条件并且标识哪个服务将接收该消息。该消息块然后在“实例”表中创建该服务的逻辑实例并且在该消息上标记了“InstanceID(实例ID)”后将该消息分派到消息引擎204。

在另一个实施例中，消息包括与批量化器206相关联的批量标识符。在该实施例中，消息块维护订阅表408，该订阅表408定义接收满足特定条件的消息的服务列表(由服务ID来标识)。消息块从源应用程序202接收消息。当消息被发布到消息块时，该消息块评估条件并且确定哪个服务将接收该消息。如果对于该服务的批量化器206的实例不存在，则消息框然后创建该实例。该消息块然后将该消息发送至消息引擎204。消息引擎204对批量标识符求散列以确定批量化器206的正确实例。消息引擎204然后将该消息发送至所确定的批量化器206。

一旦批量化器206接收到消息，它就确定一批消息是否完成。在一个实施例中，批量化器206根据批量配置策略确定该批量消息是否完成。批量配置策略包含用于确定该批量消息何时完成的业务逻辑。该业务逻辑可包括以下各项中的一个或多个：批量消息中的消息数量、批量消息中的累计字节数、批量消息中的消息类型、以及累积消息的时间段。在另一个实施例中，该业务逻辑可包括关于批量消息中的消息的所需排序次序，这允许批量化器206对批量消息中的消息进行排序。

根据本发明的各方面，与消息地址中的发送端口相关联的批量化器206接收并聚集消息。如上所述，批量消息中的消息可彼此独立。在另一个实施例中，批量消息中的消息彼此依赖并且产生消息的代码知晓新批量消息何时开始以及该批量消息应何时完成。在该实施例中，消息包括批量消息结束指示符。如果批量消息结束指示符发出批量消息完成的信号，则批量化器206将完成批量化。

在批量化器206确定该批量消息完成之后，它将该批量消息返回给消息引擎204。消息引擎204将该批量消息发送至汇编器210。进而，汇编器210将批量消息中的所有消息串行化成单个数据流。在一替换实施例中，批量化器206本身将所有批量化的消息串行化成单个输出流。汇编器210将该消息流发送至与被设计成接收该消息的应用程序相关联的目标应用程序212。

图3是示出消息聚集的一个实施例的各方面的示例性流程图。在302处，消息引擎204从源应用程序202接收定址到发送端口的消息。在304处，消息引擎204验证与该发送端口相关联的批量化器206的实例是否存在。如果是，则相关联的批量化器206聚集定址到公共发送端口的消息。反之，如果与该发送端口相关联的批量化器206不存在，则在306处创建该批量化器的实例。

在另一个实施例中，消息包括与特定批量化器206相关联的批量标识符。在该实施例中，本发明的各方面执行检查以验证与该批量标识符相关联的批量化器206的实例是否存在。如果与批量标识符相关联的批量化器206不存在，则在306处创建该批量化器的实例。

进一步参考图3，在308处消息引擎204将该消息发送至与消息地址中的发送端口相关联的批量化器206。在310处，批量化器206确定该批量消息是否完成。在一个实施例中，批量化器206根据批量配置策略来确定该批量消息是否完成，该批量配置策略包含用于作出该判定的业务逻辑。如上所述，该业务逻辑可包括以下各项中的一个或多个：批量消息中的消息数量、批量消息中的累计字节数、批量消息中的消息类型、以及累积消息的时间段。有利地，顾客能够通过批量配置策略来设置其自己的用于批量化消息的准则。此外，批量化器206可根据由批量配置策略定义的所需排序次序来对批量消息中的消息排序。

在310处，如果批量化器206确定该批量消息没有完成，则在312处将更新该批量消息的实例状态402。实例状态402包括与批量化器206相关联的发送端口以及已被定址到该发送端口的消息列表。该实例状态402可被存储在数据存储208中。反之，在310处如果批量化器206确定该批量消息完成，则在314处从该批量消息中创建消息集。在316处，批量化器206将该消息集发送至汇编器，在汇编器中，消息在单个输出流中被发送至目标应用程序212。目标应用程序212可以是例如，顾客应用程序、供应商应用程序、或财务应用程序。该输出流可以是EDI格式、SWIFT格式、GS1系统、HL7、或如目标应用程序212所指定的某一其他工业标准格式。在输出流被发送之后，在312处更新批量化器的实例状态402。

在一个实施例中，如果当在314处消息引擎204为批量化器206创建消息集或在316处将该消息集发送至汇编器的同时在302处接收到对应于批量化器206的新消息，则在308处消息引擎204将创建批量化器206的新实例。该过程将对批量化器206的新实例在306处继续。这允许消息引擎204处理并发的批量消息，其中当一批量消息在被发送至汇编器210的过程中的同时一新的批量消息在批量化器206的新实例上开始。

例如，当批量化器206确定该批量消息完成时，消息引擎204注意到它并将单个输出流传递给汇编器210。然而，如果与此同时消息引擎204接收到对应于相同发送端口的新消息，则消息引擎204将认识到先前的批量消息完成并创建新的批量化器206，并因此创建新批量消息。多个进行中的(inflight)批量化器206由‘batcherID(批量化器ID)’来标识。

图4示出了服务器430形式的通用计算设备的一个示例。在本发明的一个实施例中，诸如服务器430等的服务器适于在此所示和所描述的其它附图中使用。服务器430具有一个或多个处理器或处理单元和系统存储器。在所示实施例中，系统总线将包括系统存储器在内的各种系统组件耦合至处理器。

服务器430通常具有至少某种形式的计算机可读介质。计算机可读介质，包括易失性与非易失性介质、可移动与不可移动介质，可以是任何可由服务器430访问的可用介质。作为示例而非限制，计算机可读介质包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的信息的任何方法或技术实现的易失性与非易失性、可移动与不可移动介质。例如，计算机存储介质包括RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁带盒、磁带、诸如数据存储108或其它磁存储设备等磁盘存储、或可以用于存储所需信息并可由服务器430访问的任何其它介质。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传送介质。本领域的技术人员熟悉已调制数据信号，其一个或多个特征以将信息编码在该信号中的方式来设置与改变。诸如有线网络或直接线连接等有线介质，以及如声学、射频、红外线及其它无线介质等无线介质都是通信介质的示例。以上的任一种的组合也包括在计算机可读介质的范围之内。

服务器430也可以包括其它可移动/不可移动、易失性/非易失性计算机存储介质。可以在示例性操作环境中使用的其它可移动/不可移动、易失性/非易失性计算机存储介质包括，但不限于，盒式磁带、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等等。

以上所讨论的并且在图4中所示的驱动器或其它大容量存储设备及其相关联的计算机存储介质，为服务器430提供了对计算机可读指令、数据结构、程序模块102、104、106、110以及其它数据402、404的存储。

服务器430可使用至诸如远程服务器406A、406B、406C等一个或多个远程服务器的逻辑连接来在网络化环境中操作。远程服务器可以是个人计算机、服务器、路由器、网络PC、对等设备或其它常见的网络节点，并且通常包括以上关于服务器430所描述的许多或所有元件。图4所示的逻辑连接包括局域网(LAN)和广域网(WAN)，但也可以包括其它网络。LAN和/或WAN可以是有线网络、无线网络、其组合等等。这样的联网环境常见于办公室、企业范围计算机网络、内联网、以及全球计算机网络(例如因特网)。

当在局域网环境中使用时，服务器430通过网络接口或适配器来连接到LAN。当在广域网络环境中使用时，服务器430通常包括调制解调器或用于通过诸如因特网等WAN建立通信的其它装置。可以是内置或外置的调制解调器经由用户输入接口或其它合适的机制来连接到系统总线。在网络化环境中，相对于计算机130所描绘的程序模块或其部分可被存储在远程存储器存储设备(未示出)中。所示的网络连接是示例性的，并且可以使用在计算机之间建立通信链路的其他手段。

一般地，服务器430的数据处理器通过在不同时间存储在计算机的各种计算机可读存储介质中的指令来编程。例如，程序和操作系统通常在软盘或CD-ROM中分发。从那里，它们被安装或加载到计算机的二级存储器中。在执行时，它们至少部分地被加载到计算机的主电子存储器中。当这些和其它各种类型的计算机可读存储介质包含用于实现下面结合微处理器或其它数据处理器描述的步骤的指令或程序时，在此所述的本发明的各方面包括这样的存储介质。此外，当计算机根据此处所述的方法和技术来编程时，本发明的各方面包括计算机本身。

出于说明的目的，程序和诸如操作系统等其它可执行程序组件在此被示为离散的框。然而可以认识到，这样的程序和组件在不同时间驻留在计算机的不同存储组件中，并由计算机的数据处理器执行。

尽管结合包括服务器430的示例性计算系统环境进行了描述，但本发明的实施例可用于众多其它通用或专用计算系统环境或配置。该计算系统环境不旨在对本发明的任何方面的使用范围或功能提出任何限制。而且，该计算系统环境不应被解释为对在示例性操作环境中所示组件的任何一个或组合有任何依赖性或要求。适用于本发明各方面的公知的计算系统、环境和/或配置的示例包括，但不限于：个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、移动电话、网络PC、小型机、大型机、包括上述系统或设备中的任一个的分布式计算机环境等。

本发明的各实施例可以在由一个或多个计算机或其他设备执行的诸如程序模块等计算机可执行指令的一般上下文中描述。一般而言，程序模块包括但不限于：执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件和数据结构。本发明的各方面也可以在其中任务由通过通信网络链接的远程处理设备执行的分布式计算环境中实践。在分布式计算环境中，程序模块可以位于包括存储器存储设备在内的本地和远程计算机存储介质中。

软件体系结构的上下文中的接口包括软件模块、组件、代码部分、或其他计算机可执行指令的序列。该接口包括例如第一模块，该第一模块访问代表第一模块执行计算任务的第二模块。在一个示例中，该第一和第二模块包括诸如由操作系统提供的应用程序编程接口(API)、组件对象模型(COM)接口(例如，用于对等应用程序通信)、以及可扩展标记语言元数据交换格式(XMI)接口(例如，用于web服务之间的通信)。

接口可以是紧耦合的同步实现，诸如在Java 2平台企业版本(J2EE)、COM、或分布式COM(DCOM)的示例中那样。另选地或另外地，接口可以是松耦合的异步实现，诸如在web服务中(例如，使用简单对象访问协议)那样。一般地，接口包括以下特性的任何组合：紧耦合、松耦合、同步和异步。此外，接口可遵循标准协议、专有协议、或标准和专有协议的任何组合。

此处所描述的接口都可以是单个接口的一部分，或可被实现为独立的接口或其中的任何组合。该接口可以本地或远程地执行以提供功能。此外，该接口可包括比此处所示出或描述的更多或更少的功能。

在操作中，服务器430执行诸如在各附图中所示出的计算机可执行指令来实现本发明的各方面。

除非另有指定，否则此处所示和所述的本发明各实施例的操作的执行或进行的次序不是必需的。即，除非另有指明，否则各操作可按照任何次序执行，且本发明的实施例可以包括比本文所公开的更多或更少的操作。例如，构想了在另一操作之前、同时或之后执行或进行一特定操作是在本发明各方面的范围之内的。

本发明的各实施例可以用计算机可执行指令来实现。计算机可执行指令可以被组织为一个或多个计算机可执行组件或模块。本发明的各方面可以用任何数量和组织的这些组件或模块来实现。例如，本发明的各方面不限于在各附图示出和本文中描述的特定的计算机可执行指令或者特定的组件或模块。本发明的其他实施例可以包括具有比在本文中示出和描述的更多或更少的功能的不同计算机可执行指令或组件。

当介绍本发明或其实施例的各方面的各元素时，冠词“一”、“一个”、“该”、以及“所述”指的是存在该元素的一个或多个。术语“包括”、“包含”、以及“具有”旨在是包括性的，并且意味着可以有除所列元素之外的其它元素。

在不背离本发明各方面的范围的情况下，可对以上构造、产品和方法进行各种改变，以上描述中所包含的以及在附图中所示出的所有一切旨在应被解释为说明性并且没有限制意义。

附录A

外向批量化：批量化器组件包括用于截断批量消息，即决定该批量消息何时完成的逻辑。批量化器组件还封装用于决定批量消息中的消息的次序等的任何其它逻辑。消息引擎组件包括负责与批量化器组件、流水线以及数据交互的代码。

批量化器组件可以实现以下接口：

Interface IAggregator

{

//被调用以初始化批量化器/聚集器。

//可以使用返回的PropertyBag来将

//各种批量化器(聚集器)配置特性传回消息引擎。

PropertyBag Initialize([in]Propertybag pb，//用于传递发送

//端口信息

[in]ICallback pCallback)；

Void AddMessage(IB aseMessage msg)；

}

Interface ICallback

{

//以下方法由批量化器用来指示批量消息何时

//满……

Void BatchComplete(bool bBatchSuccesful，

IMessageSet msgSet)；

//由首先试图进行存储器中的批量化的特定批量化器调用

//然而当它们达到其配置的数据/存储器阀值时

//它们使用该API来将数据持久存储到磁盘。这对于perf也是有用的。

Void PersistMessages(IBaseMessageSet msgSet)；

}

Interface IMessageSet

{

Property-IEnumerator MessageIDList；

Property-IEnumerator MessageList；

}

//在设计时用来从模式中引出特性页

Interface IConfiguration

{

String GetConfiguration()；　　　　//返回聚集器(批量化器)的配置

}

如这些接口所示，可能存在两种类型的批量化器：标准批量化器和高性能批量化器。

标准批量化器允许消息引擎处理所有消息持久存储而无需与批量化器交互。该类型的批量化器在对Initialize()(初始化)的调用中的propertyBag(特性包)中被返回给消息引擎。对于标准批量化器，消息引擎将在每次对AddMessage()(添加消息)的调用之后自动将消息持久存储到实例状态直到批量消息满。

高性能批量化器能够进行纯(pure)存储器中批量化，并告知消息引擎何时持久存储消息。对于这些批量化器，消息引擎不会在每次对AddMessage()调用之后将消息持久存储到实例状态。相反，该批量化器能够在存储器中累积消息。以此方式，当批量消息满时，该批量化器能够对该消息引擎调用BatchComplete()(批量消息完成)并给出IBaseMessageSet(基础消息集接口)。消息引擎然后能够直接执行流水线而不必从实例状态中读取消息。这些批量化器还可具有在存储器中保存消息的配置的阀值。只要批量化器想要将消息转储清除消息/持久存储到磁盘，它都能够调用PersistMessages()(持久存储消息)API来做这件事情。如果批量化器已调用了一次PersistMessages()，则它保证在其用MessageID(消息ID)来调用BatchComplete()之前持久存储所有存储器中消息。

消息引擎交互：

当消息引擎获得去往批量化的发送端口的消息时，它通过查看内部散列表来检查是否已经为该发送端口创建了批量化器组件。如果没有已经创建的批量化器组件，则该消息引擎创建新的批量化器组件并且对该批量化器组件调用Initialize()。

该引擎然后对于该消息对该批量化器组件调用AddMessage()。该批量化器组件查看该消息并决定批量消息是否满。如果批量消息满，则它回调指示成功批量化状态的引擎(ICallback)(回调接口)。如果批量消息没有满，则该批量化器组件在更新其内部状态之后从AddMessage()返回。

对于标准批量化器，当AddMessage返回且批量消息未满时，该引擎将该消息写入实例状态。反之，当批量消息完成时，该批量化器将IMessageSet(消息集接口)返回给消息引擎。该引擎试图访问MessageIDList(消息ID列表)，该列表具有正确次序的消息的消息ID(由批量化器对该列表完成任何种类的排序)。给定MessageIDList，该引擎可以开始以正确的次序从实例状态中拉取消息。该引擎从这些文档中创建消息集并且然后将该消息集给予流水线管理器以执行该流水线。

与标准批量化器相反，高性能批量化器对ICallback周期性地调用PersistMessages()以将消息转储清楚到实例状态。如果更多的消息到达该批量消息，则该引擎对较早创建的批量化器组件调用AddMessage()。回调(ICallback)可与AddMessage()同步调用或可由批量化器组件异步地调用。如果批量消息必需基于时间被截断，则批量化器组件等待对应于该批量消息的窗口定时器，即，如果超时发生则该批量化器组件回调引擎并告知该引擎批量消息已完成。当该批量消息完成时，批量化器将IMessageset返回给该引擎。该引擎首先试图访问MessageIDList(与标准批量化器的MessageIDList相同)。如果该MessageIDList为空，则该引擎试图读取MessageList(消息列表)。该MessageList在批量化器正进行存储器中批量化时具有有效值。如果MessageList存在，则该引擎将创建IBaseMessaegSet并且将执行流水线。

流水线执行：流水线管理器中的接口准许引擎将消息集给予该流水线以供执行。该流水线管理器然后为消息集中的所有消息对汇编器调用AddDocument(添加文档)并且然后汇编消息。

独立消息批量化：

当从代理接收到对应于(为独立批量化配置的)发送端口的第一条消息时，消息引擎创建一哑实例。该引擎维护将SendPortID(发送端口ID)映射到批量化器流水线指针的散列表。在任何时刻只存在一个活动的批量化器组件，其中去往发送端口的任何新消息都将只被馈送给该活动的批量化器组件。其他批量化器组件在例如故障转移情形中可以是非活动的。

从属消息批量化：

对于从属消息批量化，以下在发送端口上配置。发送端口具有通过其用户能够选择将用于形成从属批量消息的特性的选项。例如，如果所选的消息上下文特性是BTS.BatchID，则为该发送端口创建护航(convoy)订阅。每条消息具有至少两个特殊消息上下文特性：(a)用于护航的特性(BTS.BatchID)；(b)由批量化器使用的BTS.BatchEnd＝true/false；(c)也由批量化器使用的BTS.BatchStart＝true/false。特性(b)和(c)在批量化器特性页中配置并且不出现在发送端口特性中。

消息的产生者(工作流时间表或流水线服务)为其对于该发送端口发布的每一消息提升BTS.BatchID。具有相同BTS.BatchID的消息被发送至发送端口的相同实例以供批量化。消息的产生者知道该批量消息何时完成并且将写入BTS.BatchEnd。

为了开始新的批量消息，消息的发布者提升(唯一的)BTS.BatchID并且发布该消息。在检查护航表之后由消息块来创建新实例。

具有相同BTS.BatchID的后续消息由消息块在相同的实例上传送。当这些消息被传送至消息引擎时，它已经知道它们是从属批量消息(发送端口配置)。该引擎将BTS.BatchID散列为正确的批量化器指针。

该批量化器可为从属批量消息执行以下动作：(a)批量化器查看BTS.BatchEnd特性并确定何时截断该批量消息；(b)批量化器处理故障情况，例如，如果用户想要超时；(c)批量化器对消息排序。

该引擎可取决于其是如上所述的标准批量化器还是高性能批量化器来将消息写入当前实例的实例状态。

如果批量消息完成，则该引擎执行汇编器并且发送出该消息。当所汇编的消息被成功发送出(deleteMessage()(删除消息))时，该框架对由于护航而创建的实例执行instanceComplete(实例完成)。所有其他问题(重试/移至下一个传输/灾难性故障等等)类似于独立消息批量化。

从实例状态中读取/向其写入：

当消息被写入实例状态时，该框架首先将messageID(消息ID)写入实例流。然后它调用代理API AddMessageObject()(添加消息对象)。

同样，当将消息写入实例状态时，该框架在相同的事务中对原始消息执行receiveComplete()(完成接收)以从ApplicationQ(应用程序队列)中删除该原始消息。

为了从实例状态中读取消息，该框架使用messageID(消息ID)。换言之，该框架首先读取实例流以获得messageID，并且然后使用它们来获得消息。按照消息ID来拉取消息也维护了次序。

实例故障转移：

如果进程由于某一灾难性故障而终止，则消息块在下一次当该进程恢复时创建哑消息。消息引擎接收该哑消息并且能够标识该消息与正批量化的发送端口相对应。即，在写入该实例的第一条消息的实例状态之前，该消息引擎将目标SendPortID(发送端口ID)以及其他相关信息写入实例状态流。

如果该发送端口是为独立消息批量化配置的，则当一实例进行故障转移时，该发送端口可被给回已经具有在使用中的活动批量化器的消息引擎实例。因此，当保活/哑消息被消息引擎接收到时，该消息引擎在相同线程中消耗存储在实例状态中的整个批量消息。该消息引擎创建新批量化器对象并初始化它。由消息引擎传递到批量化器的特性包指示这是经故障转移的实例。同样，如果可能，该消息引擎还提供批量消息中的消息的数量。该消息引擎然后从实例状态读取所有消息并且对批量化器调用AddMessage()。当该批量化器接收到最后一条消息时，它对该消息引擎调用BatchComplete()。

取决于该批量化器如何配置，它能够使该批量消息通过或失败。如果该批量消息失败了，则该消息引擎挂起该批量消息中的所有消息。

发送传输功能：

成功传输：适配器对来自流水线的消息调用DeleteMessage()。来自Q(队列)的消息已经以completed()(已完成)被接收到，所以删除该InstanceState(实例状态)中的消息。为了从实例状态中删除消息，该框架调用代理APIReleaseMessage()(释放消息)。

重新提交：来自Q(队列)的消息已经以completed()被接收到，所以该框架重试在InstanceState(实例状态)中的消息。发出在重试间隔之后返回的定时器消息。当消息引擎看到该定时器消息时，从该实例状态中读取消息重新开始并且处理继续进行。同样，messageID(消息ID)按序从实例流中读取并且然后消息从该实例状态中拉取。

移至下一个传输：消息引擎将消息发送至实例。当该消息恢复时，该消息引擎知道该消息正移至备份传输并且它试图消耗来自实例状态的消息并且处理该批量消息。

挂起消息：InstanceState(实例状态)中的消息从该实例状态中被拉取出并且使用将这些消息从该实例状态移至suspendQ(挂起队列)的SuspendMessages(MessageId[])(挂起消息)API来挂起。或者，消息可被发送至哑实例并且哑实例被挂起。当该消息恢复时，耗尽实例状态。

批量化的发送端口也被标记以供有序传送。当这发生时，消息引擎甚至在独立批量消息的情况下也不为发送端口创建哑实例。消息引擎自动使用与有序发送端口的默认实例相对应的实例状态。该行为可能由于在放弃代理传送线程之前，消息引擎阻断适配器以确认消息被发送或失败(对该批量消息的回调)这一事实而或多或少地改变。

跟踪：可以在对发送流水线的输入消息与输出消息之间维护一链路。当消息从applicationQ(应用程序队列)被移至实例状态时，对该消息调用ReceiveComplete()(接收完成)从该applicationQ中删除该消息。当这发生时HAT中的状态与当该消息被完全处理(即，DeleteMessage()-转换到ReceiveComplete())时所示的状态有所区别。

Claims (20)

1.一种聚集消息的计算机化的方法，包括：

从至少一个应用程序(202)接收多条消息(302)；

对所接收到的消息执行批量配置策略(306)；

根据所述批量配置策略将所接收到的消息聚集到批量消息中(310)；

将所述批量消息汇编成单个流消息输出(316)。

2.如权利要求1所述的方法，其特征在于，所述单个流消息输出被定址到端点(408)。

3.如权利要求1所述的方法，其特征在于，所述执行还包括维护与所述批量消息相关联的实例状态(402)。

4.如权利要求3所述的方法，其特征在于，还包括将所述实例状态(402)存储在数据存储(108)中。

5.如权利要求4所述的方法，其特征在于，所述接收、执行、以及维护与第一计算机相关联，并且所述数据存储(108)与第二计算机相关联。

6.如权利要求1所述的方法，其特征在于，所述接收还包括将所接收到的消息(404)存储在数据存储(108)中。

7.如权利要求1所述的方法，其特征在于，所述批量配置策略包含用于为所述应用程序(102)批量化所述消息的业务逻辑。

8.如权利要求7所述的方法，其特征在于，所述业务逻辑包括以下策略参数中的至少一个：所述批量消息中的消息的排序次序、所述批量消息中的消息的数量、所述批量消息中的累计字节数、所述批量消息中的消息的一种或多种类型、以及累积消息的时间段。

9.如权利要求1所述的方法，其特征在于，所述聚集还包括根据所述配置策略来对所述消息排序。

10.如权利要求1所述的方法，其特征在于，所述消息遵守EDI(电子数据交换)标准。

11.如权利要求1所述的方法，其特征在于，一个或多个计算机可读介质具有用于执行如权利要求1所述的方法的计算机可执行指令。

12.一种聚集消息的计算机化的方法，包括：

从至少一个应用程序(302)接收多条消息，所述消息包括批量标识符以及批量消息结束指示符；

根据所述批量标识符将所接收到的消息(308)聚集到批量消息中；

根据所述批量消息结束指示符完成所述聚集(310)；

将所述批量消息汇编(316)成单个流消息输出。

13.如权利要求12所述的方法，其特征在于，还包括对所述批量标识符求散列以确定用于聚集所述消息的批量化器的实例。

14.如权利要求12所述的方法，其特征在于，所述批量消息结束指示符发出所述批量消息何时完成的信号。

15.如权利要求12所述的方法，其特征在于，所述单个流消息输出被定址到端点。

16.如权利要求12所述的方法，其特征在于，还包括维护与所述批量消息相关联的实例状态(402)。

17.如权利要求16所述的方法，其特征在于，还包括将所述实例状态(402)存储在数据存储(108)中。

18.如权利要求12所述的方法，其特征在于，一个或多个计算机可读介质具有用于执行如权利要求12所述的方法的计算机可执行指令。

19.一种用于为应用程序(102)聚集消息的系统，所述消息被定址到发送端口，所述系统包括一个或多个计算机可执行组件，包括：

用于从所述应用程序接收消息的消息引擎组件(104)；

批量配置策略(106)，所述批量配置策略包含用于为所述应用程序批量化所述消息的业务逻辑；

用于根据所述批量配置策略(106)将消息聚集到批量消息中的批量化器组件(106)，所述批量化器组件(106)与所述发送端口相关联，所述批量化器组件(106)从所述消息引擎(104)接收定址到所述发送端口的消息；以及

其中如果与所述发送端口相关联的批量化器组件(106)不存在，则所述消息引擎组件(104)创建与所述发送端口相关联的批量化器(106)的新实例。

20.如权利要求19所述的系统，其特征在于，所述消息引擎组件(104)与第一计算机相关联并且维护存储在与第二计算机相关联的数据存储中的所述批量消息的实例状态(402)，所述实例状态(402)包括消息标识符以及发送端口标识符；以及

其中所述消息引擎组件(102)与第一计算机相关联并且将所述消息存储在与所述第二计算机相关联的数据存储(108)中。

Images