CN1685693A - 中间件应用消息/事件模型 - Google Patents

Abstract

用于在产品的第一和第二软件构件(诸如应用软件和平台软件)之间传送消息的系统和方法。示范系统包括具有软件构件和接口构件的平台，接口构件具有用于为应用域中的应用程序或模块提供对软件构件的访问的接口。系统还包括消息传送机制，用于经由所述接口在应用软件或模块和平台之间传送消息，该消息传送机制包括：允许应用程序选择回调模式或全消息模式以在应用软件或模块和平台之间接收消息的消息模型；以及用于根据选择的模式路由消息的消息处理程序。

Description

中间件应用消息/事件模型

发明领域

本发明一般地涉及无线电信领域，更具体地说，本发明涉及用于在无线电信系统的移动终端中的第一和第二软件构件(诸如应用程序和平台软件服务构件)之间传送和接收消息的系统和方法。

相关技术描述

自从在80年代第一次引入蜂窝电信系统以来，系统中使用的移动终端(移动台)变得日益复杂。最初，设计移动终端主要为提供话音电话业务，即接收并传送话音通信。在随后的若干年中，开发了还包括传送与话音电话呼叫的用户数据无关的用户数据的能力的移动终端。这种用户数据包括例如要在通过个人电脑(PC)发起的拨号网络连接上传送的数据。

如今，正在开发用于未来移动电信系统的所谓“第三代(3G)”系统。3G系统将把高速因特网接入与传统的话音通信结合起来，并将为用户提供除话音通信以外的接入因特网浏览、流式音频/视频、定位、视频会议以及许多其它能力。

已经建立了第三代伙伴项目(3GPP)，以确保全球正在开发的3G系统之间的兼容性。通用移动电话系统(UMTS)是由3GPP开发的，用于提供包括能够在全球任何地方传递话音、数据和多媒体的陆地和卫星系统的3G系统。

经由3GPP标准化包括在蜂窝电信系统中功能大大增加，这对要用于系统中的移动终端的开发者提出了大量要求。移动终端是尺寸、存储器和功率受限的″资源缺乏的″环境，这一事实加重了上述要求。

传统上，移动终端厂商已经设计、制造并销售了基本完备的移动终端系统，该系统包括基本终端操作所需要的所有硬件和软件，以及基于厂商或特定用户对市场需求的理解来提供期望特征和功能所需的硬件和软件。这种方法并不提供快速适应市场需求迅速变化或者满足多个股东的不同需求的灵活性。

认识到用于设计和制造移动终端的传统过程的不足，已经开发了移动终端平台组件，其包括可作为一个单元销售给多个用户的多个功能上互补的软件和硬件单元。每个用户然后可将其自己的应用程序安装、加载到平台组件中并运行，以便提供满足用户自身特定需要的定制移动终端平台系统。在共同转让的美国专利申请序列号10/359911和10/359835中详细描述了移动终端平台组件和平台系统，这两个专利申请公开通过引用结合于本文中。

如上所述的平台系统(其中，分别开发移动终端平台组件软件和应用程序，随后通过在移动终端平台组件中安装、加载并运行应用程序的方式来结合移动终端平台组件软件和应用程序)需要经由平台组件中的接口将与服务请求相应的结果消息(也可包括事件信息传递)从平台组件中的软件传送给应用程序。可使用基于栈/过程的方法(即回调模式)或基于串行的方法(即全消息模式)来传送这种消息。

回调模式是一种经过充分证明的简单技术，该技术允许应用程序集中于特定应用功能，而将与基本和复杂机制相关的处理留给平台或框架。软件开发者可以将消息直接路由到结果的处理程序(功能/过程/方法)。例如，开发者/用户可启动用户接口应用程序，其中，例如窗口管理程序将保持用户交互事件信息或消息的消息传送到定义明确的处理程序。用户代码的调用完全由窗口管理程序确定。增值功能是开发者可以访问或可用的，而消息循环和消息释放不是用户可见的。因此，不需要开发者将不同的消息路由到程序的专用部分，并且开发者不能使系统降级。因此，在回调模式中，应用代码不能控制何时以及以什么顺序处理某个消息。在一些情况下，应用程序可能需要控制处理消息的顺序或者处理特定消息的时间(即优先级处理)。

