使用插件软件扩展移动平台功能的方法和系统 【技术领域】
本发明一般涉及无线电信领域；更具体地说，本发明涉及扩展并修改无线通信系统移动终端平台的功能而不修改其基本功能的方法和系统，
相关技术描述
对于许多终端用户移动产品的制造商和其他平台客户而言，提供可配置程度高的平台是具有吸引力的选择。可配置性对于高级功能而言尤其重要，这是由于一些客户需要这种功能，并且常常喜欢内部开发这种功能，而其他客户对于将这种功能包括在他们的产品中没有兴趣。
然而，提供可配置程度高的移动终端平台为平台的提供者带来了一些困难。例如，提供者必须支持加到平台中的任何高级功能，并且支持不同用户可能要求的许多种配置，例如通过为客户提供针对其具体配置的平台文档。同样，由于不能期望所有平台配置都正常工作，平台提供者有必要测试每个特定配置以确保增加的功能以用户期望的方式工作。此外，在许多情况下，增加的功能将依赖于平台中提供的其他功能并具有对上述其他功能的逻辑相关性，这样，如果删除了上述其他功能，则增加的功能可能不再正常工作。
此外，平台提供者常常希望维持其专有平台的细节。为了达此目的，平台提供者不应该让客户或任何其他一方直接接触其代码库，而是最好由客户将平台简单地看成是具有定义接口和定义行为的“黑匣子”。
然而，可配置程度高地平台可表现出维护专有平台的细节的困难。例如，平台提供者的通常做法是与第三方签约以开发平台的高级附加软件。平台提供者可以开发用于平台且随平台一起交付的应用软件。这种情况可能发生的一个典型的例子关于产品特定的功能，例如控制用户界面的观感的功能，该功能经常作为高级图形库来实现。由于观感是品牌特定的，此功能在不同产品和品牌之间会有所不同。
然而，如果契约第三方来开发高级附加程序，则该用户将需要访问平台代码库以便开发功能，从而迫使提供者将专有信息揭示给第三方。
此外，在已经配置平台并将该平台交付给用户之后，平台功能将已经经过测试、稳定并被固定。然而，客户可能具有修改、扩展并配置交付平台的附加需求，而交付平台的设计已预先排除了这种可能性。例如，客户可能希望修改所提供的功能的不同部分以使该平台适应特定需要，或者增加比交付平台中所包括的更强大的功能(即，平台提供者视为在平台域范围之外的功能)。此外，客户可能想在比平台提供者在基本平台组件配置中所提供的更详细的层次上配置平台功能，或者想执行某种形式的最后一刻配置，以便基于终端用户准备支付的内容来将功能加到平台中或从中删除。
一般而言，用于移动终端和其他产品的当前平台并未提供可借以扩展、删除或改变平台功能的有效过程。
发明概述
本发明提供了可借以扩展或者改变无线电信系统移动终端平台或另一个产品平台的功能的系统和方法。用于扩展和/或修改产品平台的功能的系统具有平台域，该平台域具有：软件服务构件，用于提供功能；以及接口构件，其具有至少一个接口，用于提供对软件服务构件的访问，以使应用软件能够经由所述至少一个接口在平台中安装、加载并运行。该系统还包括与应用软件共同使用的插件软件，用于经由所述至少一个接口扩展和/或修改平台域的软件服务构件的功能。
一种用于扩展和/或修改产品平台的功能的方法包括：提供平台域，该平台域具有：软件服务构件，用于提供功能；以及接口构件，其具有至少一个接口，用于提供对软件服务构件的功能的访问，以使应用软件能够经由所述至少一个接口在平台中安装、加载并运行。该方法还包括与应用软件一起提供插件软件，用于经由所述至少一个接口扩展和/或修改平台域的软件服务构件的功能。所述方法还包括经由所述插件软件扩展和/或修改软件服务构件的功能。
通过以下结合附图所作的详细描述，将阐明本发明的其他优点和具体细节。
附图简述
图1是框图，其示意性地显示了用于无线电信系统移动终端的平台系统，以帮助解释本发明的原理；
图2是框图，其示意性地显示了图1的平台系统的移动终端平台组件的配置视图，以进一步帮助解释本发明的原理；
图3是框图，其示意性地显示了图1和2的移动终端平台组件的软件体系结构，以进一步帮助解释本发明的原理；
图4A是逻辑框图，其示意性地显示了图1-3的中间件服务层的细节；
图4B是图4A的框图的实现视图；
图5是框图，其示意性地显示了开放平台API(OPA)域的主要软件模块；
图6A和6B是框图，其分别示意性地显示了开放平台API(OPA)域的逻辑和实现视图；以及
图7A和7B是分别示意性地显示了插件软件模型在回调模式和全消息模式中实现消息模型一致的顺序图。
本发明示范实施例的详细描述
图1是框图，其示意性地显示了用于无线电信系统移动终端的平台系统，以帮助解释本发明的原理。平台系统一般地由标号10表示，其包括移动终端平台组件12和已经被安装、加载并运行在移动终端平台组件中的一个或多个应用软件(即应用软件)14中。平台系统10适于结合到移动终端(其一般地由虚线16表示)中。移动终端平台组件12包括软件服务构件22、硬件构件24和接口构件26。软件服务构件22包括多个用于提供服务的、结构完善的功能软件单元，所述服务经由接口构件26提供给用户。在图1所示的示范系统10中，多个软件单元包括多个垂直方向的功能软件栈30-38。
在图1所示的示范系统10中，硬件构件10包括一组硬件块40-48，这些硬件块与它们各自的功能软件栈30-38相关联并由它们各自的功能软件栈30-38控制。接口构件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，以操作与每个栈相关联的硬件单元。在共同转让的美国专利申请No.10/359835中详细给出了移动终端平台组件12和平台系统10的更多细节。
最好以使结合在移动终端平台组件12中的软件组织易于理解的方式配置该软件，以使该软件更容易设计、更容易升级或修改。图3是框图，其示意性地显示了移动终端平台组件12的软件体系结构，以进一步帮助解释本发明的原理。
如图3所示，除了如上所述将软件服务构件22组织成多个垂直的功能软件栈以外，也可将软件服务构件22排列，以定义多个水平层，使得中间件服务层的软件和软件服务构件22的软件共同定义一个分层结构(一般地由标号70表示)，其中各层下降次序从高服务层到低服务层排列。
该软件体系结构和标准ISO/OSI(ISO开放系统互连)模型的不同之处在于，它包括补充多个垂直分割的软件层的多个水平分割的功能软件单元。水平分割非常有助于创建独立的模块(服务)构件。
分层结构的最高层是中间件服务层，它是接口构件26的组成部分。软件服务构件22的层包括提供应用服务的应用服务器层80、为应用软件提供平台特定服务的平台服务层82、提供会话协议和应用特定协议的平台协议层84、提供音频访问/控制、数据通信传输协议、消息传输协议等的传输层86、提供外部数据IF访问、结构化存储服务和其他低级平台支持服务的数据访问层88、逻辑驱动器层90和封装硬件相关性的物理驱动器层92。此外，软件服务构件22包括提供平台组件12所需一般服务的基本系统服务层94。
底部的两层90和92构成硬件抽象层(HAL)，用于隔离软件和硬件之间的相关性。只有物理驱动器层涉及硬件细节(即，寻址ASIC硬件中的寄存器)。逻辑驱动器层90提供到硬件的逻辑映射，即，该层提供移动终端平台组件的硬件和软件部分之间的桥梁。
软件本身组织成多个软件模块，图3中明确指示了模块102、104和106。在软件服务构件22中，单个模块可只驻留在一个垂直功能栈中，并且可仅驻留在该栈内的一个水平层中。每层可包含一到多个模块，并且特定栈中特定层中的所有模块具有相同的抽象等级。不同模块之间的通信经由受一组用于软件模块与模块访问的基本规则约束的软件底板(SWBP)112来完成。这些规则可概括为：
-软件模块可调用其所在层以下所有层的功能。
-不存在对串行数据流(包含例如事件信息或数据流)方向的任何限制。串行数据流方向可以是任意的。
-软件模块绝不可调用在其所在层以上的层接口(在SWBP 112中)的功能，与该层属于哪一个模块无关。
-软件模块可调用相同垂直栈中其自身层中的层接口中的功能。
-软件模块可调用另一个垂直栈中的相同层中的软件模块中的功能(允许此功能以限制垂直栈中层的数量)。
SWBP 112中的不同模块和接口之间不存在硬耦合。因此，可以随意改变接口的实现和/或模块，而不对该接口的客户产生任何影响。此能力允许增加、删除或改变单个模块而不影响平台组件中的其他模块。在共同转让的美国专利申请No.10/359911中描述了分层体系结构的更多细节，包括实现移动终端平台组件内模块之间的内部通信的SWBP软件结构，所述申请的公开通过引用结合于本文中。
中间件服务层用于在移动终端平台组件12中的软件和要在平台组件中安装、加载并运行的应用软件14之间的明确定义的接口；并对移动终端平台组件12进行封装，且通过中间件服务层将平台组件12与应用软件隔离，以及为应用软件14提供各种其他服务。
图4A是框图，其示意性地显示了接口构件26的中间件服务层的细节。如图4A所示，中间件服务层包括多个API域，包括非本机环境如Java执行环境API域202、开放应用框架(OAF)API域204、开放平台API(OPA)域206和UI工具包域208。
通过中间件服务层中的API，移动终端平台组件12支持多个应用环境。在图4A的示范实施例中，中间件服务层支持本机应用软件(即，经编译以通过特定处理器及其指令集运行的应用软件)的环境和非本机应用软件如JAVA J2ME CLDC/MIDP(Java 2微型版连接有限设备配置/移动信息设备简档)应用软件的环境。每个执行环境具有其自身的特性，定义如下：
-开发应用软件的方法(编程语言支持、编译和链接)。
-执行应用软件的方法(例如，解释或本机代码执行)。
-提供的功能服务。
-潜在的使用限制。
通过提供多个应用环境选择，便于提供具有不同要求，例如成本、易用性、上市时间、功能集、尺寸、便携性等要求的各式各样的产品。每个API域包括多个软件模块，各API域的细节参见共同转让的美国专利申请No.10/359772，该申请的公开通过引用结合于本文中。
图4B是应用域500和中间件域501的实现视图。图4B显示了两个插件软件：插件软件A 510和插件软件B 512，这两个插件软件驻留在应用域500中，以便扩展和/或修改中间件域501的开放平台API 514的服务。插件软件A 510可仅依赖于开放平台API 514，而插件软件B 512可依赖于插件软件A 510及开放平台API 514。本机应用软件508和非本机应用软件506均依赖于插件软件A 510、插件软件B 512以及开放平台API(OPA)514。在非本机环境(例如Java虚拟机)的情况下，在应用软件506依赖于非本机环境504的意义上，应用相关性是间接的。非本机环境504依赖于插件软件A 512、插件软件B 512以及开放平台API 514。
图5是框图，其示意性地显示了根据本发明示范实施例的开放平台(OPA)域206的主要软件模块。如图所示，OPA域206包括五个模块：本机环境管理(NEM)模块230、本机应用核心(NAC)模块232、OPA接口和处理程序模块234、中间件支持服务模块236以及本机扩展插件软件模块238。
本机环境管理模块230负责控制平台系统10中的本机应用软件。本机环境管理模块230是涉及本机应用软件的控制命令的接收者，并且跟踪当前在系统中运行的本机应用软件。
本机应用核心模块232管理并维护线程化和消息处理复杂性，否则应用软件必须亲自处理。本机应用核心模块232还可通过简化操作系统的实现细节来实现操作系统无关性，以使应用软件摆脱运行复杂性，包括消息路由/过滤和消息相关资源处理。本机应用核心模块232的另一个重要职责是简化应用软件的启动和关闭阶段以及消息处理过程中的细节。
中间件支持服务模块236为OPA域206提供不同处理程序公用的或者需要集中化的服务，如目标管理和资源监督。
本机扩展插件软件模块238为平台组件12的提供者提供灵活扩展的可能性。插件软件通过为终端用户设备制造商或另一方所编写的应用软件14提供附加接口和附加服务，从而有效扩展了平台组件的功能。
图5是显示作为开放平台API(OPA)域206的一个模块的插件软件的逻辑视图，而图6A则是显示根据本发明另一个示范实施例的开放平台API(OPA)域240的更一般的表示的逻辑视图，其中开放平台API域240具有多个开放平台API模块242、244、246和248以及插件软件模块250。在本逻辑视图中，也将插件软件模块250显示为结合在开放平台API域240中，这是因为，从客户的观点来看，插件软件模块250会表现为平台组件的中间件服务构件260的组成部分。然而，插件软件模块250实际上包括在平台组件12之上的应用软件域270中运行并使用平台组件所提供的功能的独立实体。这样，从实现的观点来看，它位于平台组件上方，使用开放平台API访问平台组件功能，如图6B的实现视图所示。
插件软件支持平台组件所支持的所有应用软件机制，并且符合平台组件中定义的应用模型。换句话说，插件软件将遵从与开放平台API所输出的提供的OPA服务相同的范例。这些包括但不限于：
·就如何定义和操作接口和构件而言的构件模型一致。插件软件实现为构件并将通过基于定义的功能或方法的接口来为终端产品应用软件提供其服务。
·命名惯例一致。插件软件使用与开放平台API相同的接口方法命名惯例。同样，在这些接口方法中定义的参数和类型将遵从开放平台API中采用的命名惯例。
·非期望事件处理一致。插件软件将以与平台相同的方式处理功能的可能的错误行为。根据与开放平台API相同的范例将有关这种错误的信息传递给应用软件。
·消息模型一致。插件软件将支持两种用于传递异步请求的结果的模式，即回调模式和全消息模式。
·基于对象和接口的范例。
就上述倒数第二点而言，消息模型一致对插件软件的行为和如何构建插件软件的影响很大。尤其是，平台组件消息模型为应用软件提供双模式，以便接收由异步服务请求或事件订阅产生的结果。双模式指通过回调机制(回调模式)或消息队列(全消息模式)接收结果。这为平台组件客户软件开发者提供了根据不同消息模型，组织不同应用软件的灵活性和自由度，具体依应用功能的性质而定。
应用软件通过执行或不执行返回语句来确定应用软件接收异步结果所用的模式。如果应用软件决定以回调模式接收结果，则应用软件在完成异步服务请求后返回执行控制。如果决定采用全消息模式，则应用软件在服务请求之后不返回执行控制，而是独自轮询消息队列并手动调用消息处理代码。本解决方案的另一个好处在于：应用软件实际上可以在运行时随时在回调和全消息模式之间切换。
插件软件模型符合消息模型的双模式，并将此灵活性透明地提供给客户的应用软件。图7A和图7B中示意性地显示了根据本发明一个实施例，用于实现这种一致的顺序，图7A示意性地显示了回调模式的顺序310，图7B示意性地显示了全消息模式的顺序。这些顺序图显示了开放平台API(OPA)316、插件软件(或实用程序)314和请求服务的应用软件312之间的交互作用。
1.在启动时，客户应用软件将从OPA接收执行控制。也可选择要求根据用于初始化OPA服务(平台组件功能)的相同范例来初始化插件软件服务。当调用插件软件接口“IY”(即应用软件请求插件软件的服务)时，插件软件将依靠一个或几个OPA服务接口“IX”来执行该任务。如图7A和7B所示，对于回调模式和全消息模式，这些服务请求步骤是相同的。
2.取决于希望如何接收结果，客户应用软件将执行控制返回给OPA(回调模式310)或者如图7A和7B中的318所示，通过全消息模式320轮询消息。
3.平台组件知道服务“IX”是为插件软件执行的，会通过调用插件方法例如根据322的处理消息方法将结果返回给插件软件。插件软件将来自平台组件的结果转换成图7A所示的消息格式并且将该消息返回给本例中以OPA 316表示的平台组件。注意，如果应用软件已向插件软件指示其仅仅希望以回调模式接收消息，则此步骤可以省略，这将加速结果的处理和传递。平台组件知道应用软件等待结果的消息模式，因此将返回结果。取决于那种模式有效，至少两种方案是可能的：
·如果应用软件处于根据图7A的回调模式310中，则用回调方法“ICBY_OnService”给出结果。在此情况下，插件软件将处理结果并将其格式化，以便可以使用过程调用通过栈返回。
·如果应用软件处于根据图7B的全消息模式320中，则利用步骤Handle_Message 322中由插件软件创建的消息来传递结果。当插件软件将结果以消息格式返回给OPA 316时，OPA反过来将控制从Get_Message返回给应用软件312，从而传递该结果。
使用根据本发明原理的插件软件模型，克服了上述关于改变移动终端平台功能的问题。例如，通过使用用于高级功能实现的OPA插件软件，平台提供者可提供更精简和更稳定的平台，该平台仍然包括视为满足终端用户产品需求的基本和/或缺省的平台功能。这使高级功能的管理更靠近应用域、终端用户产品的制造商以及其他用户，这是由于提供了作为插件软件的非标准附加功能，这些功能可根据相关的特定产品容易地增加/删除。
此外，采用本发明的实施例，第三方开发者可以将附加功能作为一个或几个插件软件实现，而无需将涉及平台代码库的专有信息透露给第三方开发者或其他各方。尤其是，由于插件软件是应用域软件的实体，第三方开发者可以选择仅使用缺省/基本的平台API。
通过采用如上所述的插件技术，平台组件的提供者可选择仅将代码库的受控的和指定的部分(即，独立插件软件中的一个或几个)透露给用户。例如，提供者可以选择将作为源代码的插件软件提供给客户，客户随后可变更并修改插件软件的代码，以调整插件软件的功能和行为。
通过提供具有更高级功能的多个插件软件，终端用户产品制造商或其他方容易扩展平台组件的功能。同样，平台提供者也可以将特定制造商的扩展传递给平台组件，所述扩展不被视为平台组件所提供的部分基本功能。
通过提供具有扩展功能的多个插件软件，还容易执行平台组件的“最后时刻”配置，例如用于调整平台组件以适应不同产品的不同需要，或者在购买时定制终端用户产品。采用本发明的实施例，使用平台组件的终端用户制造商容易作出是采用平台提供者插件软件还是内部开发功能的决定。
如上所述，可能需要产品平台的更高级功能的一个示例有关产品特定的功能，例如控制用户界面观感的功能。对于具有高级用户界面的移动终端和其他专用消费品，用户界面的观感是市场上产品区分和定位的关键，并因此对商业成功而言很重要。因此，希望移动终端和其他产品的平台在定义产品观感中提供很多自由度。
窗口系统核心与观感定义的分离是已得到证明并被广泛使用的概念。X窗口系统表现出这一点，并且存在使用这种类型的体系结构在相同窗口系统之上建立具有不同观感的系统的各种示例。另一方面，改变给定实现的观感的能力是受限制的。
传统上，Java VM的移植在低级别UI支持上实现。在很大程度上，观感是通过Java中图形对象的实现来定义的。MIDP(移动信息设备简档)的引入提出了另一种方法，其中仅在抽象层次上定义图形对象。观感由执行VM的底层系统定义。如果要实现Java应用软件与在Java VM外执行的其他应用软件之间的观感一致性，可以将相同的图形对象组用于以上二者。这对于具有已定义观感的系统而言是直接了当的。
根据MIDP规范，移动设备中的Java VM理想地依赖于它正在其上运行的平台来提供UI支持。这意味着对于包括Java VM的移动平台，MIDP支持也应该是平台的一部分。另一方面，对于用于不同厂商的高度描述(highly profiled)的消费品，提供对观感的最高的可能控制级别是重要的。显然，最高级别控制是通过控制图形对象定义来取得的。这两种对平台的矛盾要求不能用先前描述的方法满足。
然而，根据本发明的另一个示范实施例，将一组图形对象和实用程序定义为开放平台API(OPA)中的一个或多个插件软件。为了MIDP支持，一个或多个插件软件的接口必须固定且足够，但实现方式可随意改变。
根据本发明的原理，可以在本机应用软件和执行环境如Java之间共享高级图形对象和实用程序的实现。同时，平台用户对图形用户界面的观感和行为的控制程度非常高。
虽然所述内容构成本发明的示范实施例，应该理解，在不脱离本发明范围的前提下，可以许多种方式对本发明进行改动。例如，虽然主要结合特定移动终端平台组件来描述本发明，但这并非为了限制本发明，因为本发明也可以用在移动终端和其他产品的其他平台中。由于可以以许多种方式修改本发明，应该认识到，本发明仅应该仅由所附权利要求书要求的范围来限定。