自动用户界面对象变换和代码生成
背景
客户机-服务器体系结构是在被称为服务器和客户机的两个基本实体之间的、为应用程序划分计算任务和工作负载的分布式应用结构。服务器是资源或服务的提供方。客户机是资源或服务的请求方。服务器是运行与客户机共享其资源的一个或多个服务器程序的物理或逻辑设备。客户机是一般不共享其任何资源,但从服务器请求内容或服务功能的物理或逻辑设备。客户机和服务器通常在分开的硬件上通过计算机网络进行通信。然而,在某些情况下,客户机和服务器两者可驻留在同一系统中。客户机因此发起与等待传入请求的服务器的通信会话。
客户机-服务器体系结构的一种形式是多层体系结构,通常被称为n层体系结构。n层体系结构是其中应用程序的某些方面被划分成多个层的客户机-服务器体系结构。例如,使用中间软件在用户和数据库之间提供数据请求的应用采用多层体系结构。n层应用体系结构提供供开发商创建灵活且可重复使用的应用的模型。通过将应用分割成多个层,开发商仅需要修改或添加特定层(或层次),由此避免了重写整个应用的需要。
在开发和修改应用程序时,n层体系结构提供许多优点。然而,在为存在大量客户机的基于web的环境实现n层体系结构时存在困难。每一客户机可利用不同的web技术,包括不同的web浏览器、web服务和web应用。此外,web技术被设计成与许多不同类型的底层硬件和软件体系结构一起工作,包括具有不同输入/输出(I/O)组件、形状因素、功率要求、处理能力、通信能力、和存储器资源等的各种各样的设备。因此,可能难以跨这许多的异构设备和体系结构实现一个或多个层。此外,应用程序的web版本可能与应用程序的非web版本不兼容,由此创建了对各自的分开的软件体系结构的需要。本发明的改进正是针对这些和其他缺点而被需要的。
概述
提供本概述是为了以简化的形式介绍将在以下具体实施方式中进一步描述的选择的概念。本概述并非旨在标识所要求保护的主题的关键特征或必要特征,也不旨在用于帮助确定所要求保护的主题的范围。
各个实施例一般涉及适用于执行不同类型的应用程序(诸如,例如商用业务线应用程序)的客户机-服务器体系结构。某些实施例尤其涉及具有应用程序的多个层(或层次)的n层客户机-服务器体系结构,包括至少一个呈现层。在一个实施例中,例如,3层客户机-服务器体系结构可包括至少一个呈现层,该呈现层使用以下技术来实现:该技术被设计成在使解释运行时引擎应用适于与许多不同类型的客户机一起操作时,分离并增强对用户事件的图形用户界面(GUI)渲染。
在一实施例中,例如,一种装置可包括被安排成执行服务器应用的逻辑设备。该服务器应用可包括用于从接收到用户事件性质集合中生成不依赖于图形用户界面(GUI)的对象的解释运行时引擎或其他元件。不依赖于GUI的对象被提供给模板处理器,以创建新的依赖于GUI的对象,该依赖于GUI的对象可被返回给客户机应用进行渲染。对其他实施例也予以描述并要求保护。
通过阅读下面的详细描述并参考相关联的附图,这些及其他特点和优点将变得显而易见。应该理解,前面的概括说明和下面的详细描述只是说明性的,不会对所要求保护的各方面形成限制。
附图简述
图1A示出了常规的桌面应用体系结构。
图1B示出了常规的2层应用体系结构。
图1C示出了常规的3层应用体系结构。
图2示出了根据一个实施例的具有多个客户机和客户机适配器的增强式n层客户机-服务器体系结构的框图。
图3示出了根据一个实施例的具有单个客户机和客户机适配器的增强式n层客户机-服务器体系结构的框图。
图4示出了根据一个实施例的具有客户机和客户机适配器的不依赖于图形用户界面(GUI)的对象的增强式n层客户机-服务器体系结构的框图。
图5示出了根据一个实施例的增强式n层客户机-服务器体系结构的第一逻辑流程。
图6A示出了根据一个实施例的不依赖于GUI的对象的逻辑示图。
图6B示出了根据一个实施例的特定的不依赖于GUI的对象的逻辑示图。
图7示出了根据一个实施例的增强式n层客户机-服务器体系结构的第二逻辑流程。
图8A示出了根据一个实施例的用于处理表示GUI对象布局的模板的增强式n层客户机-服务器体系结构的框图。
图8B示出了根据一个实施例的从代表性GUI对象布局生成的第一用户界面视图。
图8C示出了根据一个实施例的从代表性GUI对象布局生成的第二用户界面视图。
图9示出了根据一个实施例的模板处理系统的第三逻辑流程。
图10示出了根据一个实施例的适用于增强式n层客户机-服务器体系结构的计算体系结构的实施例。
图11示出了根据一个实施例的适用于增强式n层客户机-服务器体系结构的通信体系结构的实施例。
详细描述
各个实施例一般涉及适用于执行不同类型的商用业务线应用程序的客户机-服务器体系结构。某些实施例尤其涉及增强式n层客户机-服务器体系结构,其中n是表示任何正整数的变量。增强式n层体系结构可包括应用程序的多个层(或层次),包括至少一个呈现层。在一个实施例中,例如,增强式n层体系结构可被实现为包括至少一个呈现层、一应用处理层、和一数据管理层的3层体系结构。呈现层一般实现用户界面逻辑,诸如处理输入/输出操作。应用处理层一般实现应用或业务逻辑,诸如根据一组应用规则来处理数据。数据管理层一般实现数据存储和访问,诸如定义数据模式、存储数据、和处理数据查询等。
增强式n层客户机-服务器体系结构可包括使用以下技术来实现的至少一个呈现层:该技术被设计成便于使用解释运行时引擎来分离并优化应用中的GUI渲染和用户事件。它允许使来自2层的基于客户机-服务器的体系结构的解释运行时引擎应用适合于主存的3层环境,同时减少对该解释运行时引擎应用的改变。
图1A、1B和1C以背景的方式示出了应用开发的三个常规体系结构,以强调增强式n层客户机-服务器体系结构的各个实施例的优点。图1A示出了常规的桌面体系结构。图1B示出了常规的2层体系结构。图1C示出常规的3层(或n层)体系结构。
图1A是桌面体系结构100的示例,其中,应用程序112的所有部分(或应用层)是在客户机计算机110(例如,台式计算机)上实现的。应用程序112可包括实现例如用户界面(UI)逻辑、业务逻辑和数据访问逻辑的各种应用层。应用程序112可存储应用数据,并从也被实现在客户机计算机110上的数据库114中访问应用数据。
图1B是2层体系结构120的示例,其中数据库114现在在客户机计算机10的远程。在2层体系结构120中,应用程序112及其组成应用层仍存在于客户机计算机110上。然而,数据库114已从客户机计算机110被移动到了数据库服务器116。运行在客户机计算机110中的应用程序112经由数据库应用程序接口(API)向与数据库114通信地耦合的数据库服务器116发送对数据的请求。所请求的数据随后被返回给在客户机计算机110上执行的应用程序112。
图1C是3层体系结构130的示例。在3层体系结构130中,应用程序112可被划分成在各自的客户机计算机110和服务器122上执行的分布式应用程序112、124。应用程序112可以实现具有UI逻辑的应用层。应用程序124可以实现具有业务和数据库访问逻辑的应用层。在客户机计算机110中运行的应用程序112向正在执行应用程序124的服务器122发送数据。应用程序124可随后执行业务逻辑,并向与数据库114通信地耦合的数据库服务器116发送对数据的请求。所请求的数据和所执行的业务逻辑的结果随后被返回给应用程序112,并被渲染在客户机计算机110中。应注意,数据库服务器116可以与服务器122位于一处,或者是服务器122的一部分。换言之,硬件体系结构可以使得单个服务器122用作应用和数据库服务器两者。2层体系结构和3层(或n层)体系结构之间的区别因素是应用层中的一些或许多被移出客户机计算机110,并被分布在一个或多个其他服务器116、122中。
在开发和修改应用程序时,n层体系结构(诸如,3层体系结构130)相对于2层体系结构120来说,可以提供许多优点。例如,单个层可以被修改或添加,而不会导致对整个应用程序的完全重写。然而,在为存在大量客户机的基于web的环境实现n层体系结构时存在困难。每一客户机可利用不同的web技术,包括不同的web浏览器、web服务和web应用。此外,web技术被设计成与许多不同类型的底层硬件和软件体系结构一起工作,包括具有不同输入/输出(I/O)组件、形状因素、功率要求、处理能力、通信能力、和存储器资源等的各种各样的设备。由此,可能难以跨这许多的异构设备和体系结构来唯一地实现给定应用层(诸如,呈现层),而无需广泛定制呈现层以适合于每一客户机的唯一配置。此外,应用程序的web版本可能与应用程序的非web版本不兼容,由此创建了对各自的分开的软件体系结构的需要。
在各个实施例中,增强式n层体系结构提供了一框架,该框架使得能够将2层客户机-服务器应用体系结构迁移到3层应用体系结构,该3层应用体系结构将瘦客户机用于应用程序的呈现层。在一个实施例中,例如,每一客户机设备可以实现web客户机形式的瘦客户机。Web客户机通常指用web技术实现的瘦客户机应用,诸如例如在客户机计算机中操作的web浏览器。它也可以指将浏览器增强为支持来自网站或服务器的定制服务的插件和帮助应用。在此对web客户机的任何引用也可以指web浏览器的功能。
图2示出了客户机-服务器系统200。在一个实施例中,客户机-服务器系统200可以包括增强式n层客户机-服务器系统。增强式n层客户机-服务器系统可以将应用程序划分成多个层,包括至少一个呈现层。呈现层可以使用以下技术来实现:该技术被设计成便于使用解释运行时引擎来分离并优化应用程序中的GUI渲染和用户事件。它允许使来自2层的基于客户机-服务器的体系结构的解释运行时引擎应用适合于主存的3层环境,同时减少该解释运行时引擎应用所需的改变。
如之前参考图1A所描述的,许多应用遵循2层应用体系结构,在2层应用体系结构中,应用被组织成两个相互关联的组件——数据库服务器和客户机应用。数据库服务器可以主控系统和伴随数据以及扩展业务逻辑,该扩展业务逻辑允许服务器处理较繁重的操作中的一些,这些操作在客户机处执行起来将非常耗时。同时,客户机应用可以执行以下功能:分发UI、提供数据项验证、及渲染报告或其他功能。
在图2中示出的说明性实施例中,客户机-服务器系统200可包括服务器202和多个客户机204、206。当在不同的硬件平台上被实现时,服务器202和客户机204、206可以经由网络250彼此通信。当在同一硬件平台上被实现时,服务器202和客户机204、206可以经由合适的总线技术和体系结构彼此通信。虽然出于简洁的目的,图2中仅示出了单个服务器202和两个客户机204、206,但应理解,客户机-服务器系统200可以实现如给定实现所需的任何数量的服务器和客户机。各实施例不限于该上下文。
在一个实施例中,服务器202可以包括实现服务器应用210的电子设备。服务器应用210可以包括任何类型的服务器应用,诸如商用业务线应用。商用业务线应用的示例可包括但不限于会计应用、企业资源规划(ERP)应用、顾客关系管理(CRM)应用、和供应链管理(SCM)应用等。这些商用业务线应用有时被称为“中间层”应用,因为它们一般由商用企业网络中的服务器或服务器阵列来执行,而不是由诸如台式计算机的客户机设备来执行。特定示例可包括由华盛顿州雷蒙德市的微软公司开发的Dynamics GP。Microsoft Dynamics GP是商用会计软件应用。商用业务线应用的另一特定示例可包括由华盛顿州雷蒙德市的微软公司开发的Microsoft AX。Microsoft Dynamics AX是商用ERP软件应用。然而,各实施例不限于这些示例。
当服务器202是服务器应用210的执行代码时,服务器202形成解释运行时引擎212。解释运行时引擎212实现服务器应用210的多个应用层,在客户机-服务器系统200中被称为应用逻辑214、数据库逻辑216和服务器呈现逻辑218。服务器应用210可以经由通过网络250以信号或消息的形式从客户机204、206处接收到的控制指示来控制和操作。
在一个实施例中,客户机204、206各自可包括实现相应的web客户机230、240的电子设备。web客户机230、240各自可包括例如在相应的客户机204、206上执行的web浏览器的实例。web浏览器还可包括被设计为增强web浏览器以支持来自服务器202的定制服务的插件、web应用和帮助应用。此处对web客户机230、240的任何引用也可以指web浏览器的功能。
客户机204、206可以包括相应的客户机适配器232、242。客户机适配器232、242中的每一个可被配置为与给定客户机204、206一起使用。通过这种方式,服务器应用210和解释运行时引擎212在被不同的客户机使用不同的web技术访问时不需要被修改。
客户机适配器232、242可包括相应的客户机呈现逻辑238、248。客户机呈现逻辑238、248可被设计成将用户界面元素或视图呈现在客户机204、206的输出设备(诸如例如数字显示器)上。客户机呈现逻辑238、248可被设计成根据为服务器应用210实现的分布式n层体系结构与服务器202上执行的服务器应用112的应用逻辑214、数据库逻辑216和服务器呈现逻辑218互操作。
客户机适配器232、242和相应的客户机呈现逻辑238、248可以与服务器呈现逻辑218互操作以允许经由不同的客户机204、206访问服务器应用210。每一客户机204、206可以将服务器呈现逻辑218的不同版本实现成相应的客户机呈现逻辑238、248,以适合于客户机204、206的特定配置。这可以在不必重写服务器呈现逻辑218,并且更重要地不必重写业务逻辑214和数据库逻辑216的情况下被实现。此外,服务器呈现逻辑218和客户机呈现逻辑238、248可以以减少网络250的通信流量和负载的方式进行交互,由此增加了速度和性能,同时减少了与通信延迟相关联的等待时间。
在各个实施例中,服务器呈现逻辑218和客户机呈现逻辑238、248可以以利用不依赖于图形用户界面(GUI)的对象260的高效方式来进行交互。不依赖于GUI的对象260允许诸如屏幕(例如,Microsoft Form)之类的GUI元素在桌面环境和web环境之间自由移动。不依赖于GUI的对象260允许服务器应用210作为后台中正等候可经由传统的OS表单或web客户机表单来接收的用户事件的服务来运行,并仍能执行脚本事件,而不管通过其来提交该对象的表单的类型。
除了可以影响应用逻辑事件的用户事件性质之外,不依赖于GUI的对象260还可包含可以影响客户机适配器232、242的依赖于GUI的渲染的用户事件和任何用户事件性质或其他类型的信息。不依赖于GUI的对象260由解释运行时引擎212生成并被发送到客户机适配器232、242,该不依赖于GUI的对象260基本上经由相应的客户机呈现逻辑238、248被渲染在客户机用户界面中。
图3示出了n层客户机-服务器系统300的特定实现。客户机-服务器系统300可包括服务器302和客户机304。服务器302可以表示例如参考图2描述的服务器202。客户机304可以表示例如参考图2描述的客户机204、206之一或两者。
在客户机-服务器系统300中示出的说明性实施例中,服务器302可以实现服务器应用310。在一个实现中,例如,服务器应用310可以使用Microsoft编程语言或其他合适类型的编程语言来被代码化。在被实现为Microsoft Dexterity应用时,服务器应用310一般可被划分成两个不同的元素。第一元素是解释运行时引擎312,该引擎提出应用环境的诸如与操作系统(OS)进行通信和经由文件管理器316来建立和管理与数据库320的连接之类的技术方面。第二元素是应用词典313,该应用词典主控应用逻辑315,诸如,应用规则、业务规则、表单、报告、资源、元数据以及使能对用户命令和输入的响应的应用代码。该体系结构将应用逻辑315与UI的样式改变和平台进步(诸如,例如平台OS的升级)隔离。
sanScript代码用于控制应用如何操作。SanScript代码一般被写在小片段或脚本中,这些小片段或脚本被附加到应用词典313中的对象,诸如字段、菜单、屏幕和表单。脚本在用户与该应用中的那个特定对象交互时被运行。例如,被应用于推送按钮的脚本将在用户点击该按钮时运行。
如图所示,客户机304可以包括web客户机330。web客户机330可以表示例如web客户机230、240之一或两者。web客户机330可以递送面向用户界面和用户交互的组件和服务集合,包括供与服务器应用310一起使用的用户输入和轻量用户界面控制。然而,为了实现到3层体系结构的平滑迁移,需要克服由web客户机体系结构的引入造成的多个技术挑战,以允许高效的web客户机界面。
在此描述的各实施例的目标是减少所需的对现有代码和GUI元数据的修改。为了解决前述挑战中的一些,各个实施例涉及用于将用户界面管理器318和OS渲染引擎322从解释运行时引擎312中解耦出来的技术。用户界面管理器318是控制给定GUI系统中的各个用户界面元素(诸如,GUI屏幕)的放置和外观的系统软件。OS渲染引擎322是用于显示内容的系统软件。解释运行时引擎312是服务器应用310的执行版本。
对表单(或屏幕)的使用是任何Microsoft Dexterity应用的核心成份。表单是用户将与服务器应用310进行交互的机制。当服务器应用310被实现成例如Microsoft Dexterity应用时,Microsoft Dexterity屏幕一般包括与对该屏幕的控制相关联的sanScript代码。sanScript代码响应于给出屏幕的预期功能和在脚本解释器314的指导下的控制(例如,保存事务、粘贴批处理)的用户事件而执行。
在服务器应用310的非web版本中,UI由用户界面管理器318管理,该用户界面管理器318进而与OS渲染引擎322通信以使实际的MicrosoftDexterity屏幕与之前由开发商布局的控制元素一起显示在显示屏上。
然而,为了促进向客户机-服务器系统300的web客户机3层体系结构的转变,可以将用户界面管理器318和OS渲染引擎322从解释运行时引擎312的功能中解耦出来。这允许web客户机332将用户界面管理器336和渲染引擎338的客户机版本实现在客户机304上。这还允许正在服务器302上执行的解释运行时引擎312生产供web客户机332使用的不依赖于GUI的对象360。伴随不依赖于GUI的对象360,经典的客户机可以继续提供典型的GUI屏幕(例如,Microsoft 屏幕),同时还允许客户机304的web客户机330提供同一屏幕的基于web的表示,而无须改变服务器应用310的任何底层应用逻辑315。
将用户界面管理器318和OS渲染引擎322从解释运行时引擎312中解耦出来允许屏幕(表单)在非web(例如,桌面或Win32)环境和web环境之间自由移动。随着用户界面管理器318和OS渲染引擎322被解耦,服务器应用310可以作为后台中等候可经由传统的Win32表单或web客户机表单来接收的用户事件的服务来运行,并仍能执行脚本事件,而不管通过其来提交该对象的表单的类型。
为了促进该解耦,服务器应用310的依赖于GUI的处理层和不依赖于GUI的处理层首先被分开。代替这两个层之间的直接通信,渲染和事件元数据使用不依赖于GUI的对象360来展示。除了可以影响应用逻辑事件的用户事件性质之外,不依赖于GUI的对象360还可以包含可以影响客户机适配器332的依赖于GUI的渲染的任何用户事件性质。不依赖于GUI的对象360随后被发送至(依赖于GUI的)客户机适配器332,该客户机适配器332被渲染在客户机304的显示器上的客户机用户界面屏幕中。某些客户机适配器332的实例可包括但不必限于Microsoft HTML、Win32GDI、.Net表单等。
图4示出了n层客户机-服务器系统400的特定实现。客户机-服务器系统400可包括服务器402和客户机404。服务器402可以表示例如参考图2、3描述的服务器202、302。客户机404可以表示例如参考图2、3描述的客户机204、206、304之一或全部。
在服务器402上,可存在包括解释运行时引擎412的服务器应用410,该解释运行时引擎412可负责执行一个或多个应用层,或与运行一个或多个应用层的其他组件耦合在一起。解释运行时引擎412还可包括脚本解释器414、文件管理器416和用户界面管理器418。脚本解释器414可以与文件管理器416和服务器用户界面管理器418通信。文件管理器416还可以与数据库420通信。
在客户机404上存在执行客户机适配器432的web客户机430。客户机适配器432可以包括用户界面管理器436和渲染引擎438,该渲染引擎438用于根据图2中示出的客户机呈现逻辑238、248将内容显示在客户机用户界面(诸如客户机用户界面)中。
图4可表示3层应用体系结构,其中某些应用层可以分布在服务器402和客户机404之间。例如,如图2所示,客户机呈现逻辑238和/或248可以驻留在客户机404上,而应用逻辑214和数据库逻辑216可以分布在服务器402上。图4中示出的体系结构已将用户界面管理器436和渲染引擎438的功能从服务器402上的解释运行时引擎412中解耦出来,并将该功能与客户机404上的客户机适配器432放置在一起。
在一个实施例中,解释运行时引擎412可包括脚本解释器414。脚本解释器414一般可被安排成响应于诸如但不限于保存事务或粘贴批处理的用户事件而执行脚本代码。脚本代码的实例可包括预先脚本、改变脚本、和粘贴脚本或其他类型的脚本。
在一个实施例中,解释运行时引擎412可包括文件管理器416。文件管理器416一般被安排成对数据库420中存储的文件执行文件管理操作。文件管理操作的示例可包括创建文件、打开文件、复制文件、移动文件、删除文件等。
在一个实施例中,解释运行时引擎412可包括用户界面管理器436。用户界面管理器436一般被安排成控制各个用户界面元素(诸如,屏幕元素)在实现给定GUI系统的用户界面内的放置和外观。
在操作中,用户可以经由web客户机430与客户机用户界面交互。web客户机430可以包括具有用于渲染基于web的内容的用户界面代码的web浏览器。web客户机430可以使用诸如HTML、XHTML和XML等各种web技术来实现。web客户机430的示例可包括但不限于由华盛顿州雷蒙德市的微软公司开发的Internet 或其他类型的web浏览器软件。
根据一实施例,在操作中,用户可以经由web客户机430与客户机用户界面交互,并可输入用户事件,这些用户事件可被客户机适配器432接收并处理。用户事件的示例可包括但不限于,将指针移动到某字段、悬停在某字段上、选择某字段、鼠标点击某按钮、填充文本字段及类似的操作。用户事件可以使用用户事件性质集合来定义。在一个实施例中,仅需将用户事件性质的改变从web客户机430发送到服务器应用410,而非将用户事件性质的完整集合从web客户机430发送到服务器应用410。该差别技术可以节约通信带宽并减少等待时间。
用户事件性质可以是向显示在用户界面布局中的用户界面元素(诸如字段、屏幕或图形对象)分配的任何属性。用户事件性质描述了相应用户界面元素的呈现样式或呈现格式的属性。用户事件性质可包括用户界面元素标识符(ID)、性质(例如,边界、字体、字体大小、字体颜色、背景、背景色、样式、右对齐、居中对齐、左对齐、单倍行距、和双倍行距等)和性质值(例如,假、真、0、1等)、或其他类型的信息。例如,GUI屏幕可具有标识符“Window001”,以及被设为假的可重设大小性质,这意味着用户无法在运行时为GUI屏幕重设大小。这些仅是一些示例,任何用户界面元素和用户界面性质可以按照给定实现的需要被实现。各实施例不限于该上下文。
web客户机430可以将消息450中的已改变的用户事件性质451的集合发送给服务器应用410。在服务器402上操作的用户界面管理器418将消息450中的已改变的用户事件性质451转发给脚本解释器414进行处理。服务器应用410可确保应用输入和应用状态在执行服务器应用410的任何应用逻辑之前是合适的。脚本解释器414可随后与具有对数据库420的访问的文件管理器416通信,如果对数据库420的访问是执行由从客户机404接收到的消息450中的已改变用户事件性质451得到的任何应用规则所必须的话。在执行了合适的应用逻辑后,解释运行时引擎412可以产生不依赖于GUI的对象452。不依赖于GUI的对象452可以包括经更新的用户事件性质454或其他信息。由服务器402实现的用户界面管理器418可以将不依赖于GUI的对象452连同任何经更新的用户事件性质454一起发送回客户机404。随后,客户机适配器432可通过客户机界面管理器436和渲染引擎438使用不依赖于GUI的对象452以及由服务器应用410生成并从服务器应用410接收的经更新用户事件性质454来更新之前渲染的图像。
上述实施例的操作可参考一个或多个逻辑流程来进一步描述。可以理解,除非另外指明,否则代表性的逻辑流程不一定要按所呈现的次序或者按任何特定次序来执行。此外,关于逻辑流程描述的各种活动可按串行或并行的方式执行。视给定一组设计和性能约束所需,逻辑流程可使用所述实施例的一个或多个硬件元件和/或软件元件或替换元件来实现。例如,逻辑流程可被实现为供逻辑设备(例如,通用或专用计算机)执行的逻辑(例如,计算机程序指令)。
图5示出了逻辑流程500的实施例。逻辑流程500可示出根据一个或多个实施例来执行的操作。例如,逻辑流程500可示出由web客户机430和/或服务器应用410来执行的操作。
在逻辑流程500中,在框502,用户与在客户机侧用户界面中执行的web客户机交互。例如,web客户机430可以接收从输入设备接收的一个或多个控制指示形式的用户输入,该用户输入影响渲染引擎438所呈现的用户界面中的一个或多个用户界面元素。用户输入可以与用户界面元素交互,从而引起用户事件。例如,用户可以选择GUI屏幕中呈现的表单上的字段,并修改该字段的值。
在逻辑流程500中,在框504,在其中执行的客户机适配器可以以与在服务器上执行的服务器应用兼容的方式来解释表示用户事件的控制指示。例如,由web客户机430执行的客户机适配器432可以以与服务器应用410类似的方式来解释用户事件。用户事件可以包括与在web客户机430上运行的用户界面的一个或多个用户交互,诸如但不限于,点击按钮、和填充文本字段等。
在逻辑流程500中,框504处的解释操作检查新输入的用户事件性质,以在菱形506处确定用户事件性质是否已改变成服务器应用应被通知到所需的程度。例如,客户机适配器432可以检查任何用户输入及受影响的用户界面元素的性质的相应改变,以确定用户事件性质是否已改变了超过某一阈值量。例如,悬停在某字段上以将该字段带入焦点可能不足以触发用户事件性质中的任何改变,而选择字段将足以通知服务器应用410。
在逻辑流程500中,在框508,在要求通知的那些情况下,客户机适配器可以将任何待处理的已改变用户事件性质发送给服务器应用。例如,客户机适配器432可以经由网络250将消息450中的已改变用户事件性质451发送至服务器应用410。在某些实施例中,客户机适配器432可以将消息450中的多个用户事件的已改变用户事件性质451的多个集合发送至在服务器402上执行的服务器应用410。该“批处理”发送可以以许多方式使用,包括在用户事件定时时帮助服务器应用410。例如,脚本解释器414可以安排执行各种脚本(例如,预先脚本、改变脚本、粘贴脚本等)的时间以确保服务器应用410的准确更新序列。批处理发送还可以通过跨网络250发送较少的消息450来减少通信开销。其他优点也存在,且各实施例不限于该上下文。
在逻辑流程500中,在业务逻辑事件在框512处被执行之前,在服务器上执行的运行时引擎可在框510处确保服务器应用的合适的输入/状态。例如,在服务器402上执行的解释运行时引擎412可以确保服务器应用410在执行任何应用或业务逻辑之前的合适的应用输入和应用状态。
在逻辑流程500中,在框514,将从业务逻辑的执行以及不依赖于GUI的对象得出的经更新用户事件性质传送回客户机适配器。例如,可以将从应用或业务逻辑的执行以及不依赖于GUI的对象452得出的经更新用户事件性质454从服务器应用410发送至web客户机430,以供传送回客户机适配器432。
在逻辑流程500中,客户机适配器可随后在框516处使用经更新用户事件性质以及不依赖于GUI的对象来更新客户机用户界面中的之前渲染的图像。例如,客户机适配器432可以接收不依赖于GUI的对象452,渲染引擎438可以使用经更新用户事件性质454和不依赖于GUI的对象452来更新客户机用户界面中的之前渲染的图像。
图6A示出了可如何使用来自服务器应用410的数据来为客户机适配器432创建不依赖于GUI的对象452的实施例。如之前所描述的,客户机适配器432可接收具有经更新用户事件性质454的不依赖于GUI的对象452。经更新用户事件性质454可包括不依赖于GUI的对象元数据602或其他信息。在一个实施例中,不依赖于GUI的对象元数据602可包括固定的或静态的元数据。经更新用户事件性质454还可包括性质/值集合604。固定/静态的不依赖于GUI的对象元数据602可以与不依赖于GUI的性质/值集合604组合以产生不依赖于GUI的对象606,该不依赖于GUI的对象606可以被客户机适配器432渲染在web客户机430中。
图6B示出了可如何使用图6A中展示的构造来创建特定的不依赖于GUI的对象452的实施例。经更新用户事件性质454可包括对象元数据612和性质/值集合614或其他信息。
经更新用户事件性质454可包括具有一个或多个用户界面元素的对象元数据612。在这个示例中,对象元数据612包括字段形式的三个用户界面元素,即已标记字段A、字段B和字段C。字段A、B和C中的每一个字段一般被示为具有边框的文本框,所示边框围绕分别包括短语‘字段A’、‘字段B’和‘字段C’的默认字体文本。
经更新用户事件性质454还可包括性质/值集合614。在一个实施例中,性质/值集合614可以以诸如具有一个或多个元组(或行)的表格的数据结构来实现,其中每一元组包括含用户界面元素的标识符、该用户界面元素的性质和该性质的值的属性(或列)。标识符、性质和值的表格可以对应于对象元数据612的字段。
在被组合在一起时,结果可以是不依赖于GUI的对象616。如在不依赖于GUI的对象616中示出的,字段A未从通用元数据版本改变,因为在性质/值集合614中其性质或值中的任何一个都没有被改变。字段B被示为没有其边框,因为在属性/值集合614中属性‘边框’被设为值‘假’。字段C中的文本被示为黑体字,因为在属性/值集合614中属性‘黑体’被设为值‘真’。对象616现在可被客户机适配器432的渲染引擎438渲染在客户机404上的web客户机430中。
图7示出了逻辑流程700的实施例。逻辑流程700可示出根据一个或多个实施例来执行的操作。例如,逻辑流程700可以示出由web客户机430和/或服务器应用410出于恢复已被破坏的客户机适配器432的目的而执行的操作。
在此描述的各实施例的另一好处是给定客户机404中的经渲染图像可在客户机适配器432被破坏的情况下被恢复。如果客户机适配器432被破坏,则包括各种依赖于GUI的对象452的经渲染图像也被破坏。然而,服务器应用410可以继续以不依赖于GUI的对象452的形式保持状态。如图7所示,用户可以与客户机侧用户界面中执行的web客户机430交互,以在框702处创建客户机适配器432的新实例,随后,客户机适配器432的新实例可在框704处与服务器应用410重新连接。在重新连接后,服务器应用410仍可维持所有不依赖于GUI的对象452的最后已知状态。在框706,所有不依赖于GUI的对象452的最后已知状态被传送回客户机404并被客户机404接收。随后,在框708,可以使所有不依赖于GUI的对象452的最后已知状态与客户机404的web客户机430同步。结果是可以使用服务器应用410所存储的信息来有效地恢复客户机适配器432的当前状态。
本公开至此已描述了可如何将渲染引擎438从解释运行时引擎412中解耦出来,以便创建不依赖于GUI的对象452,该不依赖于GUI的对象452可被渲染成用户界面视图,诸如Microsoft Form或Microsoft UI界面等。以下描述聚焦于可如何将不依赖于GUI的对象452变换成用户界面视图(诸如,例如Microsoft Windows Form或a Microsoft Silverlight UI)的经渲染图像。
根据一个实施例,系统400可以将由解释运行时引擎412生成的不依赖于GUI的对象元数据602变换成用户界面模版,同时将原始元数据代码作为主代码库来保留。不依赖于GUI的对象452包括渲染和事件元数据两者。如之前所描述的,不依赖于GUI的对象452可以从解释运行时引擎412或从可提供关于不依赖于GUI的对象452的细节的对象模型直接生成。
回想用户界面管理器418(解释运行时引擎412的一部分)仍被分配了处理UI事件的任务,而渲染引擎438被分配了将客户机404上的用户界面呈现给最终用户的任务。现在,解释运行时引擎412已被从主要执行这些任务中释放出来,得到的不依赖于GUI的对象452被客户机适配器432处理来产生这些界面中的任一个。这可例如通过实现模板处理器来获得。
在各种实施例中,模板处理器采用GUI屏幕的一般表示,并且可能能够应用其内容(例如,字段、按钮和事件)的可扩展标记语言(XML)版本,该版本可被称为GUI屏幕模板。此外,模板处理器可能还能够应用可能仍被解释运行时引擎412显示在典型客户机中的、被称为基本模板的版本,该版本至少在不存在屏幕的GUI模板的情况下进行基本转换。GUI屏幕和基本模板包括表示GUI屏幕布局的元数据和内容。GUI屏幕模板与基本模板有关,但是其定制版本。
模板可被设计成改变现有的不依赖于GUI的对象的布局。对于在此之前呈现的实例,可存在两种类型的模板,即基本模板和GUI屏幕模板。应该理解,各种实现可根据需要使用不同的模板。
第一模板可被称为基本模板。对于许多应用,可存在差不多上千个GUI屏幕,并且对于每一个屏幕可花费大量的时间和精力来开发和应用模板(即,新布局)。然而,基本模板可以应用基本转换,而无须为每一个GUI屏幕创建新模板布局。相反,它可应用转换逻辑来创建单个新布局GUI屏幕。基本模板可以输出一个GUI屏幕,并且通常不被设计成将多个GUI屏幕组合成一个GUI屏幕。
第二模板可被称为GUI屏幕模板。GUI屏幕模板可包括给定GUI屏幕的模板。GUI屏幕模板布局可以针对头部和内容部分两者覆盖基本模板布局。被覆盖的内容布局可以是诸如网格布局之类的表格和/或诸如折叠布局之类的分组。新布局可以被定义在XML文件中。GUI屏幕模板布局可以将多个GUI屏幕组合成一个GUI屏幕,并可专用于它正改变的GUI屏幕。
如此处所使用的,术语“GUI屏幕”可涉及被设计成消费显示器的呈现字段或显示区域的部分或全部的用户界面元素。例如,某些用户界面元素被设计成仅消费显示器的诸如被该显示器上的边框、框或其他类似窗口的用户界面元素框住的一部分或子部分。在某些情况下,GUI屏幕可具有一组UI控件,该组UI控件允许用户放大、减小或移动围绕显示器的呈现字段的GUI屏幕,或者将GUI屏幕整个地从显示器的呈现字段中删除。GUI屏幕的示例可包括用户界面元素,诸如例如由Microsoft Windows或Microsoft Window Form用户界面应用或其他应用和操作系统生成的GUI“窗口”。
模板处理器可以应用上述模板等,以生成包括有关GUI屏幕布局的细节的、不依赖于GUI的对象452的定制版本。渲染引擎438以及UI转换逻辑可以接收不依赖于GUI的对象452的新定制版本,并为客户机404生成新定制的GUI视图(例如,GUI窗口)以供呈现给最终用户。渲染引擎438可以用GUI控件和性质来映射GUI对象属性(例如,头部→功能区),并生成客户机404所需的特定GUI控件和布局。
图8A示出了根据一个实施例的用于处理表示GUI对象布局的模板的模板处理系统800的框图。在一个实施例中,模板处理系统800可以被实现成用于服务器802的服务器应用810的部分。服务器应用810和服务器802可以表示如参考图4来描述的相应服务器应用410和服务器402。然而,可以理解,模板处理系统800也可以被实现在n层客户机-服务器体系结构的各个其他部分中,包括例如客户机804的客户机应用830。
在一个实施例中,客户机应用830可以表示例如参考图4来描述的客户机404的web客户机430和/或客户机适配器432。另外地或另选地,客户机应用830可以被实现成与客户机应用430不同的客户机应用,诸如例如服务器应用810的本机版本或桌面版本。其他客户机应用也可被实现。各实施例不限于该上下文。
如之前参考图4描述的,具有已改变用户事件性质451的消息450可被发送给服务器应用430。服务器应用410的解释运行时引擎412随后处理该已改变用户事件性质451以产生不依赖于GUI的对象452。
在图8A中示出的说明性实施例中,类似的过程可以由用户事件804来表示,客户机804的客户机应用830可以经由用户界面管理器806将该用户事件804转发到解释运行时引擎850,以产生不依赖于GUI的对象812。然而,在这点处,不依赖于GUI的对象812是临时的不依赖于GUI的对象,并且未准备好供客户机应用830呈现。为了细化不依赖于GUI的对象812以供特定客户机应用830使用,该不依赖于GUI的对象812可被转发给模板处理器814进行进一步处理。随后,模板处理器814可以通过不依赖于GUI的对象812应用基本模板816以及GUI屏幕模板818。
基本模板816可以应用基本转换,而无须为每一个GUI屏幕创建新模板布局。基本模板816可以应用转换逻辑来创建如GUI视图811所示的单个新布局。在这个实施例中,GUI视图811未被设计成将多个GUI屏幕组合成一个GUI屏幕。
GUI屏幕模板布局可以针对头部和内容部分两者覆盖基本模板816的基本模板布局。被覆盖的内容布局可以是诸如网格布局之类的表格和/或诸如折叠布局之类的分组。在一个实施例中,新布局可以在XML文件中被定义或以其他合适的与web相关的布局格式来定义。GUI屏幕模板布局可以将多个GUI屏幕组合成一个GUI屏幕,并可专用于它正改变的GUI屏幕。
模板处理器814可随后应用上述模板816、818来生成新的且高度已定制的不依赖于GUI的对象820,该不依赖于GUI的对象820包括有关GUI屏幕布局的细节。该新的不依赖于GUI的对象820可以包括不依赖于GUI的对象812的更具体的实现,该更具体的实现进而表示参考相应的图3、4描述的不依赖于GUI的对象360、452。将该新的不依赖于GUI的对象820从服务器应用810返回给在客户机804上执行的客户机应用830的渲染引擎822。
渲染引擎822接收该新的不依赖于GUI的对象820,并执行被设计成为最终用户生成定制的新GUI视图824的UI转换逻辑。渲染引擎822可以用GUI控件和性质来映射GUI对象属性(诸如例如,头部→功能区),并生成客户机应用所需的特定GUI控件和布局。
图8B、8C提供了相应GUI视图811、824的更详细的说明。例如,表示基本模板的GUI屏幕可被示出在图8B的GUI视图811中,而从GUI屏幕模板得到的GUI屏幕可被示出在图8C中的GUI视图824中。
在图8B、8C中示出的说明性实施例中,从基本模板816构建的GUI视图811(图8B)可以表现为类似于,但还是不同于,从屏幕模板818构建的GUI视图824(图8C)。回想屏幕模板818将取代基本模板816。即,基本模板816可以被首先应用,而屏幕模板818可以在稍候被应用来定制该基本模板816。在图8B(基本模板表示)和图8C(屏幕模板表示)的说明性示例中,已经重新安排了按钮和字段框中的许多。例如,从基本模板816构建的GUI视图811中的左下按钮已被重定位到在从屏幕模板818构建的GUI视图824的左上方部分上的菜单栏中。用于811(图8B)和824(图8C)的GUI视图两者都示出了功能区UI表示826。功能区是大型工具栏,该大型工具栏包含依据功能来组织的菜单和按钮的分组。每一功能区在功能上与选项卡(tab)相关联。参考图8C的GUI视图824,该选项卡是“Vendor(供应商)”。此外,vendor选项卡的布局已被安排在两个部分中。部分1被标记为“General(通用)”828,而部分2被标记为“Addresses(地址)”860。这与图8B中的GUI视图811不同,因为GUI视图824中的选项卡(Addresses(地址)、Accounts(账户)、Options(选项)、Email(电子邮件)、Withholding(隐藏))替代了GUI视图811中的按钮(Options(选项),Address(地址),Accounts(账户),E-mail(电子邮件))。应该理解,在GUI视图811、824之间已作出了并且可以作出其他修改和更改。通过这种方式,模板处理系统800可以向针对实现不同客户机适配器(例如,客户机适配器232、242)的不同web客户机(例如,web客户机230、240)的定制GUI视图提供从由服务器应用(例如,410、810)所提供的本机GUI视图导出的定制GUI视图。
图9示出逻辑流程900。逻辑流程900可示出根据一个或多个实施例执行的操作。例如,逻辑流程900可示出由如图8所示的服务器应用810和/或客户机应用830执行的操作。另外地或另选地,逻辑流程900可以示出由如图4所示的服务器应用410和/或web客户机430执行的操作。各实施例不限于该上下文。
在逻辑流程900中,用户与在客户机侧用户界面中执行的web客户机交互,以输入用户事件。框902、904和906可以表示已在图5中较完整地描述过的逻辑过程的缩略表示。
在逻辑流程900中,当在框906处运行时引擎生成了不依赖于GUI的对象后,可在框908将该不依赖于GUI的对象转发给模板处理器。例如,该不依赖于GUI的对象812可以被客户机应用830转发给在服务器应用810中执行的模板处理器814来进行进一步处理。
在逻辑流程900中,在框912,模板处理器可以应用所生成的基本模板和屏幕模板来生成新的GUI对象。例如,模板处理器814可以应用所生成的基本模板816和屏幕模板818来生成定制的新的不依赖于GUI的对象820。
在逻辑流程900中,在框914,可将该新的不依赖于GUI的对象发送回客户机。例如,定制的新的不依赖于GUI的对象820可(经由网络250)被发送回客户机应用830,在客户机应用830处,该对象820可被转发给渲染引擎822进行进一步处理。
在逻辑流程900中,在框916,渲染引擎可转换GUI对象,并可生成新的GUI屏幕。例如,渲染引擎822可转换不依赖于GUI的对象820,并可生成由客户机应用830(或客户机适配器或客户机OS)渲染的定制的GUI视图824。
图10示出适用于实现上述各实施例的示例性计算体系结构1000的实施例。计算体系结构1000包括各种常见计算元件,如一个或多个处理器、协处理器、存储器单元、芯片组、控制器、外围设备、接口、振荡器、定时设备、视频卡、音频卡、多媒体输入/输出(I/O)组件,等等。然而,各实施例不限于由计算体系结构1000来实现。
如图10所示,计算体系结构1000包括处理单元1004、系统存储器1006以及系统总线1008。处理单元1004可以是可购得的各种处理器中的任一种。双微处理器和其他多处理器体系结构也可用作处理单元1004。系统总线1008向包括但不限于系统存储器1006的各系统组件提供到处理单元1004的接口。系统总线10010可以是若干类型总线结构中的任一种,这些总线结构还可互连到存储器总线(带有或没有存储器控制器)、外围总线、以及使用各类市场上可购买到的总线体系结构中的任一种的局部总线。
系统存储器1006可以包括各种类型的存储器单元,诸如只读存储器(ROM)、随机存取存储器(RAM)、动态RAM(DRAM)、双倍数据率DRAM(DDRAM)、同步DRAM(SDRAM)、静态RAM(SRAM)、可编程ROM(PROM)、可擦除可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、闪存、诸如铁电聚合物存储器等聚合物存储器、奥氏存储器、相变或铁电存储器、硅-氧化物-氮化物-氧化物-硅(SONOS)存储器、磁卡或光卡、或适于存储信息的任何其他类型的介质。在图10示出的所示实施例中,系统存储器1006可包括非易失性存储器1010和/或易失性存储器1012。基本输入/输出系统(BIOS)可以存储在非易失性存储器1010中。
计算机1002可包括各种类型的计算机可读存储介质,包括内置硬盘驱动器(HDD)1014、用于读写可移动磁盘10110的磁软盘驱动器(FDD)1016、以及用于读写可移动光盘1022(例如,CD-ROM或DVD)的光盘驱动器1020。HDD1014、FDD1016、以及光盘驱动器1020可分别由HDD接口1024、FDD接口1026和光盘驱动器接口10210连接到系统总线100108。用于外置驱动器实现的HDD接口1024可包括通用串行总线(USB)和IEEE1394接口技术中的至少一种或两者。
驱动器及相关联的计算机可读介质提供了对数据、数据结构、计算机可执行指令等的易失性和/或非易失性存储。例如,多个程序模块可被存储在驱动器和存储器单元1010、1012中,包括操作系统1030、一个或多个应用程序1032、其他程序模块1034和程序数据1036。这一个或多个应用程序1032、其他程序模块1034、以及程序数据1036可包括例如客户机-服务器系统200、300和400的软件组件。
用户可以通过一个或多个有线/无线输入设备,例如键盘10310和诸如鼠标1040等定点设备将命令和信息输入到计算机1002中。其他输入设备可包括话筒、红外(IR)遥控器、操纵杆、游戏垫、指示笔、触摸屏等等。这些和其他输入设备通常通过耦合到系统总线10010的输入设备接口1042连接到处理单元1004,但也可通过诸如并行端口、IEEE1394串行端口、游戏端口、USB端口、IR接口等其他接口连接。
一个或多个监视器1044或其它类型的显示设备也经由诸如视频适配器1046等的接口连接到系统总线1008。除了监视器1044之外,计算机通常包括诸如扬声器、打印机等其他外围输出设备。一个或多个监视器1045也可经由输入设备接口1042和/或诸如USB集线器1043等的集线器连接到系统总线10010。监视器1045可包括各种组件,如摄像头、话筒阵列、触摸传感器、动作传感器、扬声器等等。这些组件可经由USB集线器1043连接到输入设备接口1042。
计算机1002可使用经由有线和/或无线通信至一个或多个远程计算机(诸如远程计算机10410)的逻辑连接在联网环境中操作。远程计算机10410可以是工作站、服务器计算机、路由器、个人计算机、便携式计算机、基于微处理器的娱乐设备、对等设备或其他常见的网络节点,并且通常包括相对于计算机1002描述的许多或所有元件,但为简明起见仅示出了存储器/存储设备1050。所描绘的逻辑连接包括到局域网(LAN)1052和/或例如广域网(WAN)1054等更大网络的有线/无线连接。这种LAN和WAN联网环境常见于办公室和公司,并且方便了诸如内联网等企业范围计算机网络,所有这些都可连接到例如因特网等全球通信网络。
当在LAN联网环境中使用时,计算机1002通过有线和/或无线通信网络接口或适配器1056连接到LAN1052。适配器1056可以方便到LAN1052的有线和/或无线通信,并且还可包括其上设置的用于使用适配器1056的无线功能进行通信的无线接入点。
当在WAN联网环境中使用时,计算机1002可包括调制解调器10510,或连接到WAN1054上的通信服务器,或具有用于诸如通过因特网等在WAN1054上建立通信的其他装置。或为内置或为外置以及有线和/或无线设备的调制解调器10510经由输入设备接口1042连接到系统总线10010。在联网环境中,相对于计算机1002所描绘的程序模块或其部分可以存储在远程存储器/存储设备1050中。将明白,所示网络连接是示例性的,并且可以使用在计算机之间建立通信链路的其他手段。
计算机1002可操作来使用IEEE802标准家族来与有线和无线设备或实体进行通信,这些实体例如是在操作上安置成与例如打印机、扫描仪、台式和/或便携式计算机、个人数字助理(PDA)、通信卫星、任何一件与无线可检测标签相关联的设备或位置(例如,电话亭、报亭、休息室)以及电话进行无线通信(例如,IEEE802.11空中调制技术)的无线设备。这至少包括Wi-Fi(即无线保真)、WiMax和蓝牙TM无线技术。由此,通信可以如对于常规网络那样是预定义结构,或者仅仅是至少两个设备之间的自组织(ad hoc)通信。Wi-Fi网络使用称为IEEE802.11x(a、b、g等等)的无线电技术来提供安全、可靠、快速的无线连接。Wi-Fi网络可用于将计算机彼此连接、连接到因特网以及连接到有线网络(使用IEEE802.3相关的介质和功能)。
图11示出适用于实现上述各实施例的示例性通信体系结构1100的框图。通信体系结构1100包括各种常见通信元件,如发射机、接收机、收发机、无线电装置、网络接口、基带处理器、天线、放大器、滤波器,等等。然而,各实施例不限于由通信体系结构1100来实现。
如图11所示,通信体系结构1100包括一个或多个客户机1102和服务器1104。客户机1102可实现web客户机430。服务器1104可以实现解释运行时引擎412。客户机1102和服务器1104可操作地连接到可被用来存储相应客户机1102和服务器1104本地的信息(如cookie和/或相关联的上下文信息)的一个或多个相应客户机数据存储1108和服务器数据存储1110。
客户机1102和服务器1104可以使用通信框架1106在彼此之间传递信息。通信框架1106可以实现任何公知通信技术,如适用于与分组交换网络(例如,诸如因特网等公共网络、诸如企业内联网等专有网络,等等)、电路交换网络(例如,公共交换电话网)、或分组交换网络和电路交换网络的组合(使用合适的网关和转换器)一起使用的技术。客户机1102和服务器1104可以包括被设计成可与通信框架1106进行互操作的各种类型的标准通信元件,如一个或多个通信接口、网络接口、网络接口卡(NIC)、无线电装置、无线发射机/接收机(收发机)、有线和/或无线通信介质、物理连接器等。作为示例而非限制,通信介质包括有线通信介质和无线通信介质。有线通信介质的示例可以包括导线、电缆、金属线、印刷电路板(PCB)、背板、交换光纤、半导体材料、双绞线、同轴电缆、光纤、所传播的信号等。无线通信介质的示例可以包括声学、射频(RF)频谱、红外和其他无线介质。客户机1102和服务器1104之间的一种可能的通信可以是以适用于在两个或更多计算机进程之间传输的数据包的形式。例如,数据包可以包括cookie和/或相关联的上下文信息。
各实施例可以使用硬件元件、软件元件或两者的组合来实现。硬件元件的示例可以包括设备、逻辑设备、组件、处理器、微处理器、电路、电路元素(例如,晶体管、电阻器、电容器、电感器等)、集成电路、专用集成电路(ASIC)、可编程逻辑器件(PLD)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、存储器单元、逻辑门、寄存器、半导体设备、芯片、微芯片、芯片组等。软件元件的示例可以包括软件组件、程序、应用、计算机程序、应用程序、系统程序、机器程序、操作系统软件、中间件、固件、软件模块、例程、子例程、函数、方法、过程、软件接口、应用程序接口(API)、指令集、计算代码、计算机代码、代码段、计算机代码段、文字、值、符号、或其任意组合。确定一实施例是否使用硬件元件和/或软件元件来实现可根据如给定实现所需的任何数量的因素而变化,这些因素诸如所需计算速率、功率级、耐热性、处理周期预算、输入数据速率、输出数据速率、存储器资源、数据总线速度以及其他设计或性能约束。
一些实施例可包括制品。制品可包括被设置为存储逻辑的计算机可读的存储介质。计算机可读的存储介质的示例可包括能够存储电子数据的任何存储介质,包括易失性存储器或非易失性存储器、可移动或不可移动存储器、可擦除或不可擦除存储器、可写或可重写存储器等。逻辑的示例可包括各种软件元件,诸如软件组件、程序、应用、计算机程序、应用程序、系统程序、机器程序、操作系统软件、中间件、固件、软件模块、例程、子例程、函数、方法、过程、软件接口、应用程序接口(API)、指令集、计算代码、计算机代码、代码段、计算机代码段、文字、值、符号、或其任意组合。例如,在一个实施例中,制品可以存储可执行计算机程序指令,该指令在由计算机执行时使得该计算机执行根据所描述的各实施例的方法和/或操作。可执行计算机程序指令可包括任何合适类型的代码,诸如源代码、已编译代码、已解释代码、可执行代码、静态代码、动态代码等。可执行计算机程序指令可根据用于指示计算机执行特定功能的预定义的计算机语言、方式或句法来实现。这些指令可使用任何合适的高级、低级、面向对象、可视、已编译和/或已解释编程语言来实现。
一些实施例可使用表述“一个实施例”和“一实施例”及其派生词来描述。这些术语意味着结合该实施例描述的特定特征、结构、或性质包括在至少一个实施例中。出现在说明书中各个地方的短语在“一个实施例中”并不必全都指的是同一实施例。
一些实施例可使用表述“耦合的”和“连接的”及其派生词来描述。这些术语不必旨在互为同义词。例如,一些实施例可使用术语“连接的”和/或“耦合的”来描述以指示两个或更多元件彼此有直接的物理或电接触。然而,术语“耦合的”还可以意味着两个或更多元件彼此不直接接触,而仍彼此合作或交互。
要强调,本公开的摘要是为了允许读者快速确定本技术公开的性质而提供的。提交摘要的同时要明白,将不用它来解释或限制权利要求的范围或含义。另外,在前面的详细描述中,可以看到,出于将本公开连成一个整体的目的而将各种特征组合在一起放在单个实施例中。此公开方法将不被解释为反映所要求保护的实施例要求比每个权利要求中明确陈述的更多特征的意图。相反,如所附权利要求书所反映,发明性的主题存在于比单个已公开实施例的所有特征少的特征中。从而,据此将所附权利要求结合进详细描述中,其中每个权利要求独立地代表一个单独的实施例。在所附权利要求书中,术语“包括”和“其中”分别用作术语“包含”和“其特征在于”的易懂的英文等价词。而且,术语“第一”、“第二”、“第三”等等只用作标记,而不旨在将数字要求强加于其对象上。
尽管用结构特征和/或方法动作专用的语言描述了本主题,但可以理解,所附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言,上述具体特征和动作是作为实现权利要求的示例形式公开的。