相应地，另一种称为全消息模式的技术可用作回调模式的一种替代。全消息模式使消息在例如应用线程上排队。排队消息然后等待应用程序处理。可以有序方式(诸如用FIFO技术)处理排队消息，或者用并行或优先级方式处理排队消息。在此情况下，应用代码能够完全控制消息循环。

当前的解决方案(诸如结合到PalmOS和Brew环境中的那些解决方案)允许用户使用回调模式或全消息模式，但是用户或应用程序不能够自由选择接收输入消息的模式。回调或全消息模式是针对应用程序预先确定的。

因此，需要一种消息模型，该消息模型为用户(应用程序)提供通过回调模式或全消息模式接收消息的选择。用户可在不同情况下个别地选择哪种消息模式最适合问题。

发明内容

在本发明的一个实施例中，用于在产品的平台域和应用域之间传送信息的系统包括平台域，该平台域具有软件构件和接口构件。所述接口构件具有至少一个接口，用于为应用域中的应用程序或模块提供对软件构件的访问；以及消息传送机制，用于经由所述接口在平台域和应用域之间传送消息。消息传送机制包括消息模型，用于使应用域中的应用程序或另一个模块可以在回调模式和全消息模式之间选择或切换，以便从平台域接收消息。消息传送模型还包括消息处理程序，用于根据选择的模式路由消息。

在本发明的另一个实施例中，平台域具有软件构件和接口构件，该接口构件具有至少一个接口，用于为应用域中的应用程序或模块提供对软件构件的访问。一种在应用域和平台域之间传送消息的方法包括应用域中的应用程序或模块，该应用程序或模块选择回调模式或全消息模式，或者在回调模式和全消息模式之间切换。上述模式用于从平台域接收消息。消息处理程序根据选择的模式路由消息。

一种用于在第一和第二软件构件之间传送消息的消息传送机制，其包括消息模型，用于允许第一和第二软件构件之一选择回调模式和全消息模式，或者在回调模式和全消息模式之间切换，所述模式用于在第一和第二软件构件之间接收消息。所述机制还包括消息处理程序，用于根据选择的模式路由消息。

通过以下结合附图对本发明的详细描述，可清除本发明的其它优点和具体细节。

附图说明

图1是示意性地显示用于无线电信系统的移动终端的平台系统的框图，以帮助解释本发明的原理；

图2是示意性地显示图1的平台系统的移动终端平台组件的配置视图的框图，以进一步帮助解释本发明的原理；

图3是示意性地显示图1和2的移动终端平台组件的软件体系结构的框图，以进一步帮助解释本发明的原理；

图4是示意性地显示图1-3的中间件服务层的细节的框图，以进一步帮助解释本发明的原理；

图5是示意性地显示根据本发明原理的图4的中间件服务层的OPA域的细节的框图；

图6是示意性地显示根据本发明原理，在控制全消息模式或回调模式的过程中所使用的信令和构件的框图；以及

图7说明根据本发明原理的全消息模式或回调模式的调用流程。

本发明示范实施例的详细描述

图1是示意性地显示用于无线电信系统的移动终端的平台系统的框图，用于帮助解释本发明的原理。该平台系统总体用标号10表示，其包括移动终端平台组件12和已经安装、加载并运行在移动终端平台组件中的一个或多个应用程序(即应用软件)14中。平台系统10适于结合在一般性地用虚线16表示的移动终端中。

移动终端平台组件12包括软件服务构件22、硬件构件24和接口构件26。软件服务构件22包括多个结构完善的用于提供服务的功能软件单元，所述服务经接口构件26提供给用户。用户包括平台用户(例如电话制造商)和终端用户(例如电话用户)。在图1所示的示范系统中，所述多个软件单元包括多个垂直方向的功能软件栈30-38。

硬件构件24包括一组硬件单元，该组硬件单元与它们各自的功能软件栈相关联并由它们各自的功能软件栈控制。在图1所示的示范系统中，硬件单元是与软件栈30-38相关联的不同硬件块40-48。

接口构件26包括中间件服务层，其包括至少一个应用编程接口(API)，用于在移动终端平台组件12中安装、加载并运行一个或多个应用程序14，该中间件服务层用于将移动终端平台组件12与使用移动终端平台组件12的应用程序相隔离，并且为应用程序14提供各种其它的服务。下面将描述中间件服务层的具体细节。

