消息传送模型和架构.pdf

提供了一种用于促进可扩展消息传送和交互的系统、架构和模型。所述消息系统可以使用包括域消息模型、开放消息模型以及线格式的消息传送架构。所述线格式可以实现原始数据类型，所述开放消息模型可以使用所述原始数据类型来定义其他和/或更复杂的数据格式。所述开放消息模型还可以指定交互范例、通用消息以及消息和传输属性。所述通用消息可以包括可以使用所述域消息模型来定义其含义和上下文的有效负荷数据。所述域消息模型可以包括内容定义模型和项目类型模型，以便构建数据和对象类型以及指定数据上下文和关系。这样，所述消息系统可以使用通用消息和格式来创建不同的消息和项目类型。

1.  一种用于促进客户与提供方之间的交互的计算机实现的数据模型，所述数据模型包括：
传输层，其定义用于对所述客户与所述提供方之间的交互进行分类的一个或多个交互范例，以及定义一个或多个通用消息类型；以及
数据层，其定义一个或多个通用数据格式，其中所述一个或多个通用消息类型包括根据所述一个或多个通用数据格式中的至少一个通用数据格式来格式化的有效负荷数据，其中所述一个或多个通用消息类型用于生成所述客户与所述提供方之间的消息而与关联于所述消息的上下文无关。

2.  根据权利要求1的计算机实现的数据模型，其中所述一个或多个交互范例包括请求/响应范例、带有兴趣的请求/响应范例以及列表/发送范例中的至少一个。

3.  根据权利要求1的计算机实现的数据模型，其中所述一个或多个通用消息类型包括请求消息、刷新消息、更新消息、状况消息、关闭消息以及确认消息中的至少一个。

4.  根据权利要求1的计算机实现的数据模型，其中所述一个或多个通用消息类型包括一个或多个基本属性。

5.  根据权利要求4的计算机实现的数据模型，其中所述一个或多个基本属性包括项目类型、流标识符以及扩展报头中的至少一个。

6.  根据权利要求1的计算机实现的数据模型，其中基于域消息模型来定义与所述消息关联的所述上下文，所述域消息模型包括项目类型模型和内容定义模型。

7.  根据权利要求6的计算机实现的数据模型，其中所述项目类型模型对应于市场价格模型。

8.  根据权利要求1的计算机实现的数据模型，其中在保持所述通用消息类型的时，通过改变与所述消息关联的域消息模型来改变与所述消息关联的所述上下文。

9.  根据权利要求1的计算机实现的数据模型，其中所述传输层还定义了一个或多个传输属性，所述传输属性包括服务标识符、名称以及名称类型中的至少一个。

10.  一种用于与提供方进行交互的方法，所述方法包括：
确定与期望的交互对应的交互范例；
向所述提供方发送请求消息，其中所述请求消息指示所述交互范例，并且其中根据通过开放消息模型定义的通用请求消息类型来生成所述请求消息；
接收来自所述提供方的刷新消息，其中所述刷新消息包括根据通过所述开放消息模型指定的通用数据格式来格式化的有效负荷数据；以及
根据通过域消息模型定义的上下文来处理所述有效负荷数据，其中所述域消息模型独立于所述开放消息模型。

11.  根据权利要求10的方法，其中响应于确定所述交互范例是带有兴趣的请求/响应交互：
定义事件流；以及
接收所述事件流中的一个或多个更新消息。

12.  根据权利要求10的方法，其中所述通用数据格式包括元素列表、字段列表、向量、映射、级数以及过滤器列表中的至少一个。

13.  根据权利要求11的方法，还包括步骤：
如果所述通用数据格式包括字段列表，则标识与所述刷新消息关联的数据字典；以及
基于所述数据字典解释所述有效负荷的至少一部分。

14.  根据权利要求10的方法，还包括步骤：根据所述刷新消息中指定的总计数提示来分配高速缓冲存储器。

15.  根据权利要求10的方法，还包括步骤：
如果所述域消息模型被改变为第二域消息模型，则根据第二上下文处理所述有效负荷数据，其中通过所述第二域消息模型来定义所述第二上下文。

16.  一种用于促进客户与提供方之间的交互的系统，所述系统包括：
第一客户和第二客户；
消息模型，其包括数据层和传输层，其中所述数据层定义数据格式并且其中所述传输层定义通用消息类型，所述通用消息类型包括根据所述数据格式来格式化的有效负荷数据；以及
第一域模型和第二域模型，
其中通过所述第一客户基于通过所述第一域模型指定的第一上下文来处理根据所述通用消息类型格式化的第一消息；以及
其中通过所述第二客户基于通过所述第二域模型指定的第二上下文来处理根据所述通用消息类型格式化的第二消息，所述第一上下文不同于所述第二上下文。

17.  根据权利要求16的系统，其中所述第一域模型包括项目类型模型和内容定义模型。

18.  根据权利要求17的系统，其中所述内容定义模型指定一个或多个用于解释所述有效负荷数据的至少一部分的数据字典。

19.  根据权利要求16的系统，其中所述传输层还定义与所述通用消息类型关联的一个或多个基本属性，其中所述一个或多个基本属性包括项目类型、流标识符以及扩展报头中的至少一个。

20.  根据权利要求16的系统，其中所述传输层还定义一个或多个传输属性，所述传输属性包括关键字、状况、服务质量以及组标识符中的至少一个。

