为组件应用程序建立混合模式执行环境的系统和方法

摘要

提供了一种用于在计算设备上执行的设备运行时间环境。设备运行时间环境在运行时间为应用程序提供了智能容器，并且包括多个彼此相互通信的服务。多个服务包括数据管理器、屏幕管理器、通信服务和脚本解释器。数据管理器管理应用程序的数据组件，包括数据组件的数据库中的操作和持久性。屏幕管理器管理应用程序的屏幕组件，并对输出进行着色以显示在计算设备的屏幕上。通信服务根据相应的消息组件，向外部资源发送消息，并接收和管理外部资源发送的消息。脚本解释器动态地解释嵌入在数据组件、屏幕组件和消息组件中至少一个中的脚本，并将解释的输出传递给相应的组件管理器来实现。还提供了一种根据上述方法在设备上实现应用程序的方法，以及一种计算机可读存储器，用于存储指令来实现所述方法。

说明书

技术领域

本发明主要涉及运行时间环境，特别涉及能在可执行模式和解释模式下操作的运行时间环境。本申请要求2004年2月27日递交的美国临时申请号60/548,098的优先权。

技术背景

由于无线网络的快速扩展，现今使用中的无线设备的数量持续增长。这些设备包括移动电话、具有无线通信能力的个人数字助理(PDAs)、双向寻呼机等等。伴随增长的可供使用的无线设备，在这些设备上运行的软件应用程序增加了设备的实用性。例如，无线设备可以包括检索期望城市列表的天气预报或允许用户购买杂货的应用程序。这些软件应用程序利用向无线网络传输数据的能力，经常为用户提供除了语音通信以外的及时和有用的服务。然而，由于不同类型设备的数量、一些设备有限的可用资源和向设备传递大量数据的复杂性，软件应用程序的开发仍然是一项困难且耗时的任务。

当前，设备被配置用于通过基于因特网的浏览器和/或本机应用程序来与网络服务进行通信。浏览器具有适于在多个不同设备的交叉平台基础上进行操作的优点，但是具有向网络服务请求页面(HTML形式的屏幕定义)的缺点，该缺点妨碍了屏幕中包含的数据的持久性。浏览器的另一个缺点是在运行时间着色(render)屏幕，这占用了大量的资源。然而，浏览器的应用程序是设计平台无关应用程序的有效工具。因此，无论何种平台，不同的运行时间环境执行相同的应用程序。不幸地，由于不同的无线设备具有不同的能力和波形因数(formfactor)，应用程序可能不会像所希望的那样被执行或显示。此外，基于浏览器的应用程序经常需要相当数量的传输带宽来有效地操作，这对于一些无线设备来说可能是昂贵甚至不可用的。

另一方面，本机应用程序被开发用于特殊的无线设备平台，从而为在该平台上运行的运行时间环境提供了相对优化的应用程序。然而，平台相关的应用程序引起了几个缺点，包括必须开发相同应用程序的若干版本，并且在大小上相对较大，从而加重了无线设备的存储器资源的负担。此外，应用程序的开发者需要具有例如Java和C++的编程语言的经验来构建这样的本机应用程序。

因此可以看出，需要这样的应用程序，它能够运行在既具有广泛种类的操作系统、又具有减少的设备资源消耗的客户端设备上。此外，期望在尽可能地限制带给应用程序开发者的复杂性的同时，实现上述结果。

因此，本发明的目标是排除或缓和至少一些上述缺点。

发明内容

根据本发明的方面，提供了一种用于在计算设备上执行的设备运行时间环境，所述设备运行时间环境用于在运行时间向应用程序提供智能容器，所述设备运行时间环境包括彼此相互通信的多个服务，所述多个服务包括：数据管理器，用于管理应用程序的数据组件，包括在数据组件的数据库中的操作和持久性(persistence)；屏幕管理器，用于管理应用程序的屏幕组件，并且对输出进行着色以便显示在计算设备的屏幕上；通信服务，用于根据相应的消息组件，向外部资源发送消息，并接收和管理外部资源发送的消息；以及脚本解释器，用于动态地解释嵌入在数据组件、屏幕组件和消息组件中至少一个中的脚本，并且将解释的输出传递给对应的组件管理器来实现。

根据本发明的另一方面，提供了一种在计算设备上执行应用程序的方法，所述应用程序至少包括屏幕组件、数据组件、消息组件和工作流组件，所述方法包括：从屏幕、数据、消息和工作流组件创建可执行格式的应用程序，用于分别由屏幕管理器、数据管理器和消息管理器执行；对于来自工作流组件的、在执行应用程序前不能转换为可执行形式的信息，在应用程序执行期间使用脚本解释器动态地解释信息；以及将脚本解释器的输出分配到对应的屏幕管理器、数据管理器和消息管理器。