为了以后扩展平台系统10的功能，移动终端平台组件12适于作为与应用软件14(本文中所用术语“应用软件”可以是提供用户可能希望获得的功能的任何软件)分离的完整的、封闭的单元来设计、实现(装配)和测试。因此，移动终端制造商和具有开发能力的其它各方可以开发或者获得他们自己的应用软件，并在以后将该软件添加到移动终端平台组件12中，以定制平台系统10。因此，可以将移动终端平台组件12销售或者转给多个不同的用户，每个用户可以通过在平台组件中安装、加载并运行他们自己的应用软件来定制平台系统10，以满足他们自身对平台系统的特定需求。

图2是示意性地显示图1的移动平台系统12的配置视图的一个示例的框图，用于进一步帮助理解本发明的原理。如图2所示，移动终端平台组件12经由在主CPU 50中执行的软件来控制。主CPU 50可包括一个或多个处理器，如微处理器、微型可编程处理器或DSP(数字信号处理器)。软件服务构件22的软件栈30-38各包括硬件驱动器软件60-68，以操作与每个栈相关联的硬件单元。在上述共同转让的美国专利申请序列号10/359835中详细给出了移动终端平台组件12和平台系统10的更多细节。

最好以使结合在移动终端平台组件12中的软件的组织易于理解的方式配置该软件，使得该软件更容易设计、更容易升级或修改。图3是示意性地显示移动终端平台组件12的软件体系结构的框图，以进一步帮助解释本发明的原理。

如图3所示，除了如上所述将软件服务构件22组织成多个垂直的功能软件栈，还可将软件服务构件22排列，以定义多个水平层，以使中间件服务层的软件和软件服务构件的软件共同定义分层结构(一般性地用标号70表示)，在该分层结构中，各层以递减次序从高服务层到低服务层排列。

该软件结构和标准ISO/OSI(ISO开放系统互连)模型的不同之处在于，它包括补充多个垂直分割的软件层的多个水平分割功能软件单元。水平分割非常有助于创建独立的模块(服务)构件。

分层结构的最高层是中间件服务层。软件服务构件22的层包括提供应用服务的应用服务器层80、为应用程序提供特定平台服务的平台服务层82、提供会话协议和特定应用协议的协议层84、提供音频访问/控制、数据通信传输协议、消息传输协议等的传输层86、提供外部数据IF访问、结构化存储服务和其它低级平台支持服务的数据访问层88、逻辑驱动器层90和封装硬件相关性的物理驱动器层92。此外，软件服务构件22包括提供平台组件所需要的一般服务的基本系统服务层94。

底部的两层90和92构成硬件抽象层(HAL)，用于隔离软件和硬件之间的相关性。只有物理驱动器层涉及硬件细节(即，ASIC硬件中的哪些寄存器是编址的)。逻辑驱动器层90提供到硬件的逻辑映射，即，该层提供移动终端平台组件12的硬件和软件部分之间的桥接。

软件本身组织成多个软件模块，图3中明确指示了模块102、104和106。在软件服务构件22中，单个模块可仅位于一个垂直功能栈中，并且可仅位于该栈内的一个水平层中。每层可包含一到多个模块，并且特定栈内特定层中的所有模块具有相同的抽象等级。各模块之间的通信通过软件底板(Software Black Plane-SWBP)112实现，SWBP 112受一组软件模块-模块访问基本规则制约。这些规则可概括为：

-软件模块可调用其下所有层中的功能。

-对串行数据流方向无任何限制。串行数据流可以流往任何方向。

-软件模块可以从不调用在其所在层以上的层接口中(在SWBP112中)的功能，与层属于哪一个模块无关。

-软件模块可调用相同垂直栈中其自身层中的层接口中的功能。

-软件模块可调用另一个垂直栈内相同层中的软件模块中的功能(此能力允许限制垂直栈中层的数量)。

在SWBP 112的不同模块和接口之间不存在硬耦合(hardcoupling)。因此，可以自由地变更模块和/或接口的实现，而不会对该接口的客户产生任何影响。这是一种重要功能，因为它允许增加、移去或变更单个模块而又不会影响平台组件中的其它模块。

在上述共同转让的美国专利申请序列号10/359911中描述了分层体系结构的更多细节，包括实现移动终端平台组件内模块之间内部通信的SWBP软件结构。