消息传送模型和架构
技术领域
本发明一般地涉及一种消息传送架构、模型和关联的操作者。更具体地说，本发明涉及一种数据消息传送模型，其定义可重用的传输和数据抽象以便促进各种类型和形式的内容的定义、结构化、访问以及生成。
背景技术
消息传送的速度和便利性使得产生了多种消息传送和传输协议以便支持不同类型的数据和消息传送。消息传送和传输协议用于定义标准，通过所述标准对内容进行传送和处理。例如，由金融公司和机构使用的消息协议可以定义特定的数据结构，用于股票价格和市场数据的有效的存储和表示。在另一个实例中，传输协议可以将交互分类为一个或更多预定义的类别，从而使接收设备和发送设备之间的通信标准化。同样，从各种源接收数据的应用和其他程序必须被特别地配置，以处理和理解根据特定的消息传送协议来格式化的数据传输。可以想象，应用可能需要拥有若干功能和/或程序，使得应用可以处理来自多个源的通信和数据，其中每个源使用不同的传输和/或消息传送协议。
此外，在许多情况下，所请求的数据和/或内容可能不会容易地(或根本不会)转化或转换成由消息传送或传输协议指定的格式。因此，可能从消息传输中排除数据和/或内容的某些部分，使得传输符合消息传送和/或传输规范。具体地说，某些传输协议可能只接受内容的特定的类型和/或格式。例如，在金融事务处理系统中，消息传送协议可能仅为消息结构定义两个字段，股票符号和股票价格。因此，消费者公司和/或用户可能不能在使用此类消息传送协议的消息中还传送事务处理量数据。
出于上述原因，需要一种用于处理各种数据类型和格式的可扩展的消息传送模型。
发明内容
通过使用域消息模型提供一种可扩展和灵活的消息传送架构和模型，来解决许多前述问题。域消息模型可以利用基础消息传送架构和模型的能力而无需对它们带来更改。所述消息传送架构和模型可以包括传输层，所述传输层用于定义使得域消息模型能够指定传输以及消息传送语法和语义的构造，而数据层可用于定义通用的数据格式，例如元素(element)列表、字段列表、向量、映射、过滤器列表以及级数(series)。可以使用一组原始数据类型或由线格式实现的构建块来构造所述通用的数据格式。所述通用的数据格式还可用于创建额外的数据格式和/或类型，例如通过组合消息中的各种数据格式。另一方面，传输层可以提供允许域消息模型进一步指定可应用上下文的消息传送和传输构造。因此，可以通过修改和/或替换所述域消息模型而不更改由传输和数据层定义的构造，来更改与消息和传输构造关联的上下文。上下文可以指定应用将如何处理数据和/或数据代表何种内容。
在一个或多个布置中，所述传输层还可以将所有交互分类成一组预定义的交互范例，例如请求/响应、带有兴趣的请求/响应以及收听/发送。请求/响应交互指客户请求快照数据的交互。然而，带有兴趣的请求/响应交互可以涉及对可随时间变化的数据或能力的请求。收听/发送交互对应于客户在不知道提供者的情况下收听发布数据的交互。
另一方面，所述传输层可以定义一个或更多通用消息类型以及所述消息类型中的属性，以支持各种交互范例。例如，所述通用消息类型可以包括请求消息、刷新消息、更新消息、状况消息、关闭消息和/或确认消息。每个所述通用消息或消息类型还可以由一个或更多包括类型、流标识符以及扩展报头的基本属性来表征。类型信息可用于指定所述消息中表示的项目类型模型。另一方面，流标识符可用作对于事件流(即，带有兴趣的请求/响应交互)的标识属性，而扩展报头可用于处理可能不适合通用属性的消息属性。通用消息或消息类型还可以包含附加的属性和元素，例如关键字属性、状态属性、服务质量属性和/或组标识符属性。
再根据另一方面，可以将域消息模型包括在所述消息传送架构中，以定义对象类型、传输行为、数据表示、含义以及关系。例如，所述域消息模型可以包括两个层：项目类型模型层和内容定义模型层。可以根据可传送传输行为、消息传送语法以及消息传送语义的项目类型模型，来构建和/或构造消息以及其中传输的有效负荷数据。例如，项目类型模型可确定用于表示有效负荷数据的数据格式。还可以基于所述项目类型模型而请求和/或定义一个或更多属性。另一方面，内容定义模型可以向数据字段和数据本身提供含义，而不必修改和/或更改基础开放消息模型(即，传输层和数据层)。例如，内容定义模型可以标识一个或更多可用于解释数据的数据字典。内容定义模型还可以包括枚举信息和/或必需的/可选的字段定义。
从本发明的以下详细说明、所附权利要求以及附图，本发明的这些以及其他优点和方面将是显而易见和可以理解的。
附图说明
通过实例的方式示出了本发明，并且本发明并不限于附图，在附图中，相同的参考标号表示相同的元素，其中：
图1示例性示出其中可以实现在此描述的一个或更多方面的计算环境的框图；
图2示例性示出其中可以实现在此描述的一个或更多方面的消息传送系统和基础结构图；
图3是示例性示出根据在此描述的方面的多个客户应用通过不同的接入点与服务提供方交互的网络图；
图4示例性示出根据在此描述的一个或更多方面的包括多个用于定义消息的建模层的消息传送架构；
图5示例性示出根据在此描述的一个或更多方面的与一个或更多通用消息类型关联的基本属性；
图6A-6C示例性示出根据在此描述的一个或更多方面与消息和交互关联的传输属性；
图7A-7F示例性示出根据在此描述的一个或更多方面的多个通用消息类型模型；
图8示例性示出根据在此描述的一个或更多方面的两种形式的记录编码；
图9示例性示出根据在此描述的一个或更多方面的被使用记录集编码来编码的数据；
图10示例性示出根据在此描述的一个或更多方面的元素列表数据格式；
图11示例性示出根据在此描述的一个或更多方面的字段列表数据格式；
图12示例性示出根据在此描述的一个或更多方面的向量数据格式；
图13示例性示出根据在此描述的一个或更多方面的映射数据格式；
图14示例性示出根据在此描述的一个或更多方面的级数数据格式；
图15示例性示出根据在此描述的一个或更多方面的过滤器条目数据格式；
图16A-16D示例性示出根据在此描述的一个或更多方面的登录项目类型模型的组件和使用；
图17A-17D示例性示出根据在此描述的一个或更多方面的市场价格项目类型模型的组件和使用；以及
图18是示例性示出根据在此描述的一个或更多方面的用于与服务提供方交互的方法的流程图。
具体实施方式
在以下对各个实施例的说明中，参考了形成本说明书一部分的附图，并且其中通过示例的方式示出了其中可以实现本发明的各个示例性实施例。应当理解，可以采用其他实施例并且可以做出结构和功能修改而不脱离本发明的范围。
图1示出了其中可以实现在此描述的一个或更多方面的计算环境。诸如计算机100的计算设备可以容纳有各种用于输入、输出、存储和处理数据的组件。例如，处理器105可以执行多种任务，包括执行一个或更多应用、从存储器115之类的存储设备检索数据和/或将数据输出到诸如显示器120之类的设备。处理器105可以连接到随机存取存储器(RAM)模块110，后者可以临时存储应用数据和/或指令。可以以任何顺序存储和存取RAM模块110，这提供了对RAM模块110中的存储单元的同等可存取性。计算机100还可以包括只读存储器(ROM)112，其允许存储在其上的数据在关闭计算机100之后保持不变或继续存在。ROM 112可用于各种用途，包括存储计算机100的基本输入/输出系统(BIOS)。ROM 112还可以存储日期和时间信息，以便即使经过关机和重新启动信息仍保持不变。此外，存储装置115可以为包括应用和数据文件的各种数据提供长期存储。在一个实例中，处理器105可以从存储装置115取回应用，并在应用正在执行时将与应用关联的指令临时存储在RAM模块110中。
计算机100可以通过各种组件和设备输出数据。如上所述，一个此类输出设备可以是显示器120。另一个输出设备可以包括诸如扬声器125之类的音频输出设备。每个输出设备120和125都可以与诸如显示适配器122和音频适配器127之类的输出适配器关联，后者将处理器指令转换成相应的音频和视频信号。除了输出系统以外，计算机100还可以从各种输入设备(如键盘130、存储介质驱动器135和/或麦克风(未示出))接收和/接受输入。与输出设备120和125一样，每个输入设备130和135都可以与适配器140关联以便将输入转换成计算机可读/可识别的数据。在一个实例中，通过麦克风(未示出)接收的语音输入可以被转换成数字格式并存储在数据文件中。在一种或多种情况下，诸如介质驱动器135之类的设备可以用作输入和输出设备两者，允许用户向和从存储介质(例如，DVD-R，CD-RW等)写入和读取数据。
计算机100还可以包括一个或多个通信组件以便通过网络接收和发送数据。各种类型的网络包括蜂窝网络、数字广播网络、网际协议(IP)网络等。计算机100可以包括适于通过一个或多个这些网络进行通信的适配器。具体地说，计算机100可以包括网络适配器150，用于通过IP网络与一个或多个其他计算机或计算设备通信。在一个实例中，适配器150可以帮助通过公司或组织的网络传输数据，例如电子邮件消息和/或金融数据。在另一个实例中，适配器150可以帮助传输或接收来自诸如因特网的万维网的信息。适配器150可以包括一组或多组与一种或多种联网协议有关的指令。例如，适配器150可以包括第一组指令以便处理IP网络分组以及包括第二组与处理蜂窝网络分组关联的指令。在一个或多个布置中，网络适配器150可以为计算机100提供无线网络接入。
本领域的技术人员将理解，诸如计算机100的计算设备可以包括各种其他组件，并且不限于图1中描述的设备和系统。
图2示例性示出用于从提供方(provider)205向客户应用210提供信息和服务的消息传送系统和基础结构。提供方205可以包括发布数据(例如市场数据、事务处理信息、医疗记录等)和/或提供服务或能力的应用和/或系统。例如，诸如事务处理网关205f之类的提供方可以协助事务处理以响应客户应用的请求。另一方面，客户210可以从诸如电子组件新闻(ECN)馈给(feed)205e之类的新闻提供方检索标题和文章。其他类型的提供方可以包括直接交换馈给205a、增值数据服务器205b、供应方馈给205c、本地数据储存库205d以及贡献馈给205g。
可以通过直接连接或替代地通过诸如市场数据系统(MDS)215之类的数据系统，建立来自客户应用210和提供方205的通信。具体地说，可以将市场数据系统215部署在客户应用210和提供方205之间，以促进其间的通信和服务。在一个或更多配置中，市场数据系统215可以对应于诸如REUTERS市场数据系统(RMDS)6.0之类的系统。市场数据系统215可用于提供应用协议接口(API)以便解析、分析、格式化和以其他方式处理由提供方205发布以供客户应用210使用的数据。市场数据系统215还可以提供代理服务，所述代理服务能够组织从一个或更多提供方205获得的大型数据和/或能力集合。此外，代理服务可以提供标识方案以便将不同的提供方划分为一个或更多服务类型类别。例如，市场数据系统215可以根据诸如商业分类、统一供应方、直接交换馈给、交换网关之类的准则，对数据和能力进行分类。代理服务通常可以是动态的并且可以在运行中(即，不中断其他过程)被创建和/或删除。在一个或更多配置中，客户应用210可以动态地发现代理服务。许可和管理块220和225可用于在数据流过系统时修改数据的能力。例如，许可块220可以将许可控制数应用于数据，进行授权以拒绝客户访问数据。
图3示例性示出了包括多个接入点307和308以便分别促进客户应用310与服务提供方305，和市场数据系统315的通信和事务处理的数据系统配置。具体地说，接入点307可以是直接或实际接入点，而接入点308可以构成代理接入点。也就是说，应用310a和310d可以通过与接入点307连接来直接访问服务提供方305的内容和能力。相比之下，应用310b和310c可以通过与数据系统315关联的接入点308和/或其中的代理服务提供方来访问服务提供方305的内容和能力。直接接入点通常允许客户应用直接地与由这些直接接入点所对应的一个(多个)服务提供方提供的内容和能力进行交互。另一方面，代理接入点与协调客户应用和一个或更多服务提供方之间的通信和事务处理的数据系统和/或其代理服务提供方关联。当需要某些未由服务提供方直接提供的能力时，客户应用310b和/或310c可以使用代理服务提供方。例如，代理服务提供方可用于提供诸如对跨多个服务提供方编辑的数据的大规模检索之类的服务。
在许多当前的系统中，发送到和接收自服务提供方(如图2的服务提供方205)的消息需要符合和遵守特定的消息规范和传输协议，这取决于该消息的类型和内容。新的数据和消息类型通常必须被内置到任何中间数据系统(如图2的市场数据系统215)或代理服务提供方，以便确保与新的交互和/或消息类型兼容。在此描述的方面提供了一种通过消除对预先定义每一个可能的消息或数据类型的需要来增强数据系统的可扩展性的架构和模型。
图4示例性示出了可扩展的消息传送模型和架构，其包括三个功能层：域消息模型401、开放消息模型402以及线格式(wire format)403。线格式403指可以为所有通信定义而与数据或内容类型无关的通用编码格式。例如，可以在当前使用多种不同线格式(例如，Marketfeed、QForms、TibMsg、ANSI Page、SSL和RRMP)的金融应用中使用该通用编码格式。因此，数据系统不需要与多种线格式兼容，而是可以采用单一的线格式。所述线格式可以实现可在数据网络内的多个组件和/或设备之间(例如，在客户应用与服务提供方之间)传送的原始数据类型或构建块(buildingblock)。然后，可以根据在此说明的方面将基本数据类型用于构建和/或表示更复杂的传输和数据格式(将在下面详细说明)。线格式的基本数据类型可以包括固定大小的有符号和无符号8位、16位、32位和64位整数，特殊值可变大小的无符号16位和32位整数，保留位可变大小的无符号15位、30位和62位整数，包括32位和/或64位整数系数和6位整数指数的实数值，IEEE标准754浮点数，时间和日期，不同长度的缓冲区，ASCII字符串，RMTES字符串，UTF8字符串以及任何上述可变类型的数组或它们的组合。
根据一个或更多方面，开放消息模型层402可以构建在多个子层(如传输子层410和数据子层411)上。子层410和411提供了定义、结构化和传送各种类型的内容的能力。例如，传输子层410可用于封装消息，与这些消息所关联的特定语法或语义无关。具体地说，传输子层410可以定义使含义和上下文遵从域消息模型401所创建的项目(item)类型模型和内容定义模型的通用消息类型和属性。在一种或多种情况中，与通用消息类型关联的上下文或含义可以对应于客户应用处理消息的方式。项目(如此处使用的)指由服务提供方发布或以其他方式可用的数据、能力和/或服务。项目可以包括市场价格信息、股票事务处理、价格报价等。传输子层410还可以定义一个或更多用于对通信和/或交互进行归类和分类的交互范例。这些交互范例可以包括请求/响应、带有兴趣的请求/响应以及收听/发送。在一个实例中，请求/响应交互指在接收响应时完成的信息请求。另一方面，带有兴趣的请求/响应涉及对可随时间变化的数据和/或能力的请求。因此，在带有兴趣的请求/响应范例中，初始响应可能只包括确认消息。然而，即使在初始响应(创建事件流)之后，交互仍保持为活动的以便向请求用户或应用提供更新响应(即，事件)。例如，事件流可以提供易于周期性地和/或间歇性地改变的股票市场价格或新闻标题。收听/发送(即，发布/订阅)交互涵盖来自不知道可能客户的服务提供方的传输。作为替代，客户可以匿名地订阅或收听服务提供方发布/发送的数据。
可替代地或额外地，传输子层410还可以定义一个或更多与各种交互范例关联的通用消息类型。此类通用消息类型可以包括请求消息、刷新消息、更新消息、状况消息、关闭消息以及确认消息。刷新消息可用于使用属性信息和/或内容来响应请求消息。刷新消息还可用于异步地更改已打开的事件流的数据。另一方面，更新消息可以对应于与已打开的事件流关联的异步数据事件。在一个或更多布置中，刷新消息可以指响应于请求被发送到客户的初始消息，而更新消息用于修改已改变的初始消息内的数据。状况消息可用于表示与已打开的事件流关联的异步属性改变。例如，如果数据或事件流被重定向到另一提供方，则可以发送状况消息。此外，关闭消息可用于关闭对现有事件流的未完成的请求，而确认消息可用于对未完成的请求或关闭请求/消息进行确认。使用域消息模型(例如，图4的模型401)，所述通用消息类型可用于传送各种消息和数据，同时保持基础语义、结构或内容。在一个实例中，可以使用与定义和发送新闻报告相同的通用消息类型和传输语义来传输和定义金融数据。可以通过改变和/或替换可应用的域消息模型来修改其中处理和定义被发送数据的上下文和方式，而不必修改或改变由传输和数据层定义的语义、语法和构造。换言之，可以在保持传输和数据层的同时执行消息上下文的改变。因此，内容消息模型的可扩展性与为之使用该内容消息模型的上下文无关。
每个通用消息类型都可以由一组或更多组基本属性来表征。此类基本属性的实例可以包括类型、流标识符以及扩展报头，如图5中所示。类型属性通常可用于标识消息中表示的项目类型模型，而流标识符可用作允许应用使用不同值(例如，无符号32位值)而不是完整关键字(key)来引用事件流的优化特性。使用流标识符而不是完整关键字可以节约带宽使用。此外，通过标识与消息关联的项目类型模型，消息的客户或接收方将能够适当地解析和处理消息中包含的数据。这样，可以使用在此说明的通用消息模型来传送用于表示各种真实世界对象(例如，报价、定购图书等)的数据。此外，在其中消息属性被标识为不适合任何通用消息属性的一个或更多事件中，可以使用扩展报头来存储此信息。一个或更多基本属性还可以是可选的，这取决于项目类型模型的偏好和/或规范。
在一个或更多配置中，除了消息属性之外，由传输子层(如图4的子层410)定义的通用消息类型还可以包括传输属性。传输属性可用于表征传输而不是其中包含的消息。例如，图6A-6C示例性示出了多个传输属性和模型，包括可以包含在一个或更多通用消息类型内的关键字、状态和服务质量(QoS)。如图6A所示，Key属性还可以包括指定信息的字段或数据元素，所述信息例如：服务标识符、所请求信息的名称、名称类型、用于存储可选内容/格式的过滤器、用于标识不同信息(例如，版本号)的标识符、允许使用其他标识机制(例如，查询、复杂过滤器等)的不透明缓冲区，以及用于指定不透明缓冲区的数据格式的不透明数据格式。不透明缓冲区的一个实例使用是向历史数据库提供SQL/XML查询。在另一个实例中，过滤器字段可用于指定可选择的值以便选择多个期望内容中的一个或更多。具体地说，如果客户只想要概要信息来确定字典类型，则可由客户在过滤器字段中指定相应的值。
图6B示例性示出了定义可用于表征交互的各种状况指示符的通用状态模型。状况信息可被分成多个类别，包括流状态、数据状态、代码和文本。流状态传送使用带有兴趣的请求/响应范例时与事件流的状态有关的信息。然而，在非流范例(例如，请求/响应)中，状况可以被设置为“未成流”(non-streaming)。“未指定的”流状态指示状态没有被指定或者请求是未决的。“打开”流状态指定事件流被主动地打开并且可在任何时间发生异步事件。另一方面，“已关闭”状态表示“打开”状态的相反状况。换言之，“已关闭”状态指示流被关闭并且无法从提供方获得。“已关闭恢复”状况对应于将要由客户应用重新打开的已关闭的流。流状态还可以被设置为“重定向”状况，表示所请求的信息或能力在另一服务提供方或位置处是可获得的。可以在关键字中指定服务提供方或位置，在所述服务提供方或位置可获得信息或能力。
数据状态可用于表示事件流中的响应内传送的数据的质量。数据状态可以包括未指定(即，数据的状态是未指定的)、OK(即，数据状态是有效的和/或最新的)以及不可信(即，数据的状态未知或失效)。除了流状态和数据状态信息，可以定义状态代码来为流和/或数据状态提供额外的状况信息。这些状态代码可以包括无(没有可用的额外信息)、未找到(无法从提供方获得项目)、超时(请求已超时)、未授权(客户未被授权访问项目)、无效变元(invalid argument，请求中传递的无效变元)、使用错误(消息或消息内容的非法使用)、抢占(事件流已被抢占以为另一事件流创建空间)、适时(JIT，just-in-time)合并启动(基于按需的数据的合并)实时恢复(适时合并已结束)、故障转移启动(已针对服务启动源镜像故障转移)、故障转移完成(对于服务，从一个提供方到另一提供方的恢复完成)、间隙检测(对来自数据发起方的消息间隙的检测)、无资源(不存在更多的资源来处理请求)、过多的项目(用户或客户已达到允许的最大事件流数)、已打开(已为客户打开事件流)、服务未知(关键字中指定的服务标识符不存在)，以及未打开(事件流未打开并且不能被关闭)。此外，还可以将文本包括在状态模型中以提供关于流和/或数据状态的文本信息。
图6C示例性示出了用于将数据和/或事件分类成服务级数的QoS模型。QoS通常可以包括两个特性：时间性和速率。时间性表示数据的年龄而速率指示数据中变化的最大周期(对于成流事件)。时间性可以被分解为两个子特性：实时和延迟。实时可以意味着没有延迟被施加到数据。换言之，数据是最新的并且一出现便被提供方发送。另一方面，延迟可以指示数据反映了请求信息的历史视图。如果数据被延迟，则可以指定延迟时间属性或特性以允许用户或客户补偿该延迟。
变化的速率，如QoS所使用的，可以被分类为逐笔(tick-by-tick)、时间合并或适时合并。逐笔意味着客户接收内容中的每次更新或变化，而合并意味着以保留内容的最终视图的方式组合多个事件。合并可以基于时间或基于其他参数，例如信道容量、拥塞等。时间合并和适时合并的不同之处可以是合并数据的时间间隔。具体地说，时间合并指以有规则的时间间隔进行合并，而适时合并指以按需为基础的合并。因此，在一个实例中，客户可以在请求中指定是期望实时数据还是延迟的信息，以及是将根据逐笔协议还是合并机制来更新数据。实时数据和/或逐笔数据可以被分类为向客户或用户收取比延迟或合并的数据服务更高的费用的更高级服务。
另一个可用于表征传输的传输属性是组标识符。组标识符可以指定事件流所属的项目组(例如，对于带有兴趣的响应/请求交互)。可以由提供方根据提供方的偏好和需要来定义项目组。在一个实例中，提供方可以维护多个到数据服务的数据链路。这样，对应于第一数据链路的多个客户请求可以被分组到第一项目组中。类似地，对应于第二数据链路的客户请求可以被分组到第二项目组中。如果数据链路变得不可信，则提供方可以将对应于该数据链路的项目组中的所有事件流的状况都标记为不可信。可以在各种时刻(包括在初始刷新消息中)建立和/或向客户传送项目组分配。
可以由一个或更多消息和传输属性来定义由传输子层(例如，图4的传输子层410)定义的每个通用消息类型。例如，图7A示例性示出了包括多个数据字段和元素的请求消息模型。除了根据图5描述的基本属性之外，请求消息模型700可包括指示有效负荷数据的通用格式的数据格式规范，以及指定请求/数据流的相对重要性的优先级级别。请求消息模型700还可以使用最佳QoS字段和最差QoS字段来指定服务质量(QoS)以定义可接受的QoS窗口。还可以将请求关键字包括在消息模型700中以标识所期望的内容或能力。有效负荷数据代表以数据格式元素指定的格式编码的原始数据缓冲区。例如，事务处理请求消息可以在有效负荷数据字段中包括事务处理信息。
在一个或更多配置中，请求消息模型700可以包括一个或更多请求选项，例如成流、更新中的关键字、更新中的合并信息以及无刷新。成流选项可以例如对应于期望，基于请求(例如，带有兴趣的请求/响应范例)来创建事件流。更新中的关键字可以指示客户想要编码在每个更新消息中的关键字。更新中的合并信息选项可以指定客户想要包括在更新中的任何更新合并信息，而无刷新选项用于指示没有刷新消息(例如，响应)被需要或希望。在多种情况下，例如，请求消息仅用于更新与先前请求有关的优先级信息的情况，客户可能不需要响应。由请求消息模型700示出的一个或更多字段可以是可选的(即，无需在消息中设置/定义这些字段)。
服务提供方可以通过由图7B的刷新消息模型720定义的刷新消息来响应根据请求消息模型700构建的请求消息。与请求消息模型700类似，刷新消息模型720可以包括基本属性，如类型、流标识符以及扩展报头。此外，刷新消息模型720可以包括诸如QoS规范、状态信息、组标识符以及关键字信息之类的传输属性。有效负荷数据存储根据数据格式字段中指定的格式编码的缓冲区中的请求数据。刷新消息模型720还可以包括许可表达式字段，其定义了访问所请求的项目数据/事件流所需的要求。例如，如果对金融预报的访问限于特定人员，则可能需要验证信息(例如，登录/密码)以便取回所述数据。刷新消息模型720还可以包括序号以便指示与事件流关联的最后序号。序号允许客户以合适的顺序构建事件(或数据)的时间线(timeline)。
此外，刷新消息模型720可以与一个或更多刷新选项(包括征求、刷新完成、垃圾缓存、不缓存以及提供方驱动选项)关联。征求表示关于消息是对请求的征求刷新还是对现有事件流的未征求刷新。刷新完成标志指示刷新或未征求刷新是否完成。例如，某些项目类型模型(如由域消息模型所定义的)可能需要单个刷新，其具有与数据一起设置的刷新完成标志。垃圾缓存选项是指定先前有效负荷数据缓存是否需要被删除的指示符。另一方面，不缓存选项指示客户不缓存当前刷新中包含的数据。此外，所包括的提供方驱动选项是在没有请求(即，广播模式)的情况下项目将被发送到客户的指示。一个或更多上述选项、属性和消息元素可以是可选的。
如图7C所示，更新消息模型740定义了被配置为表示与事件流关联的异步数据事件的更新消息。更新消息可以被赋予不同的用途和/或含义，这取决于项目类型模型和/或域。在一种或多种情况下，更新消息模型740可以共享许多与刷新消息模型720(图7B)相同的消息元素和字段。例如，更新消息模型740也可以包括诸如许可表达式和序号之类的字段和元素。更新消息模型740可以包括诸如更新类型和合并消息的额外字段。合并信息提供与可能已应用于给定事件的任何合并逻辑有关的信息。另一方面，更新类型可用于标识更新所对应的更新的类型。可以由指定的项目类型模型定义一个或更多更新类型。
此外，更新消息模型740可以关联有多个选项，包括不缓存、不合并、不波动以及提供方驱动。不波动选项的选择和/或使用限制更新中的任何字段的波动。另一方面，不合并指示客户或消息接收方不合并更新消息中的有效负荷数据。例如，服务提供方可以指示客户不合并新闻标题。
图7D示例性示出了用于修改数据或事件流的状况的状况消息模型。可以在状况消息模型760的状态字段中指定新的状态。例如，事件流的状况可以从“打开”改变为“重定向”。状况消息模型760还可以包括组标识符字段，以允许提供方使用单个消息来改变组内的多个事件流的状况。状况模型760还可以包括诸如垃圾缓存和提供方驱动之类的选项。
图7E和7F分别示例性示出了对应于关闭消息和确认消息的模型。关闭消息模型780包括基本消息属性和确认选项。确认选项指示提供方应该在收到和/或应用时对关闭进行确认。因此，当客户试图关闭事件流时，客户可以通过确认选项请求提供方确认该请求。确认消息模块790可以定义在一个或更多情况下可能使用的确认消息，以确认来自客户的关闭请求消息。确认消息模块790可以包括确认标识符(即，Ack Id)和IsNak选项。如果设置了IsNak选项，消息可以被视为否定的确认消息。此外，IsNak选项的使用的激活还可以指示消息包括Nak代码和Nak文本。
任何上述通用消息类型都可用于创建并分发来自客户或提供方或两者的信息。也就是说，请求可以源自提供方并被发送到客户并且反之亦然。开放消息模型的灵活性允许信息的双向传送和分发。
可以根据一个或更多数据格式和/或抽象来定义可包括在每个请求、刷新和更新消息中的有效负荷数据。通常由开放消息模型的数据子层(例如，图4的数据子层411)来管理这些数据格式和/或抽象。根据一个或更多布置，诸如模型402的开放消息模型可以使用由线格式(如线格式403)实现的基本数据类型来定义更复杂的数据格式和类型。如所述的，线格式403可以包括有符号整数值、IEEE 754浮点数和UTF8字符串这样的基本数据类型。由数据子层提供以定义数据格式和类型的其他数据构造可以包括记录集和概要数据。具体地说，概要数据可以存储与数据结构中的多个数据字段或条目(entry)有关的信息。例如，概要数据可用于指定与数据结构中存储的多个股票价格关联的货币。因此，数据结构中的每个股票价格条目可以无需单独地存储货币信息。
记录集可以由数据子层定义以优化基于记录的数据的带宽。基于记录的数据通常可以由字段/值对来表示。例如，字段部分可以存储条目标识符，而值可以存储与条目标识符对应的信息或数据。例如，字段/值对可用于存储股票价格数据。也就是说，字段部分可用于标识股票价格字段，而值可以对应于所标识的股票的价格值。图8示例性示出两个基于记录的数据结构，一个数据结构建立在标准的记录编码之上，另一个数据结构使用记录集编码来构建。标准的记录编码结构805将记录数据作为重复的字段部分和值对来存储和编码。另一方面，可以通过将字段部分815及其数据类型与值816分开，记录集编码结构810被存储和编码。因此，可以通过多个字段部分815及其类型来发送/定义/存储单个记录集定义或条目定义815。然后，可以由对于每个记录的单个条目定义815和条目数据810来表示多个记录。
可替代地或额外地，如图9所示，可以在单个消息内混合标准记录编码和记录集编码。这允许针对常见情况定义记录集，同时还支持开放系统的可扩展性。例如，在图9中，可以为4组记录905、906、907和908创建单个条目定义901。记录905、906和908可以都对应于和/或遵循由条目定义901定义的格式。然而，记录907可以不仅包括由条目定义901指定的数据，而且还包括未由条目定义901定义的额外的数据值。相应地，额外的数据值909可以被使用标准的记录编码来编码并被附加到记录907的记录集编码部分。
可以在本地或全局范围标识和定义记录集。本地范围指在条目数据的同一消息内发送/定义的条目定义。相比之下，全局范围指例如在记录集字典中发送/定义一次并且在许多不同的消息(即，记录)间重用的条目定义。例如，全局范围的记录集可用于编码证券报价和/或交易。此外，在一个或更多配置中，客户应用可以无需知道编码格式之间的差异。在此类配置中，解码库可以将被不同地编码的记录数据转换成一种编码格式或另一种编码格式，即，标准记录编码或记录集编码。
数据子层还可以支持分段功能以便将大型记录数据分成可管理的段和/或消息。可以基于记录数据中的逻辑条目边界来创建段，以简化接收应用的接收和解码过程。这样，接收应用可以接收单独的段并解码这些段而不必等待所有的段。根据一个或更多方面，还可以向接收应用提供总计数提示。总计数提示指示了结构内跨所有段的条目的总数。接收应用可以使用总计数提示来预先分配足够的存储器以便进行缓存。
类似于传输子层和由此定义的通用消息类型/模型，数据子层也可以定义一个或更多用于对各种类型和形式的内容建模的通用数据格式。此类通用数据格式可以包括元素列表、字段列表、向量、映射、级数和过滤器列表。例如，图10示例性示出了存储多个字段/值对条目1005的元素列表结构1000。字段/值对条目1005可以被顺序地存储在元素列表1000中，并且可以每个都包括诸如基于字符串的标签1010、数据类型1015以及值/数据1020之类的属性。基于字符串的标签1010可用于指定字段名称，而数据类型1015可以标识数据字段1020中存储的数据的类型。元素列表编号还可以被关联到或分配给元素列表100以优化缓存逻辑。例如，可以通过缓存逻辑做出带有相同元素列表编号的元素列表包含相同的条目/标签/类型的假设。此外，元素列表编号可以特定于某服务提供方。还可以在元素列表1000中定义计数以跟踪列表1000中存储的条目和/或记录数。
图11示例性示出了用于存储基于记录的内容的字段列表结构。字段列表1100在字段条目1105中存储字段标识符/值对。字段标识符可以是对应于数据字典1110中的条目的有符号2字节整数。使用数据字典1110，可以将诸如字段标识符1112的字段标识符转换成标签名称、数据类型、以及最大缓存长度。字段列表1100的每个条目1105还可以存储与每个字段标识符(例如字段标识符1112)关联的数据1113。从数据字典1110取回的信息可以向数据1113提供含义和结构。类似于元素列表，字段列表1100可以包括字段列表编号和计数。此外，字段列表1100可以标识一个或更多处理和/或解释条目1105所需的字典。可以由服务提供方或可替代地由客户应用来创建或定义字典。在一个或更多布置中，可以由与字段列表中存储的数据或项目类型关联的内容消息模型来指定数据字典。
图12示例性示出了用于存储位置定向条目(即，向量条目)的向量数据结构。可以通过索引值来标识每个向量条目位置，例如，索引值0可以对应于向量中的第一位置。诸如向量1200之类的向量还可以标识向量1200中存储的所有条目的数据格式。换言之，可要求所有向量条目1205都具有相同的数据格式。可以将各种数据格式存储为包括字段列表、元素列表、映射、级数以及过滤器列表的向量。向量1200还可以包括用于应用到所有条目1205的内容和/或信息的概要数据。可选地或额外地，记录集定义可以通过向量1200来标识，并且在向量条目1205由相同的记录数据结构(例如相同的字段/值对)定义时用于表征向量条目1205。向量1200中的条目1205还可以被设置、更新和/或清除，并且可以包括单独的许可表达式以提供更好的控制。向量1200中的条目1205还可以支持诸如插入和删除之类的排序操作，以便从向量1200添加和删除一个或更多条目。当被作为刷新消息传输时，诸如向量1200的向量还可以被分段。因此，向量1200可以指定总计数提示以促进接收应用处的缓存。
图13示例性示出了使用关键字存储条目的映射数据结构。可以通过形式为任何基本数据类型的关键字来标识映射1300中的每个映射表项1305。例如，可以通过ASCII字符串关键字、二进制缓冲区关键字或实数关键字来定义映射条目1305。与向量一样，映射(如映射1300)可以包括添加、更新和/或删除功能以便管理映射条目1305。此外，每个映射条目1305可以包括单独的许可表达式。映射条目1305可以具有与映射1300所指定的数据格式相同的数据格式。
图14示例性示出了使用隐式索引组织条目1405的级数数据结构。级数(如级数1400)类似于映射和向量，但通常用于表示和/或存储重复地构造的数据(其中由一个或更多字段(例如，时间、日期等)隐式地索引条目1405)。也就是说，级数条目1405可能没有显式标识。与向量和映射一样，级数1400可以包括数据格式规范、计数、记录集定义、概要数据和总计数提示。级数1400也支持分段。
图15示例性示出了被配置为基于位图标识符来组织和存储过滤器列表条目1505的过滤器列表数据结构。过滤器列表(如过滤器列表1500)通常由提供方定义并可用于将信息分解成可选择的条目1505。可以通过标识符大小来定义可能的过滤器条目1505的数量。也就是说，如果标识符对应于8位无符号整数，则只能将32个条目存储到过滤器列表1500。
在此讨论的通用数据格式可以被包含或存储在其他通用数据格式内。也就是说，通用数据格式可以彼此嵌套。例如，向量数据结构可以被存储在过滤器列表数据结构内并且反之亦然。在另一个实例中，图10示例性示出了元素列表1000中的字段/值对条目1005的数据1020内的嵌套的字段列表、元素列表、向量、映射、级数以及过滤器列表。因此，根据在此说明的其他和可替代方面，可以通过遍历通用数据格式的深度和宽度来检索和解码嵌套的数据格式。
再次参考图4，域消息模型401可用于根据真实世界对象(例如，市场价格和新闻标题)的要求和特性来定义这些对象。例如，市场价格对象可以包括股票符号和股票价格，而新闻标题对象可以包括主题、作者和报纸来源信息。因此，可以使用域消息模型401来定义对象，以特别地适应特定行业、组织或应用的需要。具体地说，域消息模型401可以使用由开放消息模型402提供的通用消息类型和数据模型来构建前述对象。例如，域消息模型401可以包括项目类型模型420，其定义了对象类型、相应的传输行为和/或数据表示(即，数据格式)。可以使用由开放消息模型402开发和支持的抽象、模型和概念来定义对象的这些概念和组件。项目类型模型420还可用于定义对象类型的结构或内容、对象类型的传输行为以及数据表示(即，数据格式)。域消息模型401还可以包括建立在项目类型模型420之上的内容定义模型421，以定义项目类型模型420所使用的字段含义和关系。内容定义模型421可以包括数据字典、枚举信息以及需要的/可选的字段定义。枚举信息可用于将枚举的字段转换成相应的数据或数据类型。此外，在一种或更多情况下，项目类型模型420可以与许多内容定义模型(如内容定义模型421)关联。
图16A-D示例性示出了使用开放消息模型的概念、抽象和模型创建登录项目类型模型的各个方面。图16A示例性示出了可用于授权对服务提供方的访问的登录项目类型模型1600的组件和元素。登录项目类型模型1600还可以为所有其他类型的交互在接入点(例如，图3的接入点307)内构建上下文。也就是说，登录项目类型模型1600可以定义将被应用于与登录项目类型关联的消息和数据的特定信息类型和含义。例如，登录项目类型模型1600可以定义可用于与登录项目类型关联的交互的消息分类1605。登录项目类型模型1600还可以指定与消息的关键字元素1610内存储的名称字段关联的数据格式或类型。还可以根据由域模型(例如，登录项目类型模型1600)指定的名称类型1615(例如，用户名和电子邮件地址)来定义消息关键字1610的名称字段。
图16B是标识与图16A的登录项目类型模型1600关联的传输语义的表。传输语义定义和/或指定了由域消息模型许可或支持的各种交互。例如，登录项目类型模型1600可以指示与登录项目类型关联的交互是遵循带有兴趣的请求/响应交互范例。登录项目类型模型1600还可以定义由基础开放消息模型定义的一个或更多通用消息类型(例如，请求、刷新、状况等)的含义或上下文。根据一个或更多布置，基于域消息模型为通用消息提供含义，同时保持和使用由传输和数据层定义的消息和传输语义以及数据格式。作为实例，模型1600可以将与登录项目类型关联的请求消息定义为到接入点中的登录请求。此外，模型1600将该请求消息的有效负荷表征为登录选项/参数。相应地，接收方客户、设备和/或用户可以应用此类定义和含义以解码和/或转换各种消息类型及其中存储的数据。
图16C示例性示出了由与登录项目类型关联的请求和应答数据使用的数据格式。在一种或多种配置中，可以使用元素列表(例如，图10的元素列表1000)来格式化登录项目类型请求和应答。因此，每个请求和响应(例如，刷新或更新消息)都遵循“标签，类型，值”数据格式。例如，在请求数据1620中，元素列表存储(除别的内容以外)ASCII字符串类型的应用ID以及缓冲区数据类型的密码。应答数据1630存储诸如ASCII字符串数据类型的接入点和缓冲区数据类型的许可简档之类的数据。许可简档信息可以指与特定用户关联的状况、授权和许可。可以以各种方式使用请求和刷新数据。例如，“不刷新”请求数据可用于修改接入点的参数。另一方面，未征求的刷新消息可用于重置所有应答数据(例如，新的用户简档)。可选地或额外地，更新消息可用于更新在刷新消息中发送的数据的多个部分(例如，用户简档的修改部分)。
图16D示例性示出了涉及登录项目类型的实例交互。在步骤1，客户可以初始地向提供方或其接入点发送登录请求(即，请求消息)。请求消息可以包括用户身份关键字、指示流交互的标志，以及包含各种参数的元素列表。在步骤2，提供方可以使用登录成功消息来响应所述请求消息。登录成功消息可以被格式化为刷新消息，后者指定了开放流数据和ok数据状态，并包括包含所请求的信息(例如，许可简档)或参数的元素列表。在登录之后，客户可以以期望的方式与接入点/提供方交互，并且可以在此类交互中使用其他项目类型模型。有时，例如在步骤3，提供方可能向客户发送更新消息，以更新在步骤2的响应中发送的任何所请求的或缺省的数据。例如，可以使用更新消息来更新对许可简档的更改。在客户完成与提供方或接入点的交互后，客户可以发出注销请求，如步骤4所示。注销请求可以采取关闭消息的形式，所述关闭消息标识了客户希望关闭的流。关闭消息还可以指示ack选项，所述确认选项引起步骤5中来自提供方的ack响应，从而确认成功的注销。
图17A-D示例性示出了可用于存储和/或发送信息的市场价格项目类型模型，所述信息与交易、指示性报价和最高预订报价有关。可以为各种市场工具(包括证券、固定收入、商品、货币、FX(即，外汇汇率)和贡献报价数据)定义或对其应用市场价格项目类型。可以使用消息分类1705a、工具关键字1705b、关键字类型1705c以及数据格式1705d来传递与这些工具关联的市场数据和价格。具体地说，工具关键字1705b可存储相应工具的名称或符号。例如，股票工具关键字可以通过股票的符号来标识股票以便检索关于该股票的数据。工具关键字类型1705c可以定义市场价格模型1700所理解或接受的各种类型的标识(即，名称)。此外，模型1700可以定义其中将要存储市场信息和/或数据的特殊数据格式1705d。在一个实例中，可以在字段列表格式中表示市场价格数据。这样，通过字段列表和/或相应的内容定义模型可以指定一个或更多数据字典，以便促进字段id名称的转换和解释。
在一个或更多配置中，可以使用请求/响应范例(带有或不带有兴趣)来传送和/或访问市场价格信息。换言之，可以通过单个请求/响应消息对或者通过其中周期性地和/或间歇性地传送更新和/或刷新消息的事件流，来传送市场价格数据。图17B是描述市场价格模型1700的各种传输语义的表。例如，传输语义可以为刷新消息赋予多种职责，包括：重置市场价格/事件流数据、用市场价格信息响应所请求的工具和/或重新定义与特定工具关联的标识符(例如，更改工具关键字中的名称类型)。传输语义还可以支持多个选项，如优先级支持、服务质量、均衡的流分组以及顺序编号。本领域技术人员将理解，还可以通过市场价格类型模型1700使用在此说明的可扩展系统和架构的各方面来定义多种其他类型的传输语义。
图17C示例性示出了用于三种类型的市场价格消息的数据编码。诸如刷新消息1715之类的响应通常包括和编码了构成对应于所述消息的工具的所有字段/值对。例如，股票工具可以包括诸如开盘价、收盘价、当日最高价、当日最低价、52周的最高价以及52周的最低价之类的字段。相比之下，诸如报价更新1725和交易更新1720之类的更新消息可以只包括将要更新的字段/值对。字段列表还可以使用标准记录编码或记录集编码或上述两者。
图17D示例性示出了客户和提供方之间的涉及市场价格数据和工具的实例交互。所述交互可以包括多个步骤，如请求、刷新和更新。例如，在步骤1，客户可以向提供方发送请求消息。所述请求消息可以将项目类型指定为“市场价格”，并使用RequestKey(请求关键字)中的服务、符号和/或符号表示法(symbology)字段来标识所请求的工具或信息。响应于该请求，提供方可以在步骤2中接收刷新消息中的市场价格数据。市场价格数据可以被格式化为字段列表并存储在刷新消息的有效负荷部分中。由于市场价格可以在一天中变化，因此客户可以在步骤3和4接收对数据修改一个或更多字段的更新消息。在一种或更多种情况下，客户可以仅接收对于字段列表的特定部分的更新。这样，可以仅发送改变的字段/值对。
图18是示例性示出基于消息模型与服务提供方交互的方法的流程图。在步骤1800，客户应用可以确定期望的与服务提供方的交互。例如，客户应用可以希望请求报价、出价和/或监视股票价格。在步骤1805，客户应用还可以标识与期望的交互关联的交互范例。诸如监视股票价格之类的交互可以例如对应于带有兴趣的请求/响应范例，以便可以使用流事件来周期性地和/或间歇性地更新股票价格。在步骤1810，客户应用可以向服务提供方发送请求消息。可以根据消息模型所定义的通用请求消息来格式化所述请求消息。例如，所述请求消息可以包括诸如服务质量、数据格式、优先级信息以及流标识之类的字段。在一个或更多个布置中，所述请求消息可以指定交互将要对应的交互范例。还可以通过数据系统发送(而不是直接地发送)所述请求消息。所述请求还可以标识和/或指定流标识符，后者标识了请求消息所关联的事件流(例如，如果事件流被在先发起或创建)。
响应于所述请求消息，客户应用可以在步骤1815中接收刷新消息。所述刷新消息可以包括根据消息模型所定义的数据格式来格式化的有效负荷数据。例如，可以通过一个或更多字段列表在有效负荷数据中表示市场价格信息。所述字段列表或有效负荷数据还可以指定一个或更多数据字典，用于解释存储在所述字段列表和/或有效负荷数据中的信息。根据一个或更多方面，如果同时发送客户应用所请求的数据所需的带宽太大，则可以将所述数据分段成较小的部分。在此情况下，刷新消息可以指示总计数提示。因此，在步骤1820中，客户应用可以分配足够的存储器来缓存分段的数据。这防止了潜在的缓冲区或存储器溢出。
在步骤1825，客户应用可以接收一个或更多提供了与所请求数据或交互关联的额外信息的更新消息。例如，请求股票价格监视服务可以涉及一整天中当所监视的股票价格变化时周期性地和/或不定期地接收多个更新消息。在另一实例中，请求股票事务处理的客户可以初始地接收刷新消息中的出价确认。一旦完成该事务处理，可以在稍后的时间收到完成消息。在步骤1830，一旦已经执行所请求的服务或已接收到所请求的数据，客户应用可以向服务提供方发送关闭消息以关闭与交互关联的事件流。在步骤1835，如果客户应用在关闭消息中请求确认，则随后客户应用可以接收来自服务提供方的确认消息。
在此描述的方法、模型和架构的各个方面可以以计算机可读指令的形式存储在计算机可读介质中。计算机可读介质的类型可以包括磁带驱动器、光存储装置、闪存盘、随机存取存储器(RAM)、只读存储器(ROM)等。此外，在此描述的方法、模型和架构的各方面也可以与其他行业和应用一起使用。例如，通过开放消息模型定义的通用消息可用于描述和表示图书馆应用的书籍信息。
根据本发明的优选和示例性实施例描述了本发明。通过回顾本公开，本领域技术人员将想到在所附权利要求的范围和精神之内的大量其他实施例、修改和变型。