附图说明

现在仅作为示例，参考附图来描述本发明的实施例，附图中：

图1是通信基础设施的框图；

图2是无线设备的框图；

图3是示出了组件构架的框图；

图4是示出了组件应用程序的框图；

图5是示例运行时间环境的框图；

图6至16是应用程序的多个组件的示例XML定义；以及

图17至23是示出了多个应用程序场景的运行时间流的框图。

具体实施方式

为了方便，附图说明中相同数字指示相同的结构。参考图1，通过数字100主要示出了通信基础设施。通信基础设施100包括多个通信设备102、通信网络104、网关106和多个后端设备108。

通信设备102包括任何有线或无线设备，例如桌面计算机、膝上或移动计算机、智能电话、个人数字助理(例如捷讯研究有限公司的Blackberry^TM)等等。通信设备102通过通信网络104与网关106进行通信。因此，通信网络104可以包括多个组件，例如无线网络110、中继站112、企业服务器114和/或移动数据服务器(MDS)116，用以在设备102和网关106之间传递消息。网关106还与多个后端服务器108进行通信。后端服务器108的类型及其相应链路对本领域的技术人员来说是显而易见的。

无线应用技术需要在通常有限的计算资源(如速度、功率、存储、存储器)和间断连接下提供用于用户交互、与其它有线或无线应用程序进行通信以及数据存储的装置。这些限制给现实的有用应用程序的开发带来了极大的挑战。

一种减少应用程序开发复杂性的希望方法是：按照声明(declarative)方式来定义使应用程序个性化的这些组件。这种组件的实例包括用户界面、数据和通信模型。组件被呈现给例如设备运行时间环境的智能容器，作为契约(contract)，并且复杂但一般的任务被委托给智能容器来解决。

下面描述一种系统，通过这种系统，智能容器给利用元数据和脚本语言来定义的应用程序提供了本机执行环境。因此，构成无线环境复杂性的负担从应用程序转移到智能容器。因此，应用程序作者需要解决的唯一复杂性是在应用程序和智能容器之间清楚地定义契约，以确保期望的功能。

参考图2，更详细地示出了通信设备102(也简称为设备102)。设备102包括网络接口200、用户界面202、核心基础设施204和组件构架206。网络接口200包括无线收发器或有线无线接口卡或调制解调器，用于使设备102与网络104相连。例如，网络接口200使用已知或专有协议与无线网络104进行通信。这种特性使设备102能够在彼此之间以及和例如网络服务器106的外部系统无线地进行通信。网络104支持在设备和后端服务器108之间以请求和响应消息的形式进行数据传输。此外，网络104可以支持语音通信，用于在设备102和在网络104外部的设备之间进行电话呼叫。

用户界面202包括与用户(未显示)进行通信的一种或多种装置。例如，用户界面202包括：例如小键盘、轨迹球、手写笔、鼠标和麦克风的一个或多个输入设备，用于接收用户的输入；以及例如显示器和扬声器的一个或多个输出设备，用于向用户呈现输出。如果显示器是触摸敏感的，则显示器也可以用作输入设备。设备102的用户使用用户界面202来协调客户端应用程序201的请求和响应消息。

核心基础设施204包括计算机处理器208和相关联的存储器模块210。计算机处理器208通过执行相关的指令来操作通信设备116的网络接口200、用户界面202和组件构架206的工作，所述相关指令是由存储在存储器模块210中的操作系统和客户端应用程序(未显示)提供的。此外，可以认识到，设备基础设施204还可以包括计算机可读存储介质212，用于向处理器提供指令或向存储器模块210加载或更新客户端应用程序。计算机可读介质212可以包括软盘、磁带、例如压缩盘和数字视盘的光可读介质、存储卡等。

组件构架206包括能够从元数据定义中产生、作为寄主(host)并执行客户端应用程序的运行时间环境216。因此，组件构架206为客户端应用程序提供了本机客户端运行时间环境216，并且作为与核心基础设施204的处理器208和相关联操作系统的接口。组件构架206通过在设备100上至少提供可以执行组件应用程序的最小需求的受控、安全且稳定的环境，提供了运行时间环境216。将在整个说明书中描述运行时间环境的需求。

可以配置运行时间环境216，使得设备102操作作为网络服务器106提供的网络服务的网络客户端。可以认识到，运行时间环境216还可以使设备102成为服务器108提供的任意其它范型(generic)方案定义的服务的客户端。运行时间环境216能够产生、作为寄主和执行应用程序。此外，客户端运行时间环境的特殊功能包括支持不同的语言、协调存储器分配、组网、在输入/输出(I/O)操作期间的数据管理、协调输出到输出设备的图形并且提供对核心面向对象的类的访问以及支持文件/库。运行时间环境216能够基于的环境的实例包括Microsoft的公用语言运行时间(CLR)和Sun Microsystems的Java运行时间环境(JRE)。

运行时间环境216优选地支持可执行版本的客户端应用程序的下列功能：提供通过网络104向网络服务器108的网络服务或任意其它范型方案定义的服务发送消息的通信能力；允许通过输入设备从用户输入数据；提供通过输出设备向用户显示数据的数据呈现或输出能力；提供数据存储服务来在存储器模块210中维持和操作数据；以及提供用于在需要时执行脚本的脚本解释器。

参考图3，更加详细地示出了组件构架206。组件应用程序302包括由运行时间环境216执行的组件。运行时间环境216为组件应用程序302中的每个组件创建了应用程序容器301。应用程序容器301加载应用程序302的组件并创建由处理器208执行的可执行元数据。因此组件构架206提供了用于规定组件定义的寄主应用程序容器300，以创建对于通信设备102的每个设备基础设施204特定的真实的网络客户端。应用程序容器能够按照上述基于模板的本机执行模型和基于元数据的执行模型来规定组件应用程序302。

此外，组件构架206还可以将构架服务304提供给运行时间环境216，用于便于实施组件应用程序302的组件。应用程序302与应用程序容器300进行通信，应用程序容器300在需要时协调与构架服务304的通信216。组件构架206的构架服务304通过与设备基础设施204的连接220来协调通信。因此，组件构架206给客户端应用程序302提供了对设备基础设施204、用户界面202和网络接口200的访问。此外，客户端应用程序302能够适当地抵抗病毒，因为应用程序容器300能够控制和验证组件构架206与客户端应用程序302之间的通信的所有访问。可以认识到，设备基础设施204的操作系统的一部分可以表示应用程序容器300。

参考图4，组件应用程序302的框图中包括数据组件400、呈现组件402和消息组件404，三者由工作流组件406通过与应用程序容器300的通信来进行协调。可以将结构化定义语言用于构造组件400、402、404，使之成为一系列元数据记录，包括表示资源的特殊属性的多个预定义单元，使得每个单元可以具有一个或多个值。每个元数据方案通常定义了特征，例如但不限于：有限数目的单元、每个单元的名称以及每个单元的含义。元数据方案的实例包括例如但不限于：都柏林核心集(DC)、英美编目规则(AACR2)、政府信息定位输入器服务(GILS)、档案描述编码(EAD)、IMS全球学习联盟(IMS)和澳洲政府搜索服务(AGLS)。编码语法使得组件400、402、404的元数据由设备基础设施204(见图2)处理，并且编码方案包括例如但不限于：XML、HTML、XHTML、XSML、RDF、机器可读目录(MARC)和多用途因特网邮件扩充(MIME)。

数据组件400定义了组件应用程序302使用的数据实体。数据实体的实例包括订单、用户和财务往来。数据组件400定义了描述数据实体所需要的信息和信息的表达格式。例如，数据组件400可以定义订单，包括订单的数字格式的唯一标识符、字符串格式的选项列表、日期时间格式的订单创建时间、字符串格式的订单状态以及根据另一数据组件400的定义的格式的下订单的用户。因为数据单元通常通过消息来传输，所以数据组件400经常保持在数据库中。可以由应用程序设计员动态地生成或定义数据组件400。

消息组件404定义了组件应用程序302和例如网络服务的外部系统进行通信时使用的消息的格式。例如，一种消息组件404可以描述例如但不限于用于下订单的消息，包括订单的唯一标识符、订单的状态和与订单相关的注释。使用结构化定义语言编写的消息组件404的定义可以唯一地表示并且映射到WSDL消息，并能在运行时间被动态地生成。因此，能够从用于表达网络服务接口的定义语言(例如WSDL和BPEL)的标准网络服务元数据，动态地生成客户端应用程序消息的组件定义和相关的数据内容。在操作的上下文中定义网络服务消息，而且在组件应用程序302的定义中在消息组件404之间存在定义的相关性。可以使用预定义消息参数和/或通过分离的工作流组件406来实现这种相关性，如下文所定义。

呈现组件402定义了组件应用程序302通过用户界面202显示时的外观和行为。呈现组件402可以指定GU工屏幕和控制以及在用户使用元件界面202与组件应用程序302进行交互时要执行的动作。例如，呈现组件402可以定义屏幕、标记、编辑框、按钮和菜单以及当用户在编辑框中输入或按下按钮时要采取动作。多数网络服务的消费者使用网络服务操作结果的可视化呈现，因此在他们的设备100上提供了能够显示用户界面屏幕的运行时间环境。

可以认识到，在上述客户端组件应用程序302定义寄主模型中，呈现组件402可以根据客户端平台和设备100的环境而变化。例如，在一些情况下，网络服务消费者不需要可视化呈现。组件应用程序302的组件400、402、404、406的应用程序定义能够被寄主在元数据储存库700的网络服务登记中，作为具有针对多种预定义客户端运行时间的一组平台专用呈现组件402描述符的平台中立数据400、消息404、工作流406的组件描述符包(bundle)(即，特殊组件构架206-见图2)。当发出发现或安装(install)请求消息时，客户端类型应该被指定为该请求消息的一部分。为了不在为设备102的不同客户端平台而封装组件应用程序302的同时复制数据、消息和工作流元数据，可以将应用程序定义寄主在应用程序服务器108上，例如作为与不同组的呈现组件403a、403b、403c相链接的平台中立组件定义包，表示设备102中不同的支持用户界面202。还可以认识到，可以在不明确地支持特殊设备102的情况下使用标准呈现组件402，从而至少提供了缩减组的呈现特性。当用户发现或下载请求消息时，验证设备102的客户端运行时间类型，并且构造合适的包，用于由网络服务器106在网络104上传递给设备102。对于那些网络服务消费者，客户端应用程序302可以包含通过工作流组件406与数据400以及消息404组件相链接的选定的呈现组件403a、b、c，从而提供定制的组件应用程序302。

组件应用程序302的工作流组件406定义了在要执行动作时发生的处理，所述动作是例如上述呈现组件402指定的动作，或者是当消息到达时要执行的动作。工作流组件406定义了呈现工作流和消息处理。以元数据或编程语言或例如欧洲计算机制造商协会脚本(ECMA)的脚本语言将工作流组件406编写为的一系列指令，并且可以将其编译为本机代码并由应用程序容器300执行，如上所述。工作流组件406的实例可以是给数据赋值、操作屏幕或发送消息。工作流组件406支持消息之间的相关性，并且定义应用程序流，作为在其它组件400、402、404上操作的一组规则。

脚本语言的其它一些实例包括Perl、Rexx、VBScript、JavaScript和Tcl/Tk。脚本语言通常是指令语言，用于操作、定制和自动操作例如设备102的现有系统的工具程序。在这种系统中，通过用户界面202(见图2)，有用的功能已经可供使用，并且脚本语言是向程序控制展示该功能的机制。这样，设备1002提供对象的寄主运行时间环境和构成脚本语言能力的工具程序。

再次参考图3，一旦在通信设备102上供应了应用程序302的组件400、402、404、406，那么它们就被赋予了通过组件构架206中的应用程序容器300来访问预定义组的构架服务304的能力。构架服务304包括通信服务306、呈现服务308、持久性服务310、访问服务312、供应(provisioning)服务314和实用服务316。通信服务306管理组件应用程序302和外部资源之间的通信，呈现服务308管理当组件应用程序302输出在用户界面202的输出设备(见图2)上时的表示。持久性服务310允许组件应用程序302在设备基础设施204的存储器模块210(见图2)中存储数据。访问服务312为组件应用程序302提供了对通信设备102上存在的其它软件应用程序的访问。供应服务314管理通信设备102上的软件应用程序的供应。应用程序的供应可以包括请求和接收新的和更新的组件应用程序302、配置组件应用程序302来访问通过网络104可访问的服务、修改组件应用程序302和服务的配置以及去除组件应用程序302和服务。实用服务316用于完成多种一般任务，例如执行将字符串转变为不同格式的数据操作。

可以认识到，通信设备102的构架服务304能够为组件应用程序302提供包括上述服务的功能。结果，组件应用程序302能够访问通信设备102的功能而不需实现它。与由开发者以本机代码来编程API调用的所有服务请求或服务的普通应用程序不一样，组件定义400、402、404和工作流406使用如XML的结构化定义语言和例如ECMAScript的指令集来描述服务请求。XML提供了应用程序用户界面202、持久性存储和与网络服务的通信的非过程性定义，而ECMAScript提供了过程性的组件链接。客户端运行时间环境将这些定义400、402、404解释为所支持服务的本机调用。

应用程序容器300可以被称为客户端应用程序302的智能寄主容器，并且可以负责分析消息元数据和更新存储器模块210中的元数据的表示。

在本实施例中，设备运行时间提供了智能软件构架或容器，用于提供一组基本服务来管理和执行典型的应用程序行为，包括如上所述的数据存储、消息收发、屏幕导航和显示。

通过使用元数据定义的应用程序来引入智能容器的概念，构成无线环境复杂性的负担从应用程序转移到智能容器。因此，应用程序开发者要解决的主要复杂性是在应用程序和容器之间清楚地定义契约，以确保期望的功能。

智能容器运行元数据定义的应用程序，并维持这些应用程序自身的内部表示。同样，从智能容器的观点来看，应用程序以两种格式被理解：应用程序定义和应用程序内部表示。下面将对这两种格式进行描述，包括负责提供基于有效元数据的执行模型的设备运行时间的细节。

应用程序定义是一种格式，用于使用高度结构化的、并向智能容器提供关于需要怎样执行应用程序的清楚指令的定义好的标准格式向外公布应用程序。应用程序定义包括一组共同包括应用程序的组件的定义。这些定义是声明性的并以定义好的、结构化语言(例如XML)的方式表示。此外，为了定义定制的、复杂的应用程序逻辑，有时需要使用嵌入在元数据定义中的或分离地附加在元数据定义上的脚本语言(或编码)序列。

如上所述，应用程序定义包括数据定义、屏幕定义、消息定义和工作流定义。只作为示例目的，将参考图6至16进一步描述这些定义的实例。

应用程序内部表示是在运行时间智能容器内部的应用程序的格式，包括使用应用程序定义而特别构造的可执行元数据。可执行元数据包括在智能容器内运行的所有应用程序组件的内部表示，包括它们的内部关系。可执行元数据取决于智能容器的实施方式。

作为应用程序及其智能容器之间的契约的一部分，设备运行时间负责根据包括应用程序内部表示的应用程序组件的元数据来构造有效模型。因此，设备运行时间根据应用程序元数据，为每个应用程序构造了数据模型、屏幕模型和通信模型。

参考图5，通过数字500示出了应用程序的设备运行时间环境的示例。设备运行时间环境500包括数据管理器502、屏幕管理器504、通信服务506、用户界面(UI)服务508和脚本解释器510。设备运行时间环境500还与应用程序存储器512以及外部应用程序514进行通信。应用程序存储器512是用于存储应用程序定义和应用程序数据的设备储存库。外部应用程序514是通过有线或无线连接在设备外操作的应用程序。

数据管理器502管理应用程序的数据模型503以及代表应用程序的应用程序数据。

数据模型503包括用于每个数据组件定义的内存模板、关于数据组件关系和层次以及持久性的智能、以及需要通知数据改变的外部API的引用(reference)。例如使数据关联，使得当一个变量改变时，自动地更新其它需要更新的变量。此外，不同的数据可以要求不同等级的持久性。

数据管理器502使用数据模型503，用于应用程序数据操作(包括创建、更新、删除)、数据持久性和外部数据访问。

屏幕管理器504是管理屏幕模型505的服务。屏幕模型505包括针对每个屏幕组件定义的内存模板和智能模型，用于处理UI事件并导航和着色由屏幕组件中定义的声明性动作专门构造的屏幕。屏幕模型505还包括对触发自动屏幕刷新的输入消息的引用，和对在UI事件处理和条件控制中使用的脚本序列的引用。屏幕模型505管理显示给用户的屏幕表示509。

屏幕管理器504处理条件控制和布局的建模，并且根据从UI服务508接收到的事件来连续地更新屏幕模型505。屏幕管理器504使用屏幕模型505来为应用程序屏幕的外观着色、建立屏幕导航路径以及处理UI事件。

UI服务508提供了设备的本机UI构架中的屏幕表示的可视化。UI服务508还向屏幕管理器504传达用户事件。

通信服务506管理应用程序的通信模型507，并处理所有应用程序通信和消息处理。由于无线应用程序的性质，在本实施例中使用的通信模型507是异步的。通信模型507包括针对包含消息层次的每个消息定义的内存模板。通信模型507还包括与映射到数据组件或数据字段的消息、消息安全性和可靠性相关的智能、以及对处理输入消息的脚本序列的引用。因此，通信模型507描述了应用程序启动或能够接收和处理的一组消息。

通信服务506使用通信模型507来实现应用程序与其它无线或有线应用程序的通信需要，不管这些应用程序是在设备内部还是外部。

脚本解释器510执行应用程序的脚本部分，例如ECMAScript等等。脚本解释器510通过与屏幕管理器504的交互能够操作屏幕模型505，通过与数据管理器502的交互能够操作数据模型503，并通过与通信管理器506的交互能够操作通信模型507。

下面大致描述设备运行时间的操作。当应用程序上载到设备时，利用应用程序定义来呈现设备运行时间。设备运行时间可以在此时构造应用程序内部表示，或者推迟该操作，直到接收到执行应用程序的请求为止。因此，设备运行时间能够以“原始”的格式(即应用程序定义)来寄主应用程序，或以“可执行”的格式(即应用程序内部表示)来寄主应用程序。

因此，可以看出，设备运行时间执行根据组件的元数据定义而构造的基于模板的范型码(generic code)，而不是预编译的无线应用程序的可执行代码。

此外，设备运行时间能够以混合的执行模式执行。在混合执行模式中，设备运行时间提供了在执行模式和解释模式之间进行切换的能力。

在执行模式中，设备运行时间提供了执行环境，来运行本机代码的应用程序内部表示和特殊脚本指令。如上所述，从应用程序定义中特别地构造可执行元数据形式的应用程序内部表示。此外，使用全局符号库，从脚本解释器重定向相关联的脚本指令。就是说，在本机环境下，对脚本的预定义全局符号执行了代理执行。

此外，设备运行时间能够切换到解释模式来执行更复杂的功能。就是说，当执行应用程序元数据不足以实现期望的复杂性时，运行时间切换到解释模式来运行脚本。下文描述的图6至23提供了通过元数据或脚本专有地描述的组件定义和逻辑流的几个实例。

参考图6，通过数字600主要示出了应用程序定义的数据定义的XML部分的示例。数据定义描述了应用程序使用的数据组件，包括数据组件的持久性机制。数据组件可以包含基元字段，或可以指其中定义的其它数据组件。在图6显示的实例中，所示数据组件被命名为“Race”并要求持久性。数据组件包括多个变化类型的字段和复杂性。例如，字段名称“description”是字符串，而字段名称“horses”作为另一个被命名为“Horse”的组件的引用。

参考图7，通过数字700主要示出了应用程序定义的屏幕定义的XML部分的示例。屏幕定义描述了所有应用程序屏幕、它们相关联的布局、菜单选项、控制和屏幕着色元数据。在这个特殊的实例中，屏幕组件的名称是“scrLogin”且标题是“Login”。屏幕组件具有数据组件“Player”作为参数且不表示对话框。屏幕组件包括两个标记和两个编辑框。

第一标记被命名为“ebPlayNamelbl”并具有文本值“PlayerName：”。第一标记与第一编辑框相关联，第一编辑框被命名为“ebPlayerCode”并具有和参数“Player”的“name”属性相关联的值。该编辑框允许用户输入玩家的名字。

相似地，第二标记被命名为“ebPlayerNamelbl”并具有文本值“Player Code：”。第二标记与第二编辑框相关联，第二编辑框被命名为“ebPlayerCode”，并具有和参数“Player”的“code”属性相关联的值。该编辑框允许用户输入与名字相关联的代码或口令。两个编辑框的readOnly属性都被设置为假，以允许用户输入数据。

屏幕组件还包括三个菜单项。第一菜单项被命名为“regPlayer”并具有对应的标记“Register New Player”。该菜单项允许用户导航至被命名为“scrRegisterNewPlayer”的屏幕组件来注册新玩家。

第二菜单项被命名为“loginPlayer”并具有对应的标记“Login”。该菜单项允许用户通过访问pblock“2”来登录到应用程序。在本实施例中，pblock是通过元数据或脚本声明性地描述的可重复使用的“工作流”代码。Pblock“2”描述了与用户登录相关联的工作流。

第二菜单项被命名为“logout”并具有对应的标记“Logout”。该菜单项允许用户通过访问pblock“3”来从应用程序注销。在本实例中，pblock“3”描述了与用户注销相关联的工作流。

可以看到，运行时间环境可以理解诸如注销、菜单、标记、编辑、名称、值、readOnly、动作和条件之类的术语，程序员不需要提供详细的编程技术以便实现期望的功能。

参考图8，通过数字800主要示出了应用程序定义的消息定义的XML部分的示例。消息是输入或输出的，并包括简单的或复杂的字段的列表。本实例示出了被命名为“inViewingReq”的输入消息的定义。每个消息字段描述了期望作为消息的一部分的数据的类型，并将数据映射到可应用的本地应用程序组件。例如，消息具有字段名称“requestor”。与该字段名称相关联的数据被映射到组件“Agent”中的字段“name”。

此外，可以通过元数据专门声明性地表示应用程序定义的应用程序逻辑。应用程序逻辑包括数据操作、动态屏幕的屏幕着色、UI事件处理和声明性消息处理。

图9a至9c示出了一些声明性数据操作的实例，包括将数据映射到智能UI控制、将数据作为参数传递给屏幕或脚本序列以及将消息映射到数据。

参考图9a，通过数字900主要示出了将数据映射到智能UI控制的实例。UI控制通过声明性语句被限制到显示的或相关联的数据组件。当UI控制的值改变时，下层(underlying)数据将会改变，反之亦然。在这个实例中，被命名为“chClients”的单选按钮呈现给用户。该特定单选按钮被映射到命名为客户端的组件。因此，当用户改变输入时，映射到输入的数据发生改变。

参考图9b，通过数字930主要示出了将数据作为参数传递给屏幕或脚本序列的实例。根据图7所述，数据组件“Player”作为参数被传递给屏幕。通常，将数据作为参数传递给屏幕、脚本序列或自动地映射到消息的数据组件是声明性动作的所有竞争者。

参考图9c，通过数字960主要示出了将消息映射到数据的实例。在本实例中，当输入消息具有名称“inPropertyInfo”时，输入消息被映射到命名为“ProperyInfo”的数据组件。当消息定义直接映射到数据时，设备运行时间具有预定义的指令：当接收到的这种消息时，设备运行时间动态地更新或创建数据，而不需附加的处理。

参考图10，通过数字1000主要示出了动态屏幕的声明性屏幕着色的实例。声明性地指定了值和外观能够动态地改变的条件控制。在本实例中，“Canada”和“USA”是用户可能的选择。取决于用户的选择，动态地着色屏幕来显示加拿大的省或美国的州，作为用户其后的选择。使用元数据定义的条件控制，屏幕的外观和行为遵从设备运行时间所管理的运行时间准则。

参考图11，通过数字1100主要示出了声明性UI事件处理的实例。在本实例中，声明性地指定了作为用户事件结果的屏幕导航。作为选择菜单项“Client Details”的结果，设备运行时间的屏幕管理器被命令给下一屏幕“scrClientInfo”着色。相似地，如果选择菜单项“Client Workbook”，设备运行时间的屏幕管理器被命令给下一屏幕“scrClientWrbk”着色，并且如果选择菜单项“New Client”，设备运行时间的屏幕管理器被命令给下一屏幕“scrNewClient”着色。

图12a和12b示出了声明性消息处理的实例。在这些实例中，示出了导致数据更新和屏幕刷新的输入消息处理。

参考图12a，通过数字1200主要示出了声明性数据更新的实例。输入消息中的字段被直接映射到相应的数据。当设备接收到这种消息时，设备运行时间自动地更新数据而不需附加的指令。在本实例中，如果接收到标题为“inMyListing”的消息，则自动地将标题为“forClient”的消息字段映射到数据组件“Client”的属性“name”。

参考图12b，通过数字1250主要示出了声明性屏幕的刷新。在本实例中，当接收到的消息时刷新屏幕。因此，可以将受消息影响而发生的数据改变指示给用户。在本实施例中，当接收到“inPropertyInfo”和“inPropertyStatusChange”消息时，刷新屏幕。

上述声明性示例屏幕是元数据在描述应用程序逻辑中占主要地位的几个实例。其它实例对本领域的技术人员是显而易见的。因此，设备运行时间能够将整个应用程序变换为可执行的元数据来执行。

当应用程序逻辑比元数据能够处理的更加复杂时，应用程序定义使用嵌入在组件元数据中的或者与组件元数据分离地定义的脚本序列来进行重用。下面是通过脚本实现应用程序逻辑的几个实例。

参考图13，通过数字1300主要示出了数据操作的脚本的实例。本实例中的脚本根据传递参数“propertyinfo”来对数据进行修正。利用传递参数“propertyinfo”的相应属性来更新组件“outPropertyStatusChange”的属性“propID”、“status”和“price”。

参考图14，通过数字1400主要示出了屏幕着色的脚本的实例。本实例中的脚本根据传递参数“race”、“horse”和“bet”来对屏幕上的不同单元进行着色。如果“bet”参数是非空的，则通过使用“bet”参数的相应属性来着色屏幕上的适当属性。如果“bet”参数是空的，则通过使用“race”和“horse”参数的相应属性来着色屏幕上的适当属性。

参考图15，通过数字1500主要示出了受脚本影响的屏幕导航的实例。在本实例中，屏幕着色包括命名为“btnDone”的按钮。如果用户单击这个按钮，则实现图13所示的命名为“ahStatusChange”的脚本。除了数据着色以外，如上所述，图13中的脚本使用参数“propertyInfo”的数据来着色屏幕组件“scrPropDetails”。

此外，图15和13示出了受脚本影响的消息发送的实例。在如上所述着色屏幕组件“scrPropDetails”之前，发送与组件“outPropertyStatusChange”相关的消息。

参考图16，通过数字1600主要示出了通过脚本进行消息处理的实例。在本实例中，通过脚本操作输入消息中的数据并将其存储到相关联的数据组件中。如果在接收消息中不存在数据，则脚本向用户显示消息框。

上述脚本示例屏幕是脚本在描述应用程序逻辑中起主要作用的几个实例。其它实例对本领域的技术人员来说是显而易见的。

下面描述示出了根据本发明实施例的混合模式操作的几个设备运行时间的流程。参考图17，通过数字1700主要示出了执行初始屏幕加载的方法。在步骤1702处，从应用程序存储器512中提取应用程序屏幕，作为预先消化(pre-digest)应用程序元数据或XML。在步骤1704处，产生屏幕内部表示或屏幕模型505。在步骤1706处，屏幕模型505产生当前屏幕表示509，包括反映屏幕条件当前状态的所有字段值和设置，并将当前屏幕表示509传递给UI服务508来进行可视化。

参考图18，通过数字1800主要示出了执行声明性地定义的UI开始的数据改变的方法。在步骤1802处，将由用户改变编辑控制而触发的UI改变通信到屏幕模型505。在步骤1804处，映射到编辑控制的下层数据组件在数据模型503中使其值发生改变。同时，在步骤1805处，在屏幕表示509中更新数据改变。在步骤1806处，将数据改变保持(persist)在应用程序存储器512中。

参考图19，通过数字1900主要示出了执行通过脚本定义的UI开始的数据改变的方法。在本实例中，除了修改数据之外，UI开始的改变生成了输出消息。

在步骤1902处，将由用户改变编辑控制而触发的UI改变通信到屏幕模型505。屏幕模型505验证内部屏幕元数据表示上的事件的性质，并依靠通过应用程序XML完全指定的任意条件控制关系，检测作为UI事件的结果而受影响的主动或从属控制。在步骤1904处，屏幕模型检测到UI改变需要脚本处理并调用脚本解释器510。在步骤1906处，脚本解释器510根据解释的脚本来修改数据模型503。在步骤1908处，将数据改变保持在应用程序存储器512中。

因为在步骤1910处，作为UI改变的结果而执行的脚本产生了输出消息，脚本解释器510产生了输出消息并将消息通信给通信模型509。通信模型509根据需要将消息发送到外部应用程序514。

在步骤1912处，脚本解释器510修改按照脚本指定的屏幕模型505。相应地，在步骤1914处，屏幕模型产生了更新的屏幕表示509，在步骤1916处将更新的屏幕表示509传递给UI服务508来实现可视化。

参考图20，通过数字2000主要示出了执行声明性地定义的屏幕导航的方法。在步骤2002处，用户交互导致UI的改变。因此，UI事件被通信到屏幕模型505。在步骤2004处，屏幕模型505通过可执行元数据检测到这是屏幕导航事件，并产生要显示的新屏幕的屏幕表示。在步骤2006处，屏幕表示被传递给UI服务508来进行可视化。

参考图21，通过数字2100主要示出了执行由脚本定义的屏幕导航的方法。在步骤2102处，用户交互导致UI的改变。因此，UI事件被通信到屏幕模型505。在步骤2104处，屏幕模型确定UI事件涉及脚本调用，并将控制传递给脚本解释器510。在步骤2106处，脚本解释器510执行脚本，所述脚本命令屏幕模型505产生新的屏幕表示。在步骤2108处，屏幕模型505按照脚本解释器510的需要来产生新的屏幕表示509。在步骤2110处，屏幕表示509被传递给UI服务510来进行可视化。

参考图22，通过数字2200主要示出了根据声明性地定义的已接收消息来修改数据和更新UI的方法。在步骤2202处，通信服务506接收来自外部应用程序514的输入消息。在步骤2204处，通信服务506确定消息被映射到数据，因此将控制传递给数据管理器502。数据管理器502更新数据模型503，并将新数据保持在应用程序存储器512中。

在步骤2206处，通信服务506触发了屏幕模型505的更新或屏幕刷新。在步骤2208处，屏幕模型505产生了新的屏幕表示509。在步骤2210处，屏幕表现509被传递给UI服务508来进行可视化。

参考图23，通过数字2100主要示出了根据由脚本定义的接收消息来修改数据和更新UI的方法。在步骤2302处，通信服务506接收来自外部应用程序514的输入消息。在步骤2304处，通信服务506确定要通过脚本来处理消息，因此将控制传递给脚本解释器510，脚本解释器510执行脚本来处理消息。

在步骤2306处，脚本解释器按照解释脚本的需要来更新数据模型503，并将新数据保持在应用程序存储器512中。在步骤2308处，脚本解释器按照脚本所指定地修改屏幕模型505。在步骤2310处，屏幕模型505产生新的屏幕表示509。在步骤2312处，屏幕表示509被传递给UI服务508来进行可视化。

因此可以看出的是，提供具有更大的应用程序执行能力的设备运行时间不仅允许以组件的格式编写应用程序(如这里所述)，还便利了混合模式的执行。因此，当应用程序要求不能仅通过运行可执行元数据来实现的复杂功能时，应用程序可以使用脚本组件，由此切换到解释模式。然后脚本解释器将产生的可执行元数据通信到相应的组件模型来执行。

尽管已经参考优选实施例描述了本发明，本领域的技术人员可以理解到，在不脱离本发明的精神或所附权利要求的范围的情况下可以进行改变。