中间件服务层用于在移动终端平台组件12中的软件和平台组件中所要安装、加载并运行的应用软件14之间提供明确定义的接口。此外，中间件服务层封装移动终端平台组件12，通过中间件服务层将平台组件与应用程序14相隔离，并为应用程序14提供各种不同的服务。

图4是示意性地显示中间件服务层的细节的框图。如图4所示，中间件服务层包括多个API域，包括非本机环境如Java执行环境API域202、开放应用框架(OAF)API域204、开放平台API(OPA)域206和UI工具包API域208。

虽然API位于中间件服务层，但移动终端平台组件12支持多个应用环境。在图4中，中间件服务层支持本机应用程序(即经编译以通过特定处理器及其指令集运行的应用程序)和非本机应用程序如JAVA J2ME CLDC/MIDP(Java 2微型版连接有限设备配置/移动信息设备简表)应用程序的环境。每个应用环境具有其自己的特性并定义如下：

-开发应用程序的方法(编程语言支持、编译和链接)。

-执行应用程序的方法(例如，解释或本机代码执行)

-提供的功能服务。

-使用中潜在的限制。

通过提供多个应用环境选择，有助于提供具有不同需求，例如成本、易用性、上市时间、功能集、尺寸、便携性等的范围广泛的产品。

共同转让的美国专利申请序列号10/359772中描述了中间件服务层的更多细节，该申请的公开通过引用结合于本文中。

图5是示意性地显示根据本发明原理的开放平台(OPA)域206的主要软件模块的框图。如图所示，OPA域206包括五个模块：本机环境管理(NEM)模块230；本机应用核心(NAC)模块232；OPA接口和处理程序模块234；中间件支持服务模块236；以及本机扩展插件程序模块238。本机环境管理模块230负责控制平台系统10中的本机应用程序、接收来自应用管理程序的有关本机应用程序的控制命令，并且跟踪当前在系统中运行的本机应用程序。中间件支持服务模块236为OPA域206提供对不同处理程序公用或者需要集中的服务，例如目标管理和资源监督。

可以将本机扩展插件程序模块238看成是通过OPA接口和处理程序模块234对平台组件功能的可选扩展。NE插件程序模块238受接口准则、范例和机制的支配，所述接口准则、范例和机制与适用并控制OPA接口和处理程序模块234的接口准则、范例和机制相同。OPA本机扩展插件程序模块238通过OPA接口和处理程序模块234访问平台功能。

本机应用核心模块232管理并负责线程和消息处理复杂性(否则应用程序必须自己处理)。它的目的还在于通过隐藏OS的实现细节以实现OS独立性，从而使应用软件解脱运行时复杂性，所述复杂性包括消息路由/过滤和消息相关的资源处理。本机应用核心模块232的主要职责是隐藏应用程序14的启动和关闭阶段的细节以及消息处理过程中的细节。

图6显示了根据本发明原理，应用程序14使用回调模式或全消息模式，以便经由中间件服务层从平台组件12的软件服务构件22接收消息的过程中涉及的构件和信令。消息模型250使应用程序14可以根据何种模式对应用程序14的当前操作和情形最有利在回调模式252或全消息模式254之间选择。一旦应用程序进入期望的模式，则消息模型250启动与选择的模式(即回调模式252或全消息模式254)相关联的信令协定。NAC模块232知道选择的模式并根据必要的信令协定处理消息。

如果应用程序14选择进入回调模式252，NAC模块232就将消息导向OPA接口和处理程序模块234中的适当处理程序，该处理程序然后根据回调模式将消息格式化。在回调模式252中，软件开发者可以用功能/过程/方法(例如通用功能或专用功能)直接接收结果。当应用程序14在执行回调之后将执行控制返回给中间件服务层时，进入回调模式252。一旦应用程序14将控制返回给中间件服务层，就可以触发其它的回调功能。但是，在执行回调功能期间，应用程序通过使用全消息模式254可以处理其它消息。

如果应用程序14选择进入全消息模式254，NAC模块232便根据全消息模式254将消息导向适当的应用消息队列。软件开发者现在能够完全控制消息循环。全消息模式254是默认模式，并且在应用程序14控制其自身线程时激活。在此情况下，应用程序14可以选择在任何时刻通过到中间件服务层的显式请求来轮询消息队列。在全消息模式254下接收消息有几种选择。例如，用户或软件开发者可选择请求阻塞呼叫线程(最好使用超时)直到消息可用，或者检查消息而不阻塞线程。同样，可使用过滤参数，从而可以某种顺序响应消息，过滤掉不太重要的消息以便后续处理。在全消息模式254中，应用代码负责释放消息。因此应用程序14在某些情况下可选择将接收的消息转发给另一个应用程序14，而不需要再次释放和分配消息，从而提高了性能。

当从全消息模式254切换到回调模式252时，软件开发者可使中间件服务层的软件调用正确的回调功能。此外，应用程序14可以在任何时候(甚至实时地)在回调模式252和全消息模式254之间变更。因此，应用程序14具有在任何时候选择最适合各问题的消息接收模式的能力。回调模式252和全消息模式254可以以软件实体的任意组合在应用软件域中共存。

图7说明根据本发明原理的全消息模式或回调模式的调用流程。在步骤300中，系统启动后应用程序14首次获得对其主线程的控制。应用程序14将保持这种控制(如步骤302所示)，直到应用程序14决定等待来自中间件服务层的消息。然后，应用程序14将决定304在回调模式下还是在全消息模式下等待消息。如果决定是回调模式，则应用程序14将执行返回语句，该语句将应用线程的控制转给NAC模块232(如308所示)。然后，NAC模块232将轮询该线程的消息队列以获取现有消息(如310所示)。NAC模块232将持续轮询队列，直到发现消息为止，之后，NAC模块将调用先前由应用程序14指定的回调方法以处理该消息。这使循环结束，应用程序14又可以决定(如304所示)应用程序是进入回调模式还是进入全消息模式。

如果选择了全消息模式，则应用程序14必须确定是进入阻塞模式还是进入非阻塞模式(如306所示)。应用程序14将通过向中间件服务层中的OPA接口和处理程序模块234请求消息来达此目的。请求类型还将指示请求应该是非阻塞的还是阻塞的。如果发起非阻塞请求，则该请求将应用线程的控制转给NAC模块232(如308所示)。然后，NAC模块232将根据请求规范轮询该线程的消息队列，以了解是否存在消息。如果发现了匹配消息，则将该消息从消息队列中移去(如312所示)并将其返回给应用程序14。如果没有发现消息，则NAC模块232将线程的控制返回给应用程序14，而不传送任何消息。这使循环结束，应用程序14又可以决定应用程序是进入回调模式还是进入全消息模式(如304所示)。

如果选择了全消息模式，则应用程序14又必须确定是进入阻塞模式还是进入非阻塞模式(如306所示)。如以上针对非阻塞模式的所述，应用程序14将通过向中间件服务层中的OPA接口和处理程序模块234请求消息来达此目的。请求类型还将指示请求应该是非阻塞的还是阻塞的。如果发起阻塞请求，则该请求将应用程序14线程的控制转给NAC(如308所示)。NAC模块232然后会根据请求规范轮询该线程的消息队列，以了解是否存在消息。如果没有发现消息，则NAC模块232将继续轮询消息队列以获取请求的消息，直到发现一条消息或者超过潜在的指定超时期为止。一旦发现匹配消息，便从消息队列中移去该消息(如312所示)并将其返回给应用程序14。这使循环结束，应用程序14又可以决定应用程序是进入回调模式还是进入全消息模式(如304所示)。

以上所述的是本发明的示范实施例，但应理解，可以在不脱离本发明保护范围的前提下以许多种方式对本发明加以修改。例如，虽然对本发明的描述主要结合无线电信系统的移动终端的特定平台系统中的消息传送来进行，但本发明也可结合移动终端的其它平台、其它产品的平台中的消息传送来使用。由于可以以许多种方式来改变本发明，应该认识到，本发明仅受所附权利要求书所要求的范围限制。

Claims (23)

1.一种用于在产品的平台域和应用域之间传送消息的系统，所述系统包括：

平台域，其具有软件构件和接口构件，所述接口构件具有：至少一个接口，用于为所述应用域中的应用程序或模块提供对所述软件构件的访问；以及消息传送机制，用于经由所述接口在所述平台域和所述应用域之间传送消息，所述消息传送机制包括：

消息模型，用于使所述应用域中的应用程序或另一个模块可以在回调模式和全消息模式之间选择或切换，以便从所述平台域接收消息；以及

消息处理程序，用于根据所述选择的模式路由消息。

2.如权利要求1所述的系统，其特征在于：所述消息处理程序包括在所述平台域中。

3.如权利要求2所述的系统，其特征在于：

所述接口包括中间件服务层；并且

所述消息处理程序包括作为路由器包括在所述中间件服务层中的本机应用核心模块。

4.如权利要求3所述的系统，其特征在于：所述本机应用核心模块包括在所述中间件服务层的开放平台API(OPA)域中。

5.如权利要求1所述的系统，其特征在于：对所述消息模型的支持包括在所述平台域中并由所述应用域中的所述模块控制。

6.如权利要求1所述的系统，其特征在于：如果选择所述回调模式，则通过在调用回调功能/过程/方法之后所述应用程序将执行控制返回给所述消息处理程序的方式进入所述回调模式。

7.如权利要求1所述的系统，其特征在于：如果选择所述全消息模式，则通过在调用回调功能/过程/方法之后所述应用程序保持所述执行控制并轮询所述消息处理程序以获取排队消息的方式进入所述全消息模式。

8.如权利要求1所述的系统，其特征在于：所述应用域中的所述应用程序或所述模块可在任何时候在所述回调模式和所述全消息模式之间变更或切换。

9.如权利要求1所述的系统，其特征在于：所述平台域包括用于无线电信系统的移动终端的平台。

10.一种在应用域和平台域之间传送消息的方法，所述平台域具有软件构件和接口构件，所述接口构件具有至少一个接口，用于为所述应用域中的应用程序或模块提供对所述软件构件的访问，所述方法包括：

所述应用域中的所述应用程序和所述模块，所述应用程序和所述模块选择回调模式或全消息模式，或者在所述回调模式和所述全消息模式之间切换，所述模式用于从所述平台域接收消息；以及

消息处理程序，其根据所述选择的模式路由消息。

11.如权利要求10所述的方法，其特征在于：如果选择所述回调模式，则所述方法还包括如下步骤：通过在调用回调功能/过程/方法之后所述应用程序将执行控制返回给所述消息处理程序的方式进入所述回调模式。

12.如权利要求10所述的方法，其特征在于：如果选择所述全消息模式，所述应用程序还包括步骤：通过在调用回调功能/过程/方法之后所述应用程序保持所述执行控制并轮询所述消息处理程序以获取排队消息的方式进入所述全消息模式。

13.如权利要求10所述的方法，其特征在于还包括如下步骤：所述应用域中的所述应用程序或所述模块在任何时候在所述回调模式和所述全消息模式之间切换。

14.如权利要求10所述的方法，其特征在于：所述平台域包括用于无线电信系统的移动终端的平台。

15.一种用于在第一和第二软件构件之间传送消息的消息传送机制，所述消息传送机制包括：

消息模型，用于使所述第一和所述第二软件构件之一可以选择回调模式或全消息模式，或者在所述回调模式和所述全消息模式之间切换，所述模式用于在所述第一和所述第二软件构件之间接收消息；以及

消息处理程序，用于根据所述选择的模式路由消息。

16.如权利要求15所述的机制，其特征在于：所述第二软件构件在包括接口构件的平台域中，所述接口构件包括用于为所述第一软件构件提供对所述第二软件构件的访问的接口，并且所述消息处理程序包括在所述接口构件中。

17.如权利要求16所述的机制，其特征在于：

所述接口构件包括中间件服务层；

所述消息处理程序包括含于所述中间件服务层中的本机应用核心模块；以及

所述本机应用核心模块适于用作路由器。

18.如权利要求17所述的机制，其特征在于：所述本机应用核心模块包括在所述中间件服务层的开放平台API(OPA)域中。

19.如权利要求15所述的机制，其特征在于：对所述消息模型的支持包括在所述平台域中并且由所述应用域中的所述模块控制。

20.如权利要求15所述的机制，其特征在于：如果选择所述回调模式，则通过在调用回调功能/过程/方法之后所述应用程序将执行控制返回给所述消息处理程序的方式进入所述回调模式。

21.如权利要求15所述的机制，其特征在于：如果选择所述全消息模式，则通过在调用回调功能/过程/方法之后所述应用程序保持所述执行控制并且轮询消息处理程序以获取排队消息的方式进入所述全消息模式。

22.如权利要求15所述的机制，其特征在于：所述应用程序可以在任何时候在所述回调模式和所述全消息模式之间切换。

23.如权利要求16所述的机制，其特征在于：所述平台域包括用于无线电信系统的移动终端的平台。

Images