用于对用于在应用处理的传入消息定序的计算机系统、计算机实施的方法和计算机程序产品

摘要

本发明的各实施例涉及用于对用于在应用处理的传入消息定序的计算机系统、计算机实施的方法和计算机程序产品。在一个方面中，本申请涉及一种用于在应用的处理的计算机系统、计算机实施的方法和计算机程序产品。计算机系统可以包括：应用，可操作用于处理传入消息，其中传入消息中的至少两个传入消息相关，其中相关的消息需要按照所需顺序在应用处理；以及用应用实施的定序框架，用于截获传入消息并且包括内部缓冲器，内部缓冲器用于标识相关的消息并且按照所需顺序将相关的消息缓冲为消息组，其中定序框架通过按照所需顺序从内部缓冲器向应用传送传入消息以用于处理来与应用交互。

说明书

技术领域

本说明书总体上涉及面向服务的架构(SOA)应用，特别是在 SOA应用之间的消息交换，并且特别地涉及一种用于对将在应用处 理的传入消息定序和/或重新排序的系统、计算机实施的方法和计算 机程序产品。

背景技术

许多软件应用(下文也被称为应用)(比如基于SOA的应用) 需要按照从源系统(例如，客户端、另一远程软件应用)通过网络 向应用发送电子消息(下文也称为消息)的顺序处理它们。可以应 用面向服务的架构(SOA)的原理来实施这样的软件应用。

基本上，目前，一种用于确保按照所需顺序处理在应用接收的 消息的方式是在接收应用具有用于一次处理一个消息的单个线程或 者进程。在并行处理的情况下，可能此时不再确保跨越应用的并行 处理线程和/或进程的消息(重新)排序和/或定序。

因此，需要维持在软件应用接收的用于处理的消息的排序而未 在仅能在给定的时间处理一个消息的软件应用中造成瓶颈。

当前已经开发了试着解决这一问题的计算机系统。然而，可用 系统具有关于能力(例如，允许定序但不支持重新排序)、协议(例 如，不支持可用电子消息通信协议)和/或便携性(例如，需要具体 产品以用于安装)的限制。

因此，需要提供用于解决以上问题以实现传入消息的定序和/或 重新排序以维持消息在被并行处理时的排序而未在仅能在给定的时 间处理一个消息的软件应用中造成瓶颈，也没有关于能力、协议和/ 或便携性的限制。

发明内容

根据一个通用方面，提供一种用于对用于在应用处理的传入消 息定序的计算机系统。该计算机系统可以包括：

应用，可操作用于处理传入消息，其中传入消息中的至少两个 传入消息相关，其中相关的消息需要按照所需顺序在应用处理；以 及

用应用实施的定序框架，用于截获传入消息并且包括内部缓冲 器，内部缓冲器用于标识相关的消息并且按照所需顺序将相关的消 息缓冲为消息组(也被称为消息的组)，

其中定序框架通过按照所需顺序从内部缓冲器向应用传送传入 消息以用于处理来与应用交互。

根据一个通用方面，提供一种用于对用于在应用处理的传入消 息定序的计算机实施的方法。该方法可以包括：

接收用于在应用处理的传入消息，其中传入消息中的至少两个 传入消息相关，其中相关的消息需要按照所需顺序在应用处理；

在用应用实施的定序框架截获传入消息，定序框架包括内部缓 冲器，内部缓冲器用于标识相关的消息并且按照所需顺序将相关的 消息缓冲为消息组(也被称为消息的组)；以及

按照所需顺序从定序框架的内部缓冲器向应用传送传入消息以 用于处理。

传入消息涉及接收应用提供的一个或者多个服务。

消息组可以由相关的消息属于的服务和/或服务组定义。因此， 相关并且因此在相同消息组中的消息涉及相同服务/或相同服务组 (也被称为服务的组)。定序框架定义当在应用被处理时需要排序 的消息的组，其中组中的消息本身可以与属于一个或者多个不同消 息的组的其他消息并行被处理。在一组中的消息被视为需要按照具 体(或者所需)顺序在应用处理的相关的消息。

可以将缓冲器实施为包括一个或者多个数据库表的数据库(例 如，关系数据库)。在数据库表中，表的每列定义向表中的条目指 定的参数，并且行指定表中的如下条目，该条目具有用于指定的参 数中的每个参数的值。所述值也被称为参数值。

用定序框架实施应用，可以避免用于定义消息的组的在技术上 相当复杂、昂贵和/或精细的实现方式，这些消息的组需要定序和/ 或(重新)排序。可以实现相当容易和高效地指定和/或定义消息的 组，这些消息的组需要排序处理所述组中的消息而允许属于另一组 的不同消息由在应用的两个或者更多不同线程并行处理。

根据一个方面，可以将定序框架实施为具有内部缓冲器的基于 数据库的应用，内部缓冲器包括至少一个配置表和至少一个实例表。

根据另一方面，配置表可以存储关于应用支持的一个或者多个 服务的预定义配置，其中每个服务与服务ID关联并且与一个或者多 个有关配置参数一起被存储于配置表中。

根据又一方面，相关消息中的每个相关消息可以与包括消息状 态、服务ID和/或内部序列ID的定序参数一起被存储于实例表的行 中。

消息可以是包括消息头部和/或消息主体的SOAP消息和/或 HTTP请求。消息头部和/或消息主体可以包括涉及定序参数的参数。 例如，消息可以包括消息属于的服务的服务名称和/或服务ID。消息 也可以包括创建日期和/或时间和/或发送日期和/或时间(也一起被 称为事件数据)。也可以在消息中包括和/或根据与消息一起取回的 参数值和/或从如在配置表中定义的、消息属于的服务的服务配置取 回的参数值生成内部序列ID。因而，内部序列ID可以由定序框架和 /或由已经生成消息并且与定序框架交互的源系统生成。

优选地，内部序列ID是在给定的时间点在实例表中存储的每个 消息特有的。优选地，服务ID是每个服务和/或每个服务组特有的。 消息状态指定消息的关于它在应用的处理的处理状态。消息具有以 下关联消息状态之一：新、正在运行、未决、丢弃、完成。

根据另一方面，相同消息组的相关的消息可以具有相同服务ID。

根据另一方面，内部序列ID可以定义传入消息相对于实例表中 的其他相关的消息的处理顺序。

根据另一方面，可以通过级联用于传入消息的一个或者多个配 置参数值来生成内部序列ID，配置参数值是基于传入消息的关联服 务ID从配置表取回的。

内部序列ID优选地是定序框架生成的保证消息的正确序列的长 数。内部序列ID保证即使按照不同顺序接收消息，消息仍然将如它 们用于传入消息的下层(处理)配置而应当的那样被排序。可以通 过执行以下步骤中的一个或者多个或者所有步骤来生成内部序列 ID：

-对于每个接收(输入)的消息，取得配置(取回消息字段 及其必须用于定序的顺序)；

-对配置字段重复并且对于每个配置字段取得消息的值并且 将消息值变换成对应长数；以及

-通过级联所有长数来生成内部序列ID。

通过生成如描述的序列ID，有利地无需维持数据库序列和/或配 置以生成内部序列ID。可以使用从消息取回的现有值和如在配置表 中向服务ID存储的对应服务组来容易和高效地生成序列ID。因此， 可以自动化消息定序。无需在序列的中间对消息重新排序以及移位 其余消息的序列ID。在向服务组的配置添加新参数的情况下，添加 的参数既未影响生成序列ID也未影响现有序列ID。

根据另一方面，可以用作为面向服务的架构(SOA)的应用实 施定序框架(SOA)。

在另一通用方面中，提供一种包括计算机可读指令的计算机程 序产品，这些计算机可读指令当在计算机系统中被加载和运行时使 计算机系统执行如描述的方法。

可以将在本说明书中描述的主题内容实施为一种方法或者为一 种系统或者使用在信息载体(比如CD-ROM、DVD-ROM、半导体存 储器、信号和/或数据流和硬盘)中有形地体现的计算机程序产品来 实施该主题内容。这样的计算机程序产品可以使数据处理装置进行 在本说明书中描述的一个或者多个操作。

此外，也可以将在本说明书中描述的主题内容实施为一种包括 处理器和耦合到处理器的存储器的系统。存储器可以编码使处理器 执行在本说明书中描述的方法动作中的一个或者多个方法动作的一 个或者多个程序。另外，可以使用各种MRI机器来实施在本说明书 中描述的主题内容。

在示例性附图和以下示例性描述中阐述一个或者多个实现方式 的细节。其他特征将从描述和附图中以及从权利要求中清楚。

附图说明

图1示出在应用接收的用于处理的示例性消息。

图2示出定序框架在被实施为SOA(面向服务的架构)的软件 应用中的示例性实现方式。

图3示出在使用定序框架的应用的示例性消息处理。

图4示出用于实施定序框架的示例性数据模型。

图5A、图5B和图5C示出在定序框架中实施的对消息定序和/ 或重新排序的示例性消息流程。

图6示出用于在定序框架中实施的定序过程的示例性消息状态 流程图。

图7示出用于实施如在图1至图6中所示的计算机网络、计算 机系统和计算机实施的方法的示例性计算机系统和/或计算机网络系 统。

具体实施方式

在下文中，将参照附图给出示例的具体描述。应当理解，可以 进行对示例的各种修改。特别地，一个示例的要素可以在其他示例 中被组合和使用以形成新示例。

图1示出可以向软件应用(下文也被称为应用)发送以用于处 理的示例性消息10、20、30。可以在源系统(例如，客户端应用、 另一服务应用、服务器程序等)生成消息10、20、30。消息10、20、 30涉及请求的来自应用的一个或者多个服务，该应用相应地处理消 息10、20、30。向应用发送以用于处理的消息10、20、30也被称为 传入消息10、20、30。所述应用相应地也被称为接收应用。

可以在电子可读和可处理数据格式(比如如图1中示例性地所 示的基于XML的数据格式)中指定消息10、20、30。例如，消息 10、20、30可以是从消息接发队列(比如基于XML的JMS队列(Java 消息服务)和/或基于SOAP的JMS队列)取回的HTTP请求、SOAP 消息和/或基于XML的消息10、20、30。

例如，接收应用处理传入消息10、20、30。假设应用需要按照 通过网络(例如，因特网)向应用发送接收的消息10、20、30的顺 序处理它们。

例如，应用接收必须按照(第一)消息10在(第二)消息20 之前并且(第二)消息20在(第三)消息30之前的顺序处理的如 在图1中所示的三个消息10、20、30。应用可以多线程。多线程是 指包括多于一个线程(也被称为进程)的应用的功能，该线程可操 作用于并行处理传入消息10、20、30。例如，应用包括可操作用于 并行处理接收的消息10、20、30中的至少两个消息的至少两个线程。 在示例性场景中，线程中的第一线程处理第一消息10并且线程中的 第二线程处理第二消息20。第二线程可能在第一线程已经结束处理 第一消息10之前结束处理第二消息20。第二线程然后可能获得第三 消息30以用于处理并且也在第一线程已经结束处理第一消息10之 前结束处理第三消息30。在这一示例性场景中，用以下顺序处理消 息10、20、30：第二消息20、第三消息30、第一消息10。然而， 所需顺序是第一消息10、第二消息20、继而第三消息30，从而使得 在应用正确处理消息10、20、30。

处置在接收应用的消息排序和/或定序问题基于定义消息的组 (简称为消息组或者组，也被称为消息集)，这些消息的组仅需在 消息组内的排序并且通过向应用的不同线程指派不同消息的组来将 处理并行化。

应当避免用于定义消息的组的在技术上相当复杂、昂贵和/或精 细的实现方式，这些消息的组需要定序和/或(重新)排序。应当实 现相当容易和高效地指定和/或定义消息的组，这些消息的组需要排 序处理所述组中的消息而允许属于另一组的不同消息由在应用的两 个或者更多不同线程并行处理。消息涉及由接收应用提供的一个或 者多个服务。

可以通过如图2中所示的以处理传入消息的应用作为面向服务 的架构(SOA)实施定序框架100来实现以上内容。

可以在三层基于SOA的应用200内实施在图2中所示的定序框 架100，该应用200包括对接来自源系统300的入站消息(也被称为 事件)的适配器210、用于处理消息的应用逻辑220和/或对接来自 源系统300的出站消息(也被称为事件)的部件服务230。应用200 向源系统300提供服务。

源系统300可操作用于生成关于请求的来自应用200的一个或 者多个服务的消息。应用200可以通过网络(比如因特网)与源系 统300交互。定序框架100在对在应用200接收的用于处理的消息 进行定序时与应用200的服务210、220、230交互并且向一个或者 多个源系统300提供用于对将在应用200处理的传入消息进行定序 的界面。应用200的服务210、220、230可以包括用通过定序框架 100向一个或者多个目的地系统400传播客户数据的源系统300更新 客户数据服务。在第一情况下，源系统300向定序框架100发送消 息以用于处理而无需来自定序框架100和/或来自目的地系统400的 响应。在第二情况下，源系统300向定序框架100发送消息以用于 处理并且需要来自定序框架100和/或来自目的地系统400的响应。 在两种情况下，定序框架100接收第一消息并且开始处理消息。在 定序框架100为第一消息执行适配器/应用逻辑/部件服务210、220、 230步骤之时，在定序框架100从源系统300接收将不会被处理但是 实际上被设置成未决状态的第二消息和/或第三消息，因为第一消息 在运行状态中。在结束第一消息时，将第一消息设置成完成状态， 并且通过启动与定序框架100关联的适配器/应用逻辑/部件服务进程 210、220、230来触发第二消息。在结束第二消息之后，将第二消息 设置成完成状态，并且通过定序框架100和有关服务210、220、230 触发第三消息以用于处理。

定序框架100定义当在应用200被处理时需要排序的消息的组， 其中组中的消息本身可以与属于一个或者多个不同消息的组的其他 消息并行被处理。在一组中的消息被视为需要按照具体顺序处理的 相关的消息。可以在应用200的可能的不同线程处理消息。通过在 定序框架100实施内部缓冲器110(这里也被称为缓冲器)来实现定 义这样的消息的组。可以将缓冲器110实施为包括一个或者多个数 据库表的数据库。

通过与应用200关联地用缓冲器110实施定序框架100，在定序 框架100为接收应用200截获、缓冲和/或存储在应用200接收的一 个或者多个消息以用于处理，从而使得未在应用200立即处理传入 消息。相反地，在定序框架100截获并且在被向应用200传送以用 于由应用200的一个或者多个线程处理之前在定序框架100的内部 缓冲器100中缓冲和/或存储传入消息。

缓冲器110存储用于服务和/或涉及服务的消息的预定义配置。 服务由应用200支持。预定义配置包括可适用于将在应用处理的传 入消息的定序和/或重新排序规则的预定义集。在缓冲器110中存储 的配置可以由应用100的管理员和/或开发者指定和实施。

基本上，在应用200接收的传入消息由定序框架100截获并且 被存储于缓冲器110的表中。为了按照所需顺序处理接收的消息， 定序框架向应用200的适配器210和/或应用逻辑220转发接收的消 息以用于处理。例如，基于在缓冲器110中存储的配置，向接收应 用200传送下一排序的消息以用于处理。在处理消息之后，与已经 处理了消息的应用200通信的定序框架100检查是否存在等待在应 用200处理的相关的消息(在相同消息的组中)，并且如果是这种 情况，则将向应用200提供并且相应地处理它。

有利地，使用定序框架100，将在应用200处理的消息的定序和 /或重新排序变成经由与定序框架100一起实施的缓冲器110完全可 配置。框架提供严格和非严格定序特征。非严格定序基于先入先出 (FIFO)原理，框架按照在定序框架100接收消息的顺序处理消息。 严格定序基于按照指定的顺序处理接收的消息。例如，如果定序框 架100接收包括如下字段的三个相关的消息m1、m2和m3，该字段 为每个消息指定在序列中的所需位置，则框架100按照在对应消息 字段中指定的所需顺序处理消息。定序框架100可移植。可以将定 序框架100实施为基于数据库的应用并且可以使用不同计数来暴露 定序框架100。可以使用基于数据库的应用来实施定序框架100，其 中可以使用最常见语言(比如java、C、C++)来实施用于与数据库 通信的接口。定序框架100被从应用200去耦合，应用200在支持 将在应用200处理的消息的定序和/或重新排序时使用框架100。这 基本上归因于用定序框架100对应用200的基于SOA的实现。可以 基于服务标识符(ID)对具体服务和/或服务组应用定序。如果它是 组，则在该组中的所有服务应当具有相同服务ID。定序框架100支 持在SOA中支持的可用协议(例如，同步和异步的JMS、FTP、在 HTTP之上的SOAP、DB)。定序框架100支持端到端(例如，在使 用框架的两个不同应用之间)通信(比如经由消息)事务。

图3示出用于对在用定序框架100实施的应用200处理的消息 定序和/或重新排序的示例方法。

使用定序框架100对消息进行定序和/或重新排序基本上包括以 下步骤中的一个或者多个步骤。接收消息以用于在用定序框架100 实施的应用200处理。定序框架100检查是否需要相对于例如属于 请求的具体服务的一个或者多个更多消息按照具体顺序处理消息。 假设需要相对于一个或者多个其他消息的排序处理的消息涉及相同 (消息的)组。例如，涉及请求的相同服务的消息被视为在组中相 关。如果服务相关，则将服务分组成服务的组(也被称为服务组)， 并且对属于在所述服务组中的服务中的任何服务的消息进行分组。 在需要相对于其他相关的消息按照具体顺序处理传入消息的情况 下，在定序框架100在关联的缓冲器110缓冲这一消息。随后基于 如在缓冲器110中存储的关于其他相关的消息的预定义配置数据停 止和/或继续处理消息。向应用200的线程发送消息以用于处理。在 终止处理之后，相应地通知和/或通报定序框架100。定序框架100 检查缓冲器110中的需要与当前消息一起按照具体顺序处理的相关 的消息并且取回被排序为随后的消息(也被称为下一消息)并且向 应用300的进程提供下一(或者随后)消息以用于处理。

如图3中所示，用包括一个或者多个配置表112和/或一个或者 多个实例表114的缓冲器110实施定序框架100。配置表112存储关 于应用200支持的服务的预定义配置。配置例如由已经设立和实施 了应用200的开发者和/或管理员预定义。实例表114存储传入消息， 这些传入消息属于应用200支持的一个或者多个服务。例如，属于 消息组(或者消息的组)的消息一起被存储于实例表114之一中， 从而使得每个消息的组被存储于分离的实例表114中。在消息组中 的消息属于相同服务或者服务组并且具有相同服务ID。

在实例实现方式中，用于通过定序框架100对消息定序和/或重 新排序以用于在应用300处理的以下描述的系统和/或方法包括以下 步骤中的一个或者多个步骤。

在S1，定序框架100截获和/或接收传入消息10、20、30(例如， HTTP请求或者SOAP消息)以用于在应用200处理。备选地和/或 附加地，定序框架100从消息接发队列40(例如，Java消息服务(JMS) 队列(比如XML/JMS队列或者SOAP/JMS队列))读取和/或取回 一个或者多个消息10、20、30以用于在应用200处理。在标准数据 交换格式(比如SOAP和/或HTTP)中指定消息10、20、30并且这 些消息包括消息头部和/或消息主体。可以在消息头部和/或消息主体 中定义为了对消息定序而需要的数据。

在S2，定序框架100从消息10、20、30提取服务名称。服务名 称可以指定消息10、20、30属于的服务。假设服务由接收应用200 支持。定序框架100检查消息10、20、30是否需要相对于一个或者 多个其他消息被定序和/或重新排序。可以通过比较消息10、20、30 的提取的服务名称与在缓冲器110的配置表112中存储的对应配置 数据来执行检查。例如，通过用从消息10、20、30提取的服务名称 访问配置表112来检查消息10、20、30属于的服务和/或服务的组是 否用属于相同服务和/或相同服务组的相关的消息10、20、30的所需 处理顺序来定义。

如果在S2确定消息10、20、30需要与一个或者多个相关的消 息10、20、30一起的定序和/或排序处理，从而使得需要在消息的组 中与相关(或者有关)的消息10、20、30一起对消息10、20、30 进行排序，则定序框架100在实例表114中与相关的消息10、20、 30一起存储消息10、20、30，S3。在实例表114中一起存储的消息 的组可以与用于所述消息的组的执行计划关联地被存储。执行计划 可以存储于相关的消息的对应实例表114内和/或与具体消息的组的 相应实例表114链接的配置表112中。例如，相关的消息10、20、 30可以与每个消息10、20、30的相应执行状态一起按照所述组所需 要的执行计划的顺序被存储，其中需要在更低排序的消息(例如， 在表114的第二或者随后行)可以运行之前完成更高排序的消息10、 20、30(例如，在表114的第一行中)。执行计划可以是关于相关 的消息10、20、30属于的服务和/或服务的组的预定义配置并且对于 每组从配置表112可取回。执行计划定义在需要按照具体顺序在应 用200处理的消息的组中的相关的消息10、20、30的顺序和/或序列。

在S4，在选择下一排序的消息10、20、30以用于在应用处理之 后，激发应用200的适配器服务210。如果所述当前消息10、20、 30可以由应用200的线程处理，则适配器服务起动应用220的应用 逻辑220以用于处理。在消息10、20、30被拒绝的情况下，更新实 例表114以阻止在将按照特定顺序处理的相同消息的组中的相关的 消息10、20、30。例如，将在这一组的实例表114中的所有相关消 息10、20、30设置为未决。如果需要按照具体顺序处理消息10、20 和30，则在消息10正在运行时，消息20和30将未决等待消息10 结束(或者完成)，从而使得消息20、30被阻止。

在S5，如果应用200的应用逻辑220已经成功执行了消息10、 20、30，则相应地通报定序框架100。

在S6，定序框架100在正被处理的消息10、20、30属于的组的 实例表114中更新组的状态。例如，处理的消息10、20、30在消息 10、20、30属于的组的实例表114中的的状态被设置成完成。

定序框架100从在相同实例表114中存储的组取回随后排序的 消息10、20、30(如果有)和/或从可以与讨论的集合并行被处理的 在不同实例表114中存储的另一消息的组取回消息10、20、30，并 且向应用200提供随后取回的消息10、20、30以用于处理，S7。

因而，定序框架100在接收的消息10、20、30执行一个或者多 个检查。检查包括在配置表112中查找取回的消息10、20、30是否 需要相对于一个或者多个相关的消息10、20、30的定序。如果消息 10、20、30属于相同服务和/或相同服务的组，则它们可以相关。可 以通过提取与消息10、20、30一起被传达的服务名称来取回关于消 息10、20、30属于的服务的信息。可以使用服务名称在定序框架100 的一个或者多个配置表112中查找涉及服务和/或服务组的定序要 求。在消息的组(也被称为消息组)中对相关的消息10、20、30排 序和/或定序。消息的组需要按照具体给定的顺序的依次处理而可以 与属于一个或者多个不同消息的组的消息10、20、30并行处理它。 属于消息的组的消息10、20、30一起被存储于定序框架100的实例 表114中。消息10、20、30中的每个消息可以与至少包括消息状态、 服务ID和/或内部序列ID(也被称为序列ID)的参数(也被称为定 序参数)一起存储于所述表114的单行中。在一个实例表114中并 且因此属于相同组的消息10、20、30可以具有相同服务ID。

如果消息10、20、30同步和/或如果对于消息10、20、30禁用 定序，则未在定序框架100的实例表114中保持、而是在应用200 立即处理消息10、20、30。

在消息10、20、30未同步和/或对于消息10、20、30启用定序 的情况下，在定序框架100的实例表114中存储消息10、20、30并 且与相关的消息一起在组中对消息10、20、30进行排序以按照具体 顺序来处理。在消息的组中的消息被视为属于具体服务或者服务组 并且因此具有相同服务ID。可以在定序框架100的配置表112中指 定并且可以从如从接收的消息10、20、30取回的服务名称和/或对应 ID取回服务ID。

除了以上描述的定序方法之外，定序框架附加地和/或备选地实 施对用于在应用200处理的消息10、20、30的严格定序。严格定序 包括仅在已经在应用200接收和处理了先前(按照所需顺序的)消 息的情况下处理消息10、20、30。消息10、20、30可以与关联序列 ID一起被存储于定序框架100的实例表114中。序列ID是顺序号并 且在实例表114中相对于在相同消息的组中(例如，具有相同服务 ID)的另一消息10、20、30对消息10、20、30排序。例如，在启 用了严格定序时，如果在用定序框架100实施的应用200未接收和 处理具有序列ID“3”的另一消息10、20、30，则不能处理具有序列 ID“4”的消息10、20、30。

可以用定序框架100实施以下方面中的一个或者多个方面。对 于消息10、20、30，可以在消息头部和/或消息主体内的具体分节中 与消息10、20、30一起传递与定序有关的数据。消息10、20、30 的所述分节可以被称为定序分节。定序分节可以包括消息10、20、 30属于的服务的服务名称、服务ID和/或消息10、20、30相对于它 在对应服务中的顺序的序列ID。定序分节可定制。例如，用户有可 能指定消息的一个或者多个字段，其中需要向定序网络100传递指 定的消息字段以正确处理对应消息。

消息10、20、30的服务ID和/或序列ID可以由发送源系统生成。 在源系统不能生成所述ID的情况下，发送消息10、20、30的源系 统应当保证发送在不同消息的时间戳之间有一致性的有关事件数 据。在多于一个源系统可操作用于发送具有相同服务ID的用于处理 的消息10、20、30的情况下，假设发送具有相同服务ID的消息的 源系统同步。不是数据的主控、而是仅对数据工作的源系统可以请 求不将序列ID用于消息10、20、30。如果需要在没有序列ID的情 况下管理定序，则假设源系统在相同时区之下操作并且具有同步的 时间。如果消息的组内具有多于一个服务(例如，具有至少两个不 同服务ID的消息)，这意味着服务间定序，则在所述消息的组中的 有关服务应当在发送的有关消息10、20、30的头部和/或主体的具体 定序分节中使用相同服务ID。仅如果源系统能够在发送的消息10、 20、30的消息头部和/或消息主体中提供序列ID才可以启用严格定 序。如果未启用严格定序，则将记下和丢弃定序框架100在更加新 的消息被处理之后接收的具有更旧的序列ID的消息10、20、30。

图4示出可用来将定序框架100实施为计算机系统的示例性对 象类规范。可以用来实施定序框架100的对象类包括一个或者多个 配置表规范112和一个或者多个实例表规范114。图4示出三个示例 性配置表规范112a、112b、112c和两个示例性实例表规范114a、114b 及其相互关系。可以在与定序框架110的缓冲器110(例如，被实施 为关系数据库)中将表规范112、114实施为数据库表。

在随后的表中，第一列指定在对应配置表和/或实例表中的条目 具有的参数。在随后的表中的第二列提供对应参数的规范的描述。 在根据以下规范实施的对应表中的条目是如以下指定的对应参数的 一行值。

SEQUENCING_SERVICE表规范112a包括应用200可用的服务 的定义。SEQUENCING_SERVICE表规范112a被实施为配置表112。 下面的表1示出可以用来实施SEQUENCING_SERVICE表规范112a 的示例性参数。

表1

SEQUENCING_CONFIG_MAIN表规范112b提供用于对在使用 定序框架100的应用200的传入消息定序的配置。 SEQUENCING_CONFIG_MAIN表规范112b可操作用于存储涉及应 用200支持的服务的数据，该数据包括服务组数据、包括启用/禁用 的服务组级别配置数据、严格定序等。 SEQUENCING_CONFIG_MAIN表规范112b被实施为配置表112。 下面的表2示出可以用来实施SEQUENCING_CONFIG_MAIN表规 范112b的示例性参数。

表2

SEQUENCING_CONFIG_PARAM表规范112c定义用来生成用 于传入消息的内部序列ID的参数。SEQUENCING_CONFIG_PARAM 表规范112c被实施为配置表112。下面的表3示出可以用来实施 SEQUENCING_CONFIG_PARAM表规范112c的示例性参数。

表3

SEQUENCING_RUNTIME_MAIN表规范114a处置消息级运行 时数据。SEQUENCING_RUNTIME_MAIN表规范114a包括用于在 用定序框架100实施的应用200接收的每个被启用定序的消息的一 行。SEQUENCING_RUNTIME_MAIN表规范114a被实施为实例表 114。下面的表4示出可以用来实施SEQUENCING_RUNTIME_MAIN 表规范114a的示例性参数。

表4

SEQUENCING_RUNTIME_PARAM表规范114b包括如下参数 的值，这些参数用来生成用于取回的消息的内部序列ID。在对应表 114中将每个参数存储为行。SEQUENCING_RUNTIME_PARAM表 规范114b被实施为实例表114。下面的表5示出可以用来实施 SEQUENCING_RUNTIME_PARAM表规范114b的示例性参数。

表5

图5A至图5C示出可以在用于(例如，在定序框架100的)用 于对用于在应用200处理的传入消息定序的计算机方法中实施的示 例性流程图。

图5A示出在定序框架100中实施的定序方法的示例性流程图。

在S10，源系统300生成将向应用200发送以用于处理的消息。 源系统300可操作用于用消息头部和/或消息主体生成消息。消息头 部和/或消息主体包括定序框架100为了相应地对消息定序而需要的 一个或者多个参数。参数(也被称为定序参数)可以包括消息属于 的服务的服务名称、服务ID、内部序列ID(也被称为序列ID)和/ 或如参照图4和对应的表1至表5指定的更多参数中的一个或者多 个参数。消息包括两个部分：消息头部，该消息头部包括关于消息 的通用信息，比如服务名称、源系统、目的地系统、一个或者多个 业务密钥、消息类型、定序信息；以及消息主体，该消息主体包括 具体数据，比如客户数据、地址信息、记账账户数据。当在用定序 框架100实施的应用200接收消息之后，对接收的消息执行普通生 效和/或重复检查，S11。如果消息未成功生效，S12，则源系统300 从应用接收异常通报，S13。否则，定序框架通过访问用定序框架100 实施的一个或者多个配置表来检查对于接收的消息是否启用了定 序，S14。如果对于接收的消息未启用定序，则定序框架100立即向 应用200的服务传递消息以用于处理，S15。

如果对于接收的消息启用了定序，则消息头部和/或消息主体的 定序参数用来通过查询定序框架100的一个或者多个配置表112来 取回消息属于的服务和/或服务组和/或用于服务组的配置数据S16。 使用为消息取回的与服务有关的参数，为消息生成内部序列ID，S17。 以下更具体地描述生成内部序列ID(也被称为序列ID)。生成的内 部序列ID与消息，S20一起被存储于定序框架100的实例表114中， S18。关于实例表114，为消息设置和/或改变对应(处理)状态，S19。 例如，如果实例表114包括具有当前完成和/或正在运行的相同服务 ID和/或服务组ID的另一消息，则将消息的状态设置成“丢弃”。然 后，从实例表114取回服务的相同组或者集的随后的消息以用于处 理，S20。以下参照5B描述取回和/或取得下一或者随后的消息，S20。

图5B示出在定序框架100中实施的取得下一消息的方法的示例 性流程图。可以用在图5A中所示的定序方法实施取得下一消息的方 法。如果在应用200成功处理了当前消息，则取得下一消息的方法 实施取回下一消息(或者随后排序的消息)以用于处理。

在S21，执行检查是否存在具有与传入消息相同的服务ID并且 因此在相同服务和/或服务组中的当前正在运行的消息(即在应用当 前被处理的消息)。如果是这种情况，则返回空响应，S22。因此， 关于所述服务ID未从实例表114取回随后的消息。在实例表114中 将消息的状态设置成“未决”，S23。如果具有与传入消息相同的服务 ID的当前正在运行的消息未存在于实例表114中，则执行检查对于 消息属于的服务和/或服务组是否启用了严格定序，S24。从配置表 112取回对应数据。

如果对于讨论的服务ID并且因此对于服务和/或服务组未启用 严格定序，则从实例表114取回实例表114中的具有相同服务ID的 在先前处理的消息之后的未决的下一或者随后的消息，S25。如果没 有这样的下一消息存在，则不返回消息，S26。否则，从实例表114 取回下一消息，S27，并且将它的状态设置成“2在运行”，S28。

如果对于当前处理的消息的讨论的服务ID并且因此对于服务和 /或服务组启用了严格排序，则执行检查是否有传入消息并且传入消 息是否按照关于具有相同服务ID的消息的当前处理状态而言的所需 顺序，S29。对于这一检查，从实例表114为所述服务ID取回传入 消息的对应序列ID。如果传入消息按照正确顺序，则返回当前传入 消息，S30，并且将它的状态设置成“正在运行”，S31。否则，通过 访问实例表114来取回具有相同服务ID的下一或者随后的可用消 息，S32。相应地执行以上步骤S25、S26、S27和/或S28。

图5C示出在定序框架100中实施的响应方法的示例流程图。可 以用参照图5A和图5B描述的方法实施响应方法。在S33，已经生 成了用于在应用200处理的消息的源系统300接收关于处理消息的 响应。在应用200向定序框架100传达响应以用于更新处理的消息 的状态，S34。将状态相应地设置成“完成”，S35。随后取回下一和/ 或随后消息，S20。参照图5B描述取回下一消息。

对于在使用定序框架的应用处理的每个消息，为消息生成内部 序列ID。内部序列ID可以保证消息相对于在相同服务和/或服务组 中的一个或者多个其他消息(即对于具有相同服务ID的消息)而言 的正确序列。序列ID可以保证消息即使在应用按照不同顺序接收它 们，仍然将如它们根据对应服务的配置而应当的那样被排序。根据 参照图4描述的配置表规范用对应应用的实现方式预定义对应服务 的配置。

可以为接收的消息生成序列ID。从与消息一起取回的服务的名 称标识并且在服务ID方面指定消息属于的服务和/或服务组。假设具 有相同服务ID的消息按照具体顺序被处理并且一起被存储于实例表 中而参照图4描述实例表规范的参数。从对应配置表取回为服务ID 定义的对应配置参数。从根据消息具体值创建的运行时参数标识用 于组的所有参数值。

例如，假设用于更新客户数据服务的以下配置。

配置参数表：

定序框架100接收以下消息M1、M2和M3：

在消息m1、m2、m3中的每个消息的<sequencing info>... </sequencing info>分节中指定用于在定序框架100处理消息m1、m2、 m3的定序数据。当在定序框架100接收和处理消息m1、m2、m3 时，将在运行时间参数表中插入以下记录。

并且将在sequencing_runtime_main表中具有以下记录：

在红色sequence_id参数中和在蓝色event_date参数中。 internal_sequence_ID是按照在sequencing_config_param表中配置的 参数序列的级联。

将向服务ID的取回的配置参数值转换成用于序列ID字段的类 型“long”值以在实例表中作为参数值向接收的消息的条目存储。基于 在参数配置中的“参数序列”级联转换的值以创建新“long”值以用作 为用于取回的消息的序列ID。可以在表sequencing_config_param中 指定参数序列，并且参数序列可以定义将按照的参数的级联顺序以 便生成用于有关的消息的组的内部序列ID。在以上给出的示例中， 对于在配置参数表中的sequence_id参数序列1和对于event_date参 数序列2，在为所述消息生成内部序列ID时，级联是 <sequence_id><event_date>。

通过如以上描述的那样生成序列ID，有利地无需维持数据库序 列和/或配置以生成内部序列ID。可以使用从消息取回的现有值和如 在配置表中向服务ID存储的对应服务组来容易和高效地生成序列 ID。因此，可以自动化消息定序。无需在序列的中间对消息重新排 序以及移位其余消息的序列ID。在向服务组的配置添加新参数的情 况下，添加的参数既未影响生成序列ID也未影响现有序列ID。这可 以归因于如下事实，该事实为向配置添加新添加的参数作为最后参 数，例如，在图4中所示的SEQUENCING_C0NFIG_PARAM表规 范112c中的最大PARAM_SEQUENCE值。

在启用了严格定序时，用于服务组的配置应当具有从已经生成 了对应消息的源系统接收的仅一个参数，该参数是在图4中所示的 SEQUENCING_RUNTIME_MAIN表规范114a中的 INTERNAL_SEQUENCE_ID参数。这实现以高效方式生成在图4中 所示的SEQUENCING_RUNTIME_MAIN表规范114a中的最大 INTERNAL_SEQUENCE_ID参数，由此避免附力查询 SEQUENCING_RUNTIME_PARAM表规范114b以维持实例表114 中的另一最大INTERNAL_SEQUENCE_ID列并且在将消息的状态更 新成“完成”时为具有相同服务ID的所有消息更新所述表114。

虽然定序框架100可以处理对于从不能生成序列ID的源系统接 收的消息的定序，但是由于性能方面而优选用可操作用于为生成的 消息生成序列ID的源系统实施定序框架100。在源系统未与消息一 起生成序列ID的情况下，然后为了保证使用严格定序来处理序列， 对应应用要求使用单个线程以从用于消息属于的对应服务的实例表 读取。这可能在传入消息的数目显著增加时引起性能问题。如果应 用使用多个线程，则可能由于在消费序列中的先前消息的线程中的 可能延时而有丢弃的消息。

参照随后的表，给出了用于为传入消息生成序列ID的两个示例。

以下示例涉及源系统可操作用于为每个生成的消息生成序列ID 的情况。

以下是用于具体服务组的图4中所示的SEQUENCING_ CONFIG_PARAM表规范112c的实现方式的概况。

以下是用于这一示例的SEQUENCING_RUNTIME_PARAM表 规范114b的实现方式的概况。

对于这一示例，SEQUENCING_RUNTIME_MAIN表规范114a 的实现方式的部分将如下。

在这一场景中，将被处理的消息将是具有更低内部序列ID的消 息，该内部序列ID是“22011021410111644441”，这是表中的末行， 即使它的日期比其他日期更晚。

以下示例涉及源系统不可操作用于为每个生成的消息生成序 列ID的情况。

以下是用于具体服务组的SEQUENCING_CONFIG_PARAM表 规范112c的实现方式的概况。

以下是用于这一示例的SEQUENCING_RUNTIME_PARAM表 规范114b的实现方式的概况。

对于这一示例，SEQUENCING_RUNTIME_MAIN表规范114a 的实现方式的部分将如下。

在这一场景中，将被处理的第一消息将是具有如下内部序列 ID的消息，该内部序列ID是“2011021422222244441”，因为它在 结束具有“1”，即使消息具有相同事件日期。

图6示出可以在用定序框架100实施的定序方法期间将消息指 派成的可能状态11、12、13、14、15。可以将消息指派成以下状态 11、12、13、14、15之一：“新”11、“正在运行”12、“未决”13、“丢 弃”14、“完成”15。图示了用于定序方法中的消息的状态流程。下面 的表6列举和指定所示的消息状态11、12、13、14、15。

表6

图7示出用于实施本发明的示例性系统，该系统包括形式为常 规计算环境920的通用计算设备(例如，个人计算机)。常规计算 环境包括处理单元922、系统存储器924和系统总线926。系统总线 将包括系统存储器924的各种系统部件耦合到处理单元922。处理单 元922可以通过访问系统存储器924来执行算术、逻辑和/或控制操 作。系统存储器924可以存储用于与处理单元922组合使用的信息 和/或指令。系统存储器924可以包括易失性和非易失性存储器，比 如随机存取存储器(RAM)928和只读存储器(ROM)930。可以在 ROM930中存储包含基本例程的基本输入/输出系统(BIOS)，这些 基本例程有助于比如在启动期间在个人计算机920内的单元之间传 送信息。系统总线926可以是若干类型的总线结构中的任何类型的 总线结构，这些类型的总线结构包括存储器总线或者存储器控制器、 外围总线和使用多种总线架构中的任何总线架构的本地总线。

个人计算机920还可以包括用于从硬盘(未示出)读取和向硬 盘写入的硬盘驱动932以及用于从可拆卸盘936读取或者向可拆卸 盘写入的外部盘驱动934。可拆卸盘可以是用于磁盘驱动器的磁盘或 者用于光盘驱动的光盘，比如CD ROM。硬盘驱动932和外部盘驱 动934分别由硬盘驱动接口938和外部盘驱动接口940连接到系统 总线926。驱动及其关联计算机可读介质提供用于个人计算机920 的计算机可读指令、数据结构、程序模块和其他数据的非易失性存 储。数据结构可以包括用于实施如以上描述的用于对将在应用处理 的传入消息定序的方法的相关数据。可以在数据库(例如，关系数 据库管理系统或者面向对象的数据库管理系统)中组织相关数据。

虽然这里描述的示例性环境运用硬盘(未示出)和外部盘936， 但是本领域技术人员应当理解也可以在示例性操作环境中使用可以 存储计算机可访问的数据的其他类型的计算机可读介质，比如磁盒、 闪存卡、数字视频盘、随机存取存储器、只读存储器等。

可以在硬盘、外部盘936、ROM930或者RAM928上存储多 个程序模块，包括操作系统(未示出)、一个或者多个应用程序944、 其他程序模块(未示出)和程序数据946。应用程序可以包括如图1 至图6中所描绘功能的至少一部分。

用户可以通过输入设备(比如键盘948和鼠标950)向个人计 算机920中如以下讨论的那样录入命令和信息。其他输入设备(未 示出)可以包括麦克风(或者其他传感器)、操纵杆、游戏板、扫 描仪等。这些和其他输入设备可以通过耦合到系统总线926的串行 端口接口952连接到处理单元922或者可以由其他接口(比如并行 端口接口954、游戏端口或者串行总线端口(USB))收集。另外， 可以使用打印机956来打印信息。打印机956和/或其他并行输入/ 输出设备可以通过并行端口接口954连接到处理单元922。监视器 958或者其他类型的显示设备也经由接口(比如视频输入/输出960) 连接到系统总线926。除了监视之外，计算环境920还可以包括其他 外围输出设备(未示出)，比如扬声器或者其他可听输出。

计算环境920可以与其他电子设备(比如计算机、电话(有线 或者无线)、个人数字助理、电视等)通信。为了通信，计算机环 境920可以使用与一个或者多个电子设备的连接在联网环境中操作。 图7描绘与远程计算机962联网的计算机环境。远程计算机962可 以是另一计算环境(比如服务器、路由器、网络PC、对等设备或者 其他常见网络节点)并且可以包括以上相对于计算环境920描述的 单元中的许多或者所有单元。图7中描绘的逻辑连接包括局域网 (LAN)964和广域网(WAN)966。这样的联网环境在办公室、企 业范围计算机网络、内部网和因特网中司空见惯并且特别地可以被 加密。

当在LAN联网环境中使用时，计算环境920可以通过网络I/O 968连接到LAN 964。当在WAN联网环境中使用时，计算环境920 可以包括调制解调器970或者用于通过WAN 966建立通信的其他装 置。可以在计算环境920内部或者外部的调制解调器970经由串行 端口接口952连接到系统总线926。在联网环境中，可以在驻留于远 程计算机962上或者可由远程计算机962访问的远程存储器存储设 备中存储相对于计算环境920描绘的程序模块或者其部分。另外， 与(以上描述的)用于优化策略的评估的方法相关的其他数据可以 在远程计算机962上驻留或者经由远程计算机962可访问。将领会 到，所示网络连接为示例性的并且可以使用建立在电子设备之间的 通信链路的其他手段。

以上描述的计算系统仅为可以用来实施用于对用于在应用处 理的传入消息定序的方法的计算系统的类型的一个示例。

标号

10，20，30    消息

11    消息状态“新”

12    消息状态“正在运行”

13    消息状态“未决”

14    消息状态“丢弃”

15    消息状态“完成”

40     消息队列

100    定序框架

110    缓冲器(例如，数据库)

112    配置表

112a，112b，112c    配置表规范

114    实例表

114a，114b    实例表规范

200    应用

210    适配器

220    应用逻辑

230    部件服务

300    源系统

400    目的地系统

S1-S35 定序步骤

920    常规计算环境

922    处理单元

924    系统存储器

926    系统总线

928    随机存取存储器(RAM)

930    只读存储器(ROM)

932    硬盘驱动

934    外部盘驱动

936    可拆卸盘

938    硬盘驱动接口

940    外部盘驱动接口

944    一个或者多个应用程序

946    程序数据

948    键盘

950    鼠标

952    串行端口接口

954    并行端口接口

956    打印机

958    监视器

960    视频输入/输出

962    远程计算机

964    局域网(LAN)

966    广域网(WAN)

968    网络I/O

970    调制解调器