MX2013014797A - Tecnicas para adaptar una aplicacion de tiempo de ejecucion interpretativa a multiples clientes. - Google Patents

Abstract

Se describen técnicas para adaptar un procesador de tiempo de ejecución interpretativo a múltiples clientes. Un aparato puede comprender un dispositivo lógico dispuesto para ejecutar un cliente web. El cliente web puede comprender, entre otros elementos, un adaptador de cliente operativo para detectar un evento de usuario para una interfase de usuario de cliente, enviar cambios a propiedades de evento de usuario asociadas con el evento de usuario a una aplicación de servidor, recibir un objeto dependiente de interfase de usuario gráfica (GUI) y propiedades de eventos de usuario actualizadas de la aplicación de servidor, y actualizar una imagen presentada en la interfase de usuario de cliente utilizando el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor. Se describen y reclaman otras modalidades.

Description

TECNICAS PARA ADAPTAR UNA APLICACION DE TIEMPO DE EJECUCION INTERPRETATIVA A MULTIPLES CLIENTES ANTECEDENTES Una arquitectura de cliente-servidor es una estructura de aplicación distribuida que divide tareas de cómputo o cargas útiles para un programa de aplicación entre dos entidades básicas, denominadas como servidores y clientes. Un servidor es un proveedor de recursos o servicios. Un cliente es un solicitante recursos o servicios. Un servidor es un dispositivo físico o lógico que está ejecutando uno o más programas de servidor que comparten sus recursos con clientes. Un cliente es un dispositivo físico o lógico que típicamente no comparte ninguno de sus recursos, pero solicita contenido o funciones de servicio de un servidor. Los clientes y servidores frecuentemente se comunican sobre una red de computadora en hardware separado. Sin embargo, en algunos casos tanto el cliente como el servidor pueden residir en el mismo sistema. Por lo tanto los clientes inician sesiones de comunicación con servidores que esperan solicitudes entrantes.

Una forma de arquitectura de cliente-servidor es una arquitectura de niveles múltiples, frecuentemente denominada como arquitectura de nivel n. La arquitectura de nivel n es una arquitectura de cliente-servidor en la cual ciertos aspectos de un programa de aplicación están separados en múltiples niveles. Por ejemplo, una aplicación que utiliza middleware para dar servicio a solicitudes de datos entre un usuario y una base de datos entre una arquitectura de múltiples niveles. Una arquitectura de aplicación de nivel n proporciona un modelo para que los desabolladores creen una aplicación flexible y reutilizable. Al dividir una aplicación en múltiples niveles, los desabolladores únicamente tienen que modificar o agregarun nivel específico (o capa), evitando con ello la necesidad de reescribir toda la aplicación.

La arquitectura de nivel n proporciona muchas ventajas cuando desarrolla y modifica un programa de aplicación. Sin embargo, existen dificultades al implementar una arquitectura de nivel n para un ambiente basado en web en donde existe un gran número de clientes. Cada cliente puede utilizar diferentes tecnologías web, incluyendo diferentes navegadores web, servicios web, y aplicaciones web. Además, las tecnologías web pueden estar diseñadas para trabajar con muchos tipos diferentes de arquitecturas de hardware y software subyacentes, incluyendo una variedad de dispositivos que tienen diferentes componentes de entrada/salida (l/O), factores de forma, requisitos de energía, capacidades de procesamiento, capacidades de comunicación, recursos de memoria, y así sucesivamente. Como tal, puede ser difícil implementar uno o más niveles a través de éstos muchos dispositivos y arquitecturas heterogéneos. Además, versiones web de un programa de aplicación pueden no ser compatibles con versiones no web de un programa de aplicación, creando con ello la necesidad de arquitecturas de software separadas para cada uno. Es con respecto a estas y otras desventajas que se necesitan las presentes mejoras.

BREVE DESCRIPCION DE LA INVENCION Esta Breve Descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe a continuación en la descripción detallada. Esta Breve Descripción no pretende identificar características clave o características esenciales del tema reivindicado, ni se pretende como un auxiliar al determinar el alcance del tema reivindicado.

Varias modalidades están generalmente dirigidas a una arquitectura de cliente-servidor adecuada para ejecutar diferentes tipos de programas de aplicación, tales como programas de aplicación de línea de negocios comercial, por ejemplo. Algunas modalidades particularmente están dirigidas a una arquitectura de cliente-servidor de nivel n que tiene múltiples niveles (o capas) de un programa de aplicación, incluyendo al menos un nivel de presentación. En una modalidad, por ejemplo, una arquitectura de cliente-servidor de tres niveles puede incluir al menos un nivel de presentación implementado utilizando técnicas diseñadas para separar y mejorar interfase de usuario gráfica (GUI) que presenta eventos de usuario cuando adapta una aplicación de procesador de tiempo de ejecución interpretativa para operar con muchos tipos diferentes de clientes.

En una modalidad, por ejemplo, un aparato puede comprender un dispositivo lógico dispuesto para ejecutar un cliente web. El cliente web puede comprender, entre otros elementos, un adaptador de cliente operativo para detectar un evento usuario para una interfaz de usuario de cliente, propiedades de evento de usuario cambiadas asociadas con el evento de usuario a una aplicación de servidor, recibir un objeto independiente de interfase de usuario gráfica (GUI) y propiedades de evento de usuario actualizadas de la aplicación de servidor, y actualizar una imagen presentada en la interfase de usuario de cliente utilizando el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor. Se describen y reclaman otras modalidades.

Estas y otras características y ventajas serán evidentes a partir de una lectura de la siguiente descripción detallada y una revisión de los dibujos asociados. Se entenderá que tanto la descripción general anterior como la siguiente descripción detallada son explicativas únicamente y no restrictivas de aspectos como se reclama.

BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1A ilustra una arquitectura de aplicación de escritura convencional.

La Figura 1B ilustra una arquitectura de aplicación de dos niveles convencional.

La Figura 1C ilustra una arquitectura de aplicación de tres niveles convencional.

La Figura 2 ilustra un diagrama de bloques de una arquitectura de cliente-servidor de nivel n mejorada que tiene múltiples clientes y adaptadores de cliente de acuerdo con una modalidad.

La Figura 3 es un diagrama de bloques de una arquitectura de cliente-servidor de nivel n mejorada que tiene un cliente individual y adaptador de cliente de acuerdo con una modalidad.

La Figura 4 ilustra un diagrama de bloques de una arquitectura de cliente-servidor de nivel n mejorada que tiene un objeto independiente de interfase de usuario gráfica (GUI) para un cliente y adaptador de cliente de acuerdo con una modalidad.

La Figura 5 ilustra un primer flujo lógico de una arquitectura de cliente-servidor de nivel n mejorada de acuerdo con una modalidad.

La Figura 6A ilustra un diagrama lógico de un objeto independiente de GUI de acuerdo con una modalidad.

La Figura 6B ilustra un diagrama lógico de un objeto independiente de GUI específico de acuerdo con una modalidad.

La Figura 7 ilustra un segundo flujo lógico de una arquitectura de cliente-servidor de nivel n mejorada de acuerdo con una modalidad.

La Figura 8 ilustra una modalidad de una arquitectura de cómputo adecuada para una arquitectura de cliente-servidor de nivel n mejorada de acuerdo con una modalidad.

La Figura 9 ilustra una modalidad de una arquitectura de comunicaciones adecuada para una arquitectura de cliente-servidor de nivel n mejorada de acuerdo con una modalidad.

DESCRIPCION DETALLADA Varias modalidades generalmente están dirigidas a una arquitectura de cliente-servidor adecuada para ejecutar diferentes tipos de programas de aplicación de línea de negocios comercial. Algunas modalidades están particularmente dirigidas a una arquitectura de cliente-servidor de nivel n mejorada, en donde n es una variable que representa cualquier entero positivo. La arquitectura de nivel n mejorada puede comprender múltiples niveles (o capas) de un programa de aplicación, incluyendo al menos un nivel de presentación. En una modalidad, por ejemplo, la arquitectura de nivel n mejorada puede implementarse como una arquitectura de tres niveles que comprende un nivel de presentación, un nivel de procesamiento de aplicación, y un nivel de manejo de datos. El nivel de presentación generalmente implementa lógica de interfase de usuario, tal como operaciones de manejo de entrada/salida. El nivel de procesamiento de aplicación generalmente implementa lógica de aplicación a negocio, tal como datos de procesamiento de acuerdo con un grupo de reglas de aplicación. El nivel de manejo de datos generalmente implementa almacenamiento y acceso de datos, tal como definir esquemas de datos, almacenar datos, procesar consultas de datos, y así sucesivamente.

La arquitectura de cliente-servidor de nivel n mejorada puede incluir un nivel de presentación implementado utilizando técnicas diseñadas para facilitar la separación y optimización de presentación de GUI y eventos de usuario en una aplicación utilizando un procesador de tiempo de ejecución interpretativo. Permite adaptar una aplicación de procesador de tiempo de ejecución interpretativo de una arquitectura basada en cliente-servidor de dos niveles a un ambiente de tres niveles alojado mientras reduce cambios a la aplicación de procesador de tiempo de ejecución interpretativo.

Las Figuras 1A, 1B y 1C ilustran tres arquitecturas convencionales para desarrollo de aplicación a manera de antecedentes para resaltar ventajas para varias modalidades de la arquitectura de cliente-servidor de nivel n mejorada. La Figura 1A ilustra una arquitectura de escritorio convencional. La Figura ÍB ilustra una arquitectura de dos niveles convencional. La Figura 1C ilustra una arquitectura de tres niveles convencional (o nivel n).

La Figura 1A es un ejemplo de una arquitectura de escritorio 100 en la cual se implementan todas las partes (o capas de aplicación) de un programa de aplicación 122 en una computadora de cliente 110 (por ejemplo, una computadora de escritorio). El programa de aplicación 112 puede comprender varias capas de aplicación que implementan, por ejemplo, lógica de interfase de usuario (Ul), lógica de negocio, y lógica de acceso de base de datos. El programa de aplicación 112 puede almacenar y acceder a datos de aplicación desde una base de datos 114 que se va a implementar en la computadora de cliente 110.

La Figura 1B es un ejemplo de una arquitectura de dos niveles 120 en la cual una base de datos 114 ahora está lejos de la computadora de cliente 110. En la arquitectura de dos niveles 120, el programa de aplicación 112 y sus capas de aplicación constituyentes aún existen en la computadora de cliente 110. Sin embargo, la base de datos 114 ha sido movida de la computadora de cliente 110 a Un servidor de base de datos 116. El programa de aplicación 112 que corre en la computadora de cliente 110 envía solicitudes para datos a través de interfases de programa de aplicación de base de datos (API) al servidor de base de datos 116 que está acoplado comunicativamente con la base de datos 114. Los datos solicitados entonces son regresados al programa de aplicación 112 ejecutándose en la computadora de cliente 110.

La Figura 1C es un ejemplo de una arquitectura de tres niveles 130. La arquitectura de tres niveles 130, el programa de aplicación 112 puede estar separado en programas de aplicación distribuido 112, 124 que se ejecutan en computadora de cliente respectiva 110 y un servidor 122. El programa de aplicación 112 puede implementar una capa de aplicación que tiene lógica Ul. El programa de aplicación 124 puede implementar una capa de aplicación que tiene lógica de negocio y de acceso de base de datos. El programa de aplicación 112 que corre en la computadora de cliente 110 envía datos al servidor 122 que están ejecutando el programar aplicación 124. En programa de aplicación 124 entonces puede ejecutar lógica de negocio y enviar solicitudes para datos al servidor de base de datos 116 que está acoplado comunicativamente con la base de datos 114. Los datos solicitados y los resultados de la lógica de negocio ejecutada entonces se regresan al programa de aplicación 112 y se presentan en la computadora de cliente 110. Se debe observar que el servidor de base de datos 116 puede estar colocalizado con el servidor 122 para ser una parte el servidor 122. En otras palabras, la arquitectura de hardware puede ser tal que un servidor individual 122 funciona como una aplicación y servidor de base de datos. Un factor distintivo entre una arquitectura de dos niveles y una de tres niveles (o nivel n) es que algunas o muchas de las capas de aplicación se mueven fuera de la computadora de cliente 110 y se distribuyen entre uno o más de otros servidores 116, 122.

Una arquitectura de nivel n, tal como la arquitectura de tres niveles 130, pueden proporcionar muchas ventajas con relación a una arquitectura de dos niveles 120 cuando desarrolla y modifica un programa de aplicación. Por ejemplo, un nivel individual puede modificarse o agregarse sin causar una reescritura completa de todo el programa de aplicación. Sin embargo, existen dificultades al implementar una arquitectura de nivel n para un ambiente basado en web en donde existe un gran número de clientes. Cada cliente puede utilizar diferentes tecnologías web, incluyendo diferentes navegadores web, servicios web, y aplicaciones web. Además, las tecnologías web están diseñadas para trabajar con muchos tipos diferentes de arquitecturas de hardware y software subyacentes, incluyendo una variedad de dispositivos que tienen diferentes componentes de entrada/salida (l/O), factores de forma, requisitos de energía, capacidades de procesamiento, capacidades de comunicación, recursos de memoria, y así sucesivamente. Como tal, puede ser difícil implementar una capa de aplicación dada, tal como una capa de presentación, uniformemente a través de éstos muchos dispositivos y arquitecturas heterogéneos sin personalización extensiva de la capa de presentación para ajustarse a la configuración única de cada cliente. Además, las versiones web de un programa de aplicación pueden no ser compatibles con versiones no web de un programa de aplicación, creando con ello una necesidad de arquitecturas de software separadas para cada uno.

En varias modalidades, una arquitectura de nivel n mejorada proporciona una estructura que permite migración de una arquitectura de aplicación de cliente-servidor de dos niveles o una arquitectura de aplicación de tres niveles que utiliza un cliente delgado por una capa de presentación de un programa de aplicación. En una modalidad, por ejemplo, cada dispositivo de cliente puede implementar un cliente delgado en la forma de un cliente web. Un cliente web típicamente se refiere a una aplicación de cliente delgado implementado utilizando tecnologías web, tal como un navegador web que opera en una computadora de cliente, por ejemplo. También puede referirse a programas auxiliares y aplicaciones de ayudante que mejoran el navegador para soportar servicios personalizados del sitio o servidor. Cualquiera de las referencias aquí a un cliente web también puede referirse a la funcionalidad de navegador web.

La Figura 2 ilustra un sistema de cliente-servidor 200. En una modalidad, el sistema de cliente-servidor 200 puede comprender sistema de cliente-servidor de capa n mejorada. El sistema de cliente-servidor de nivel n mejorado puede separar un programa aplicación en múltiples niveles, incluyendo al menos un nivel de presentación. El nivel de presentación puede implementarse utilizando técnicas diseñadas para facilitar la separación y optimización de presentación GUI y eventos de usuario en el programa de aplicación utilizando un procesador de tiempo de ejecución interpretativo. Permite adaptar una aplicación de procesador de tiempo de ejecución interpretativo de una arquitectura basada en cliente-servidor de dos niveles a un ambiente de tres niveles alojado mientras reduce cambios necesarios para la aplicación de procesador de tiempo de ejecución interpretativo.

Como se describió previamente con referencia a la Figura 1A, muchas aplicaciones siguen una arquitectura de aplicación de dos niveles en la cual se organiza la aplicación en dos componentes interrelacionados, el servidor de base de datos y la aplicación de cliente. El servidor de base de datos puede alojar datos de sistema y compañía, junto con lógica de negocios extendida que le permite procesar alguna de las operaciones más pesadas que podrían ser extremadamente lentas para realizar en el cliente. Mientras, la aplicación de cliente puede realizar las funciones de suministrar la Ul, proporcionar validación de entrada de datos, y presentar reportes, entre otras funciones.

En la modalidad ilustrada mostrada en la Figura 2, el sistema de cliente-servidor 200 puede comprender un servidor 202 y múltiples clientes 204, 206. Cuando se implementa en diferentes plataformas de hardware, el servidor 202 y los ciento 204, 206 pueden comunicarse entre sí a través de una red 250. Cuando sé implementa en una misma plataforma de hardware, el servidor 202 y los clientes 204, 206 pueden comunicarse entre sí con otras tecnologías y arquitecturas de conductor común adecuadas. Aunque la Figura 2 ilustra únicamente un servidor individual 202 y dos clientes 204, 206 para búsqueda de claridad, se puede apreciar que el sistema de cliente-servidor 200 puede ¡mplementar cualquier número de servidores y clientes como se desee para una implementación dada. Las modalidades no están limitadas en este contexto.

En una modalidad, el servidor 202 puede comprender un dispositivo electrónico que implementa una aplicación de servidor 210. La aplicación de servidor 210 puede comprender cualquier tipo de aplicación de servidor, tal como una aplicación de línea de negocio comercial. Ejemplos de aplicaciones de línea de negocios comercial pueden incluir sin limitación un programa de contabilidad, una aplicación de planeación de recurso de empresa (ERP), una aplicación de manejo de relación de cliente (CRM), una aplicación al manejo de cliente de suministro (CSM), y así sucesivamente. Estas aplicaciones de línea de negocio comercial algunas veces denominadas como aplicaciones de "nivel medio" típicamente como se ejecutan por servidores o arreglos de servidor en redes de empresa comercial, en lugar de dispositivos de cliente tal como una computadora de escritorio. Un ejemplo específico puede incluir Microsoft® Dynamics GP, hecho por Microsoft Corporation, Redmond, Washington. Microsoft Dynamics GP es una aplicación de software de contabilidad comercial. Otro ejemplo específico de una aplicación de ínea de negocio comercial puede comprender un Microsoft Dynamics® AX hecho por Microsoft Corporation, Redmond, Washington. Microsoft Dynamics AX es una aplicación de software ERP comercial. Sin embargo, las modalidades no están limitadas a estos ejemplos.

Cuando el servidor 202 está ejecutando código para la aplicación de servidor 210, el servidor 202 forma un procesador de tiempo de ejecución interpretativo 212. El procesador de tiempo de ejecución interpretativo 212 implementa múltiples capas dé aplicación para la aplicación de servidor 210, denominado como él sistema de cliente-servidor 200 como lógica de aplicación 214, lógica de base de datos 216, y lógica de presentación de servidor 218. La aplicación de servidor 210 puede controlarse y operarse a través de directivas de control recibidas de los clientes 204, 206 en la forma de señales o mensajes sobre la red 250.

En una modalidad, cada uno de los clientes 204, 206 puede comprender un dispositivo electrónico que implementa clientes web respectivos 230, 240. Los clientes web 230, 240 cada uno puede comprender, por ejemplo, casos de navegador web que se ejecuta en los clientes respectivos 204, 206. Los navegadores web también pueden incluir programas auxiliares, aplicaciones web y aplicaciones de ayudante diseñadas para mejorar los navegadores web para soportar servicios personalizados del servidor 202. Cualquiera de las referencias aquí a clientes de web 230, 240 también pueden referirse a funcionalidad de un navegador web.

Los clientes 204, 206 pueden comprender adaptadores de cliente 232, 242. Cada uno de los adaptadores de cliente 232, 242 puede configurarse para uso con un cliente dado 204, 206. De esta forma, la aplicación de servidor 210 y el procesador de tiempo de ejecución interpretativo 212 no necesitan modificarse cuando se acceden por diferentes clientes utilizando diferentes tecnologías web.

Los adaptadores de cliente 232, 242 pueden comprender lógica de presentación de cliente respectiva 238, 248. La lógica de presentación de cliente 238, 248 puede diseñarse para presentar elementos o vistas de interfase de usuario en un dispositivo de salida para los clientes 204, 206, tal como una presentación digital, por ejemplo. La lógica de presentación de cliente 238, 248 puede diseñarse para inter-opsrar con la lógica de aplicación 214, la lógica de datos 216, y la lógica de presentación de servidor 218 de la aplicación de servidor 210 que se ejecuta en el servidor 202, de acuerdo con la arquitectura de nivel n distribuida implementada para la aplicación de servidor 210.

Los adaptadores de cliente 232, 242, y lógica de presentación de cliente respectiva 238, 248, pueden inter-operar con la lógica de presentación de servidor 218 para permitir que la aplicación de servidor 210 se acceda a través de diferentes clientes 204, 206. Cada cliente 204, 206 puede implementar diferentes versiones de la lógica de presentaciones de servidor 218 como la lógica de presentación de cliente respectiva 238, 248 para ajustarse a una configuración particular para los clientes 204, 206. Esto puede lograrse sin tener que reescribir la lógica de presentación de servidor 218, y de manera más importante, la lógica de negocio 214 y la lógica de base de datos 216. Además, la lógica de presentación de servidor 218 y la lógica de presentación de cliente 238, 248 pueden interactuar en una forma que reduce tráfico de comunicación y datos generales para la red 250, aumentando con ello velocidad y el desempeño mientras reduce latencia asociada con retrasos de comunicación.

La aplicación de servidor 210 puede comunicarse con los adaptadores de cliente 232, 242, o versiones separadas de cada uno, separada o simultáneamente. Un escenario para operación simultánea puede incluir cuando un usuario requiere asistencia, y un administrador desea ver una segunda versión de una vista de cliente web del usuario.

En varias modalidades, la lógica de presentación de servidor 218 y la lógica de presentación de cliente 238, 248 pueden interactuar en una forma eficiente utilizando un objeto independiente de interfase de usuario gráfica (GUI) 260. El objeto independiente de GUI 260 permite que los elementos GUI, tal como pantallas GUI (por ejemplo, Formas de Microsoft Windows®), se muevan libremente entre ambientes de escritorio y ambientes web. El objeto independiente de GUI 260 permite a la aplicación de servidor 210 ejecutarse como un servicio en los antecedentes, esperar eventos de usuario que pueden recibirse ya sea a través de una forma OS tradicional o una forma de cliente web, y aún ser capaz de ejecutar eventos de escrito sin importar el tipo de forma a través de la cual se envían.

El objeto independiente de GUI 260 puede contener, entre otros tipos de información, eventos de usuario o cualquiera de las propiedades de evento de usuario que pueden influenciar la presentación dependiente de GUI por los adaptadores de cliente 232, 242 además de propiedades de evento de usuario que pueden influenciar eventos de lógica de aplicación. El objetivo independiente de GUI 260 se genera y envía desde el procesador de tiempo de ejecución interpretativo 212 a los adaptadores de cliente 232, 242, que se presenta subsecuentemente en una interfase de usuario de cliente a través de la lógica de presentación de cliente respectiva 238, 248.

La Figura 3 ilustra una implementación específica de un sistema de cliente-servidor de nivel n 300. El sistema de cliente-servidor 300 puede comprender un servidor 302 y un cliente 304. El servidor 302 puede ser representativo de, por ejemplo, el servidor 202 descrito con referencia a la Figura 2. El cliente 304 puede ser representativo de, por ejemplo, uno o ambos clientes 204, 206 descritos con referencia a la Figura 2.

En la modalidad ilustrada mostrada en el sistema de cliente-servidor 300, el servidor 302 puede implementar una aplicación de servidor 310. En una modalidad, por ejemplo, la aplicación de servidor 310 puede codificarse utilizando un lenguaje de programación Microsoft Dexterity®, entre otros tipos adecuados de lenguajes de programación. Cuando se implementa como una aplicación Microsoft Dexterity, la aplicación de servidor 310 puede estar generalmente dividida en dos elementos distintos. El primer elemento es un procesador de tiempo de ejecución interpretativo 312 que atiende los aspectos de tecnología del ambiente de aplicación tal como comunicarse con un sistema operativo (OS) y establecer y manejar una conexión a la base de datos 320 a través de un administrador de archivo 316. El segundo elemento es un diccionario de aplicación 313 que aloja la lógica de aplicación 315, tal como las reglas de aplicación, reglas de negocio, formas, reportes, recursos, metadatos, y el código de aplicación que permiten respuestas a comandos de usuario y entrada. Ejemplos de código de aplicación pueden incluir código sanScript, un complemento de Microsoft Visual Studio®, Aplicación de Microsoft Visual Basic® (VBA), Microsoft Dexterity Continuum, y así sucesivamente. Esta arquitectura aisla la lógica de aplicación 315 de cambios de estilo Ul y avances de plataforma, tal como mejoras a un OS de plataforma, por ejemplo.

El código sanScript se utiliza para controlar cómo opera una aplicación. El código sanScript típicamente está escrito en pequeños segmentos, o escritos, que están unidas a objetos en el diccionario de aplicación 313, tal como campos, menús, pantallas y formas. Los escrito se ejecutan a medida que el usuario interactúa con el objeto particular en la aplicación. Por ejemplo, un escrito aplicado a un botón oprimible se ejecutará cuando el usuario da clic al botón.

Como se muestra, el cliente 304 puede comprender ün cliente web 330. El cliente web 330 puede ser representativo de, por ejemplo, uno o ambos clientes web 230, 240. El cliente web 330 puede entregar un grupo de componentes y servicios orientados a la interfase de usuario e interacción de usuario, incluyendo controles de entrada de usuario y de interfase de usuario ligera para uso con la aplicación de servidor 310. Para lograr una migración uniforme a una arquitectura de tres niveles, sin embargo, numerosos retos de tecnología planteados por la introducción de la arquitectura de cliente web necesitan superarse para permitir una interfase de cliente web eficiente.

Una meta de las modalidades aquí descritas es reducir las modificaciones necesarias para código existente y metadatos GUI. Para resolver algunos de los retos mencionados anteriormente, varias modalidades están dirigidas a técnicas para desacoplar un administrador de interfase de usuario 318 y un procesador de presentación OS 322 del procesador de tiempo de ejecución interpretativo 312. El administrador de interfase de usuario 318 es software de sistema que controla la colocación y apariencia de varios elementos de interfase de usuario, tal como una pantalla GUI, dentro de un sistema GUI dado. El procesador de presentación OS 322 es software de sistema para presentar contenido. El procesador de tiempo de ejecución interpretativo 312 es una versión ejecutada de la aplicación de servidor 310.

El uso de formas (o pantallas) es un componente de núcleo de cualquier aplicación Microsoft Dexterity. Las formas son un mecanismo por el cual un usuario interactuará con la aplicación de servidor 310. Cuando la aplicación de servidor 310 se implementa como una aplicación Microsoft Dexterity, por ejemplo, una pantalla de Microsoft Dexterity típicamente incluye un código sanScript asociado con los controles para esa pantalla. El código sanScript se ejecuta en respuesta a eventos de usuario dada la función deseada de la pantalla y los controles (por ejemplo, guardar una transacción, publicar un grupo) bajo la dirección del intérprete de escrito 314.

En versiones no web de la aplicación de servidor 310, se administra la Ul por el administrador de interfase de usuario 31.8, que a su vez se comunica con el procesador de presentación OS 322 para presentar la pantalla Microsoft Dexterity real en la pantalla de presentación con los elementos de control previamente dispuestos por un desarro Mador.

Sin embargo, con el fin de facilitar la transición a ja arquitectura de tres niveles de cliente web del sistema de cliente- servidor 300, el administrador de interfase de usuario 318 y , e I procesador de presentación OS 322 pueden desacoplarse de las funciones del procesador de tiempo de ejecución interpretativo 312. Esto permite al cliente web 332 implementar versiones de cliente de un administrador de interfase de usuario 336 y un procesador de presentación 338 en el cliente 304. Esto además permite que el procesador de tiempo de ejecución interpretativo 312, que está ejecutándose en el servidor 302, produzca un objeto independiente I de GUI 360 para usarse por el cliente web 332. Con un objeto independiente de GUI 360, un cliente clásico puede continuar sirviendo una pantalla GUI típica (por ejemplo, una pantalla Microsoft Win32®), mientras también permite que el cliente web 330 del cliente 304 sirva a una representación basada en web de esa misma pantalla, sin tener que cambiar cualquier lógica de aplicación subyacente 315 de la aplicación de servidor 310.

El desacoplamiento del administrador de interfase de usuario 318 y el procesador de presentación OS 322 del procesador de tiempo de ejecución interpretativo 312 permite que las pantallas (formas) se muevan libremente entre ambiente no web (por ejemplo, escritorio o Win32) y ambientes web. Con el administrador la interfase de usuario 318 y el procesador de presentación OS 322 desacoplados, la aplicación de servidor 310 puede ejecutarse como un servicio en los antecedentes, esperando que los eventos de usuario puedan recibirse ya sea a través de una forma Win32 tradicional o una forma de cliente web, y aún ser capaz de ejecutar eventos descritos sin importar el tipo de forma a través de la cual se envió.

Para facilitar este desacoplamiento, las capas de procesamiento dependientes de GUI e independientemente GUI de ía aplicación de servidor 310 se separan primero. En lugar de comunicación directa entre estas dos capas, se expone metadatos de presentación y de evento utilizando el objeto independiente de GUI 360. El objeto independiente de GUI 360 puede contener cualquiera de las propiedades de evento de usuario que pueden influenciar la presentación dependiente de GUI por el adaptador de cliente 332, además de propiedades de evento de usuario que pueden influenciar eventos de lógica de aplicación. El objeto independiente de GUI 360 se envía a un adaptador de cliente (dependiente de GUI) 332 que se presenta en una pantalla de interfase de usuario de cliente en una presentación para el cliente 304. Ejemplos de algunos adaptadores de cliente 332 pueden incluir, pero no necesariamente están limitados a Microsoft Silverlight®, HTML, Win32 GDI, Net Forms, entre otros.

La Figura 4 ilustra una implementación específica de ún sistema de cliente-servidor de nivel n 400. El sistema de cliente-servidor 400 puede comprender un servidor 402 y un cliente 404. El servidor 402 puede ser representativo de, por ejemplo, los servidores 202, 302 descritos con referencia a las Figuras 2, 3. El cliente 404 puede ser representativo de, por ejemplo, uno o todos los clientes 204, 206, 304 descritos con referencia a las Figuras 2, 3.

En el servidor 402, puede haber una aplicación de servidor 410 que incluye un procesador de tiempo de ejecución interpretativo 412 que puede ser responsable de ejecutar una o más capas de aplicación o acoplarse con otros componentes que ejecutan una o más capas de aplicación. El procesador de tiempo de ejecución interpretativo 412 además puede comprender un intérprete de escrito 414, un administrador de archivo 416, y un administrador de interfase de usuario 418. El intérprete de escrito 414 puede estar en comunicación con el administrador de archivo 416 y el administrador de interfase de usuario de servidor 418. El administrador de archivo 416 también puede estar en comunicación con una base de datos 420.

En el cliente 404 existe un cliente web 430 que ejecuta un adaptador de cliente 432. El adaptador de cliente 432 puede incluir un administrador de interfase de usuario 436 y un procesador de presentación 438 para presentar el contenido en una interfase de usuario de cliente, tal como una interfase de usuario de cliente, de acuerdo con la lógica de presentación de cliente 238, 248 mostrada en la Figura 2.

La Figura 4 puede representar una arquitectura de aplicación de tres niveles en donde ciertas capas de aplicación pueden distribuirse entre el servidor 402 y el cliente 404. Por ejemplo, la lógica de presentación de cliente 238 y/o 248 puede residir en el cliente 404, mientras la lógica de aplicación 214 y la lógica de base de datos 216 pueden distribuirse sobre el servidor 402, como se muestra en la Figura 2. La arquitectura ilustrada de la Figura 4 ha desacoplado la funcionalidad del administrador de interfase de usuario 436 y procesador de presentación 438 del procesador de tiempo de ejecución interpretativo 412 en el servidor 402 y colocarlo con el adaptador de cliente 432 en el cliente 404.

En una modalidad, el procesador de tiempo de ejecución interpretativo 412 puede incluir un intérprete descrito 414. El intérprete descrito 414 puede disponerse generalmente para ejecutar código escrito en respuesta a eventos de usuario tal como, pero no limitado a, ahorrar una transacción o publicar un grupo. Ejemplos de código escrito pueden incluir pre-escritos, cambiar escritos, y posescritos, entre otros tipos de escritos.

En una modalidad, el procesador de tiempo de ejecución interpretativo 412 puede incluir un administrador de archivo 416. El administrador de archivo 416 puede disponerse generalmente para realizar operaciones de manejo de archivo en archivos almacenados en una base de datos 420. Ejemplos de las operaciones de administración de archivo pueden incluir crear archivo, abrir archivo, copiar archivo, mover archivo, eliminar archivo, entre otros.

En una modalidad, el procesador de tiempo de ejecución interpretativo 412 puede incluir un administrador de interfase de usuario 436. El administrador de interfase de usuario 436 puede disponerse generalmente para controlar la colocación y apariencia de varios elementos de interfase de usuario, tal como elementos de pantalla, dentro de una interfase de usuario que implementa un sistema GUI dado.

En operación, gn usuario puede interactuar con una interfase de usuario de cliente a través del cliente web 430. El cliente web 430 puede comprender un navegador web que tiene código de interfase ele usuario para presentar contenido basado en web. El cliente web 430 puede implementarse utilizando varias tecnologías web, tal como HTML, XHTML y XML, entre otras. Ejemplos de un cliente web 430 pueden incluir sin limitación Internet Explorer® hecho por Microsoft Corporation, Redmond, Washington, entre otros tipos de software de navegador web.

De acuerdo con una modalidad, en la operación un usuario puede interactuar con una interfase de usuario de cliente a través de un cliente web 430 y puede ingresar eventos de usuario que pueden recibirse y procesarse por el adaptador de cliente 432. Ejemplos de eventos de usuario pueden incluir sin limitación mover un indicador a un campo, flotar sobre un campo, seleccionar un campo, un clic de ratón en un botón, llenar un campo de texto, y operaciones similares. Un evento de usuario puede definirse utilizando un grupo de propiedades de evento de usuario. En una modalidad, únicamente cambios a propiedades de evento de usuario necesitan enviarse del cliente web 430 a la aplicación de servidor 410, en lugar de un grupo completo de propiedades de evento de usuario. Esta técnica diferencial puede conservar ancho de banda de comunicación y reducir latencia.

Una propiedad de evento de usuario puede ser un atributo que puede asignarse a elementos de interfase de usuario, tal como campos, pantallas u objetos gráficos, presentados en un diseño de interfase de usuario. La propiedad de evento de usuario describe atributos de un estilo de presentación o formato de presentación para elementos de interfase de usuario correspondientes. La propiedad de evento de usuario puede incluir, entre otros tipos de información, un identif icador (ID) de elemento de interfase de usuario, una propiedad (por ejemplo, borde, fuente, tamaño de fuente, color de fuente, fondo, color de fondo, estilo, alineación derecha, alineación centrada, alineación derecha, espacio individual, espacio doble, y así sucesivamente), y un valor de propiedad (por ejemplo, falso, verdadero, 0, 1, etc.). Por ejemplo, una pantalla GUI puede tener un identificador "Ventana 001" con una propiedad reajustable establecida falso, que significa que la pantalla GUI no puede reajustarse por el usuario en tiempo de ejecución. Estos son únicamente algunos ejemplos, y cualquiera de los elementos de interfase de usuario y propiedades de interfase de usuario puede implementarse como se desee para una implementacion dada. Las modalidades no están limitadas en este contexto.

El cliente web 430 puede enviar un grupo de propiedades de evento de usuario cambiadas 451 y un mensaje 450 a la aplicación de servidor 410. El administrador de interfase de usuario 418 que opera en el servidor 402 envía las propiedades de evento de usuario cambiadas 451 en el mensaje 450 al intérprete descrito 414 para procesamiento. La aplicación de servidor 410 puede asegurar que las entradas de aplicación y estados de aplicación son apropiados antes de ejecutar cualquier lógica de aplicación para la aplicación de servidor 410. El intérprete de escrito 414 entonces puede comunicarse con el administrador de archivo 416 que tiene acceso a la base de datos 420 si es necesario para la ejecución de cualquiera de las reglas de aplicación que resultan de las propiedades de evento de usuario cambiadas 451 del mensaje 450 recibido dél cliente 404. Con la ejecución de la lógica de aplicación apropiada, él procesador de tiempo de ejecución interpretativo 412 puede producir I un objeto independiente de GUI 452. El objeto independiente de GUI 452 puede incluir, entre otra información, propiedades de evento de usuario actualizadas 454. El administrador de interfase de usuario 418 implementado por el servidor 402 puede enviar el objeto independiente de GUI 452 junto con cualquiera de las propiedades de evento de usuario actualizadas 454 de regreso al cliente 404. El adaptador de cliente 432 a través del administrador de interfase de usuario de cliente 436 y procesador de presentación 438 entonces puede actualizar la imagen previamente presentada utilizando objeto independiente de GUI 452 junto con las propiedades de evento de Usuario actualizadas 454 generadas por y recibidas de la aplicación de servidor 410.

Operaciones para las modalidades descritas anteriormente además pueden describirse con referencia a uno o más flujos lógicos. Puede apreciarse que los flujos lógicos representativos no necesariamente se han ejecutado en el orden presentado, o en cualquier orden particular, a menos que se indique de otra forma. Además, varias actividades descritas con respecto a los flujos lógicos pueden ejecutarse en serie o en forma paralela. Los flujos lógicos pueden implementarse utilizando uno o más elementos de saco y/o elementos de software de las modalidades descritas o elementos alternativos como se desee para un grupo dado de restricciones de diseño y desempeño. Por ejemplo, los flujos lógicos pueden implementarse como lógica (por ejemplo, instrucciones de programa de computadora) para ejecución por un dispositivo lógico (por ejemplo, una computadora de propósito general o propósito especial).

La Figura 5 ilustra una modalidad de un flujo lógico 500. El flujo lógico 500 puede ilustrar operaciones realizadas de acuerdo con una o más modalidades. Por ejemplo, el flujo lógico 500 puede ilustrar operaciones realizadas por el cliente web 430 y/o aplicación de ser idor 410.

En el flujo lógico 500, un usuario interactúa con un cliente web cjue se ejecuta en una interfase de usuario de lado de cliente en el bloque 502. Por ejemplo, el cliente web 430 puede recibir entrada de usuario en la forma de uno o más dispositivos de control recibidos de un dispositivo de entrada que afecta uno o más elementos de interfase de usuario de una interfase de usuario como se presentó por el procesador de presentación 438. La entrada de usuario puede interactuar con el elemento de interfase de usuario causando un evento de usuario. Por ejemplo, un usuario puede seleccionar un campo en una forma presentada de una pantalla GUI, y modificar un valor para el campo.

En el flujo lógico 500, un adaptador de cliente que se ejecuta ahí puede interpretar una directiva de control que representa los eventos de usuario en una forma compatible con una aplicación de servidor que se ejecuta en el servidor en el bloque 504. Por ejemplo, el adaptador de cliente 532 puede ejecutarse por el cliente web 430 que puede interpretar eventos de usuario en una forma similar a la aplicación de servidor 410. Los eventos de usuario pueden incluir una o más interacciones de usuario con la interfase de usuario que corre en el cliente web 430 tal como, pero no limitándose a, dar el ic con botón, llenar un campo de texto, y así sucesivamente.

En el flujo lógico 500, la operación de interpretación en él bloque 504 examina las propiedades de evento de usuario de entrada más recientes para determinar si las propiedades de evento de usuario han cambiado en diamante 506 a una extensión que la aplicación de servidor debe notificarse. Por ejemplo, el adaptador de cliente 432 puede examinar cualquiera de las entradas de usuario y cambios correspondientes a propiedades de elementos de interfase de usuario afectados para determinar si las propiedades de evento de usuario han cambiado sobre alguna cantidad de umbral. Por ejemplo, flotar sobre un campo para llevar el enfoque puede ser insuficiente para activar cualquiera de los cambios en propiedades de evento de usuario, mientras seleccionar un campo sería suficiente para notificar la aplicación de servidor 410.

En el flujo lógico 500, en aquellos casos en donde se requiere una notificación, el adaptador de cliente puede enviar cualquiera de las propiedades de evento de usuario cambiadas pendientes a la aplicación de servidor en el bloque 508. Por ejemplo, el adaptador de cuente 432 puede enviar propiedades de evento de usuario cambiadas 451 en el mensaje 450 a la aplicación de servidor 410 a través de la red 250. En algunas modalidades, el adaptador de cliente 432 puede enviar múltiples grupos de propiedades de evento de usuario cambiadas 451 para múltiples eventos de usuario en el mensaje 450 a la aplicación de servidor 410 ejecutándose en el servidor 402. Este envío en "grupo" puede ser útil en muchas formas, incluyendo ayudar a la aplicación de servidor 410 en cronometraje de evento de usuario. Por ejemplo, el intérprete de escrito 414 puede cronometrar ejecución de varios escritos (por ejemplo, pre-escritos, cambiar escritos, pos-escritos, etc.) para asegurar una secuencia precisa de actualizaciones a la aplicación de servidor 410. El envío de grupo también puede reducir comunicación general al enviar menos mensajes 450 a través de la red 250. Otras ventajas también existen, y las modalidades no están limitadas en este contexto.

En el flujo lógico 500, un procesador de tiempo de ejecución que se ejecuta en el servidor puede asegurar entradas/estados apropiados para la aplicación de servidor en el bloque 510 antes que puedan ejecutarse eventos de lógica de negocio en el bloque 512. Por ejemplo, el procesador de tiempo de ejecución interpretativo 412 que se ejecuta en el servidor 402 puede asegurar entradas de aplicación apropiadas y estados de aplicación para la aplicación de servidor 410 antes de ejecutar cualquier aplicación o lógica de negocio.

En el flujo lógico 500, las propiedades de eventos de usuario actualizadas que resultan de la ejecución de la lógica de negocio junto con un objeto lógico independiente de GUI pueden transferirse de nuevo al adaptador de cliente en el bloque 514. Por ejemplo, las propiedades de evento de usuario actualizadas 454 que resultan de la ejecución de la aplicación o lógica de negocio junto con objeto independiente de GUI 452 puede enviarse de la aplicación de servidor 410 al cliente web 430 para transferir de nuevo al adaptador de cliente 432.

En el flujo lógico 500, el adaptador de cliente entonces puede actualizar la imagen previamente presentada en la interfase de usuario de cliente del bloque 516 utilizando las propiedades de evento de usuario actualizadas y objeto independiente de GUI. Por ejemplo, el adaptador de cliente 432 puede recibir el objeto independiente de GUI 452, y el procesador de presentación 438 puede actualizar la imagen previamente presentada en la interfase de usuario de cliente utilizando las propiedades de evento de usuario actualizadas 454 y el objeto independiente de GUI 452.

La Figura 6A ilustra una modalidad de cómo puede crearse un objeto independiente de GUI 452 para un adaptador de cliente 432 utilizando datos de la aplicación de servidor 410. Como se describió previamente, el adaptador de cliente 432 puede recibir un objeto independiente de GUI 452 que ha actualizado propiedades de evento de usuario 454. Las propiedades de evento de usuario actualizadas 454 pueden comprender, entre otra información, metadatos de objeto independiente de GUI 602. En una modalidad, los metadatos de objetos independientes de GUI 602 pueden comprender metadatos hijos o estáticos. Las propiedades de evento de usuario actualizadas 454 además pueden comprender una colección de propiedad/valór 604. Los metadatos de objeto independientes GUI fijos/estáticos 602 pueden combinarse con la colección de propiedad/valor independiente de GUI 604 para generar un objeto independiente de GUI 606 que puede presentarse en el cliente web 430 por el adaptador de cliente 432.

La Figura 6B ilustra una modalidad de cómo puede crearse un objeto independiente de GUI 452 utilizando las construcciones establecidas en la Figura 6A. Las propiedades de evento de usuario actualizadas 454 pueden comprender, entre otra información, metadatos de objeto 612 y una colección de propiedad/valor 614.

Las propiedades de evento de usuario actualizadas 454 pueden comprender metadatos de objeto 612 que tienen uno o más elementos de interfase de usuario. En este ejemplo, los metadatos de objeto 612 incluyen tres elementos de interfase de usuario en la forma de campos, etiquetado Campo A, Campo B y Campo C. Cada uno de los Campos A, B, y C se muestran generalmente como un cuadro de texto con un borde alrededor de texto de fuente predeterminado compuesto de las frases 'Campo A', 'Campo B',. y 'Campo C respectivamente.

Las propiedades de evento de usuario actualizadas 454 además pueden comprender una colección de propiedad/valor 614. En una modalidad, la colección de propiedad/valor 614 puede implementarse en una estructura de datos, tal como una tabla que tiene una o más tupias (o filas), con cada fila que comprende atributos (o columna) incluyendo un identif icador de un elemento de interfase de usuario, üna propiedad para el elemento de interfase de usuario, y un valor para la propiedad. La tabla de identificadores, propiedades y valores puede corresponder a los campos de los metadatos de objeto 612.

Cuando se combinan juntos el resultado puede ser un objeto independiente de GUI 616. Como se muestra en el objeto independiente de GUI 616, el campo A no cambia de la versión de metadatos genérica debido a que ninguna de estas propiedades o valores cambió en la colección de propia/valor 614. El Campo B se muestra sin su borde debido a que la propiedad 'borde' se estableció al valor 'Paso' en la colección de propiedad/valor 614. El texto en el Campo C se muestra en negritas debido a que la propiedad 'negritas' estableció el valor 'Verdadero' en la colección de propiedad/valor 614. El objeto 616 ahora puede presentarse en el cliente 404 en el cliente web 430 por el procesador de presentación 438 del adaptador de cliente 432.

La Figura 7 ilustra una modalidad de un flujo lógico 700. El flujo lógico 700 puede ilustrar operaciones realizadas de acuerdo con una o más modalidades. Por ejemplo, el flujo lógico 700 puede ilustrar operaciones realizadas por el cliente web 430 y/o la aplicación de servidor 410 para propósitos de cubrir el adaptador de cliente 432 que se ha destruido.

Otro beneficio de las modalidades aquí descritas es que una imagen presentada en un cliente dado 404 puede recuperarse si se destruye un adaptador de cliente 432. Si se destruye un adaptador de cliente 432, la imagen presentada compuesta de varios objetos dependientes de GUI 452 también se destruye. Sin embargo, la aplicación de servidor 410 puede continuar manteniendo el estado en la forma de los objetos independientes de GUI 452. Como se muestra en la Figura 7, un usuario puede interactuar con el cliente web 430 que se ejecuta en una interfase de usuario de lado de cliente para crear un nuevo caso de un adaptador de cliente 432 en el bloque 702. El nuevo caso del adaptador de cliente 432 entonces puede reconectarse a la aplicación de servidor 410 en el bloque 704. Con reconexión, la aplicación de servidor 410 aún puede mantener el último estado conocido para todos los objetos independientes de GUI 452. En el bloque 706 el último estado conocido para todos los objetos independientes de GUI 452 se transfiere de nuevo a, y se recibe por, el cliente 404. El último estado conocido para todos los objetos independientes de GUI 452 entonces puede sincronizarse con el cliente web 430 de cliente web 404 en el bloque 708. El resultado es que un estado actual para el adaptador de cliente 432 puede recuperarse efectivamente utilizando información almacenada por, la aplicación de servidor 410.

La Figura 8 ilustra una modalidad de una arquitectura de cómputo ilustrativa 800 adecuada para implementar varias modalidades como se describió previamente. La arquitectura de cómputo 800 incluye varios elementos de cómputo comunes, tal como uno o más procesadores, co-procesadores, unidades de memoria, conjuntos de chip, controladores, periféricos, interfases, osciladores, dispositivos de cronometraje, tarjetas de video, tarjetas de audio, componentes de entrada/salida (I/O) multimedia, y así sucesivamente. Las modalidades, sin embargo, no están limitadas a implementación por la arquitectura de cómputo 800.

Como se muestra en la Figura 8, la arquitectura de cómputo 800 comprende una unidad de procesamiento 804, una memoria de sistema 806 y un conductor común de sistema 808. La unidad de procesamiento 804 puede ser cualquiera de varios procesadores comercialmente disponibles. Microprocesadores dobles y otras arquitecturas de multiprocesador también pueden emplearse como la . 'f unidad de procesamiento 804. El conductor común de sistema 808 proporciona una interfase para componentes de sistema que incluyen, pero no se limitan a, memoria de sistema 806 a la unidad de procesamiento 804. El conductor común de sistema 808 puede ser cualquiera de varios tipos de estructuras de conductor común que además pueden interconectarse a un conductor común de memoria (con o sin un controlador de memoria), un conductor común periférico, y un conductor común local que utiliza cualquiera de una variedad de arquitecturas de conductor común comercialmente disponibles.

La memoria de sistema 806 puede incluir varios tipos de unidades de memoria, tal como memoria sólo de lectura (ROM), memoria de acceso aleatorio (RAM), RAM dinámica (DRAM), DRAM de Velocidad de Datos Doble (DDRAM), DRAM sincrónica (SDRAM), RAM estética (SRAM) ROM programable (PROM), ROM programable borrable (EPROM), ROM programable eléctricamente borrable (EEPROM), memoria flash, memoria de polímero tal como memoria de polímero ferroeléctrico, memoria ovónica, memoria de cambio de fase o ferroeléctrica, memoria de óxido de nitruro-silicio (SONOS), tarjetas magnéticas u ópticas, o cualquier otro tipo de medios adecuado para almacenar información. En la modalidad ilustrada mostrada en la Figura 8, la memoria de sistema 806 puede incluir memoria no volátil 810 y/o memoria volátil 812. Un sistema entrada/salida básico (BIOS) puede almacenarse en la memoria no volátil 810.

La computadora 802 puede incluir varios tipos de medios de almacenamiento legibles por computadora, incluyendo una unidad de disco duro (HDD) interna 814, una unidad de disco flexible (DD) magnética 816 para leer de o escribir a un disco magnético removible 818, y una unidad de disco óptico 820 para leer de o escribir a un disco óptico removible 822 (por ejemplo, un CD-ROM o DVD). La HDD 814, FDD 816 y unidad de disco óptico 820 pueden conectarse al conductor común de sistema 808 por una interfase HDD 824, una interfase FDD 826 y una interfase de unidad óptica 828, respectivamente. La interfase HDD 824 para implementaciones de unidad externa puede incluir al menos una o ambas de tecnologías de Conductor Común en Serie Universal (USB) e interfase IEEE 1394.

Las unidades y medios legibles por computadora asociados proporcionan almacenamiento de datos volátil y/o no volátil, estructuras de datos, instrucciones ejecutables por computadora, y así sucesivamente. Por ejemplo, puede almacenarse un número de módulos de programa en las unidades y unidades de memoria 810, 812, incluyendo un sistema operativo 830, uno o más programas de aplicación 832, otros módulos de programa 834, y datos de programa 836. Uno o más programas de aplicación 832, otros módulos de programa 834, y datos de programa 836 pueden incluir, por ejemplo, componentes de software para los sistemas de cliente-servidor 200, 300 y 400.

Un usuario puede ingresar comandos e información en la computadora 802 a través de uno o más dispositivos de entrada por cable/inalámbricos, por ejemplo, un teclado 838 y un dispositivo de señalamiento, tal como un ratón 840. Otros dispositivos de entrada pueden incluir un micrófono, un control remoto infrarrojo (IR), una palanca de mandos, un almohadilla de juegos, una pluma de estilete, pantalla táctil, o similares. Estos y otros dispositivos de entrada frecuentemente están conectados a la unidad de procesamiento 804 a través de una interfase de dispositivo de entrada 842 que está acoplado al conductor común de sistema 808, pero puede conectarse por otras interfases tal como un puerto paralelo, puerto en serie IEEE 1394, un puerto de juegos un puerto USB, una interfase IR, y así sucesivamente.

Uno o más monitores 844 u otro tipo de dispositivos de presentación también están conectados al conductor común dé sistema 808 a través de una interfase, tal como un adaptador de video 846. Además del monitor 844, una computadora típicamente incluye otros dispositivos de salida periféricos, tal como bocinas, impresoras, y así sucesivamente. Uno o más monitores 845 también pueden conectarse al conductor común de sistema 808 a través de una interfase de dispositivo de entrada 842 y/o un concentrador, tal como un concentrador de USB 843. Los monitores 845 pueden comprender varios componentes, tal como una cámara de video, micrófono de disposición, sensores táctiles, sensores de movimiento, bocinas, y así sucesivamente. Los componentes pueden conectarse-a la interfase de dispositivo de entrada 842 a través del concentrador de USB 843.

La computadora 802 puede operar en un ambiente en red que utiliza conexiones lógicas a través de comunicaciones por cable y/o inalámbricas a una o más computadoras remotas, tal como una computadora remota 848. La computadora remota 848 puede ser una estación de trabajo, una computadora de servidor, un enrutador, una computada personal, una computadora portátil, aparato de entretenimiento basado en microprocesador, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos con relación a la computadora 802, aunque, para propósitos de brevedad, únicamente se ilustra un dispositivo de memoria/almacenamiento 850. Las conexiones lógicas ilustradas incluyen conectividad por cable/inalámbrica a una red de área local (LAN) 852 y/o redes más grandes, por ejemplo como una red de área ancha (WAN) 854. Tales ambientes en red LAN y WAN comúnmente están ubicados en oficinas y compañías, y facilitan redes de computadora extendidas en empresa, tal como Intranets, todas de las cuales pueden conectarse a una red de comunicaciones global, por ejemplo, Internet.

Cuando se utiliza en un ambiente en red LAN, la computadora 802 está conectada a la LAN 852 a través de una interfase de red de comunicación por cable y/o inalámbrica o adaptador 856. Él adaptador 856 puede facilitar comunicaciones por cable y/o inalámbricas a la LAN 852, que también pueden incluir un punto de acceso inalámbrico dispuesto en éste para comunicarse con la funcionalidad inalámbrica del adaptador 856.

Cuando se utiliza en un ambiente en red WAN, la computadora 802 puede incluir un módem 858, o se conecta a un servidor de comunicaciones en la WAN 854, o tiene otros medios para establecer comunicaciones a través de la WAN 854, tal como a manera de Internet. El módem 858, que puede ser interno o externo y un dispositivo por cable y/o inalámbrico, se conecta al conductor común de sistema 808 a través de la interfase de dispositivo de entrada 842. En un ambiente en red, los módulos de programa ilustrados relativos a la computadora 802, o porciones de la misma, pueden almacenarse en el dispositivo de memoria remota/almacenamiento 850. Se apreciará que las conexiones de red mostradas son ilustrativas y pueden utilizarse otros medios para establecer un enlace de comunicaciones entre las computadoras.

La computadora 802 es operable para comunicarse con dispositivos o entidades por cable e inalámbricos utilizando la familia de estándares IEEE 802, tal como dispositivos inalámbricos operativamente dispuestos en comunicación inalámbrica (por ejemplo, técnica de modulación sobre el aire IEEE 802.11), con, ppr ejemplo, una impresor, escáner, escritorio y/o computadora portátil, asistente digital personal (PDA), satélite de comunicaciones, cualquier pieza de equipo o ubicación asociada con una etiqueta inalámbricamente detectable (por ejemplo, un quiosco, puesto de periódicos, baño), y teléfono. Esto incluye al menos tecnologías inalámbricas Wi-Fi (o Fidelidad Inalámbrica, WiMax y Bluetooth™. De esa forma, la comunicación puede ser una estructura predefinida como con una red convencional o simplemente una comunicación ad hoc entre al menos dos dispositivos. Las redes Wi-Fi utilizan tecnologías de radio denominadas IEEE 802.11x (a, b, g, etc.) para proporcionar conectividad inalámbrica segura, confiable, rápida. Puede utilizarse una red Wi-Fi para conectar computadoras entre sí, a Internet, o a redes por cable (que utilizan medios y funciones relacionadas con IEEE 802.3).

La Figura 9 ilustra un diagrama de bloques de una arquitectura de comunicaciones ilustrativa 900 adecuada para implementar varias modalidades como se describió previamente. La arquitectura de comunicaciones 900 incluye varios elementos de comunicaciones comunes, tal como un transmisor, receptor, transceptor, radio, interfase de red, procesador de banda de base, antena, amplificadores, filtros, y así sucesivamente. Sin embargo, las modalidades no están limitadas a implementación por la arquitectura de comunicaciones 900.

Como se muestra en la Figura 9, la arquitectura de comunicaciones 900 incluye uno o más clientes 902 y servidores 904. Los clientes 902 pueden implementar el cliente web 330. Los servidores 904 pueden implementar el procesador de tiempo de ejecución 312. Los clientes 902 y los servidores 904 están conectados operativamente a uno o más almacenamientos de datos de cliente respectivos 908 y almacenamientos de datos de servidor 910 que pueden empelarse para almacenar información local a los clientes respectivos 902 y servidores 904, tal como cookies y/o información contextual asociada.

Los clientes 902 y los servidores 904 pueden comunicar información entre sí utilizando la estructura de comunicación 906. La estructura de comunicaciones 906 puede implementar cualquiera de las técnicas de comunicaciones bien conocidas, tal como técnicas adecuadas para usarse con redes conmutadas de paquete (por ejemplo, redes públicas tal como Internet, redes privadas tal como intranet de empresa, y así sucesivamente), redes conmutadas de circuito (por ejemplo, la red de teléfono conmutada pública), o una combinación de redes conmutadas de paquete y redes conmutadas de circuito (con accesos y traductores adecuados). Los clientes 902 y los servidores 904 pueden incluir varios tipos de elementos de comunicación estándar diseñados para inter-operar con la estructura de comunicaciones 906, tal como una o más interfases de comunicaciones, interfases de red, tarjetas de interfases de red (NIC), radios, transmisores/receptores inalámbricos (transceptores), medios de comunicación por cable y/o inalámbricos, cpnectores físicos, y así sucesivamente. A manera de ejemplo, y no de limitación, el medio de comunicación incluye medios de comunicaciones por cable y medios de comunicaciones inalámbricos. Ejemplos de medios de comunicaciones inalámbricos pueden incluir un alambre, cable, conductores metálicos, tarjetas de circuito impreso (PCB), tarjetas madre, telas de interruptor, material semiconductor, alambre de par torcido, cable coaxial, fibra óptica, una señal propaganda, y así sucesivamente. Ejemplos de medios de comunicaciones inalámbricas pueden incluir medios acústicos, de espectro de radiofrecuencia (RF), infrarrojos y otros inalámbricos. Una comunicación posible entre un cliente 902 y un servidor 904 puede estar en la forma de un paquete de datos adaptado para transmitirse entre dos o más procedimientos de computadora. El paquete de datos puede incluir una cookie y/o información contextual asociada, por ejemplo.

Varias modalidades pueden implementarse utilizando elementos de hardware, elementos de software, o una combinación de ambos. Ejemplos de elementos de hardware pueden incluir dispositivos, dispositivos lógicos, componentes, procesadores, microprocesadores, circuitos, elementos de circuito (por ejemplo, transistores, resistores, capacitores, inductores, y así sucesivamente), circuitos integrados, circuitos integrados específicos de aplicación (ASIC), dispositivos lógicos programables (PLD), procesadores de señal digital (DSP), acceso programable de campo (FPGA), unidades de memoria, accesos lógicos, registros, dispositivos de semiconductor, chips, microchips, conjuntos de chip, y así sucesivamente. Ejemplos de elementos de software pueden incluir componentes de software, programas, aplicaciones, programas de computadora, programas de aplicación, programas de sistema, programas de máquina, software de sistema operativo, middleware, firmware, módulos de software, rutinas, subrutinas, funciones, métodos, procedimientos, interfases de software, interfases de programa de aplicación (API), conjunto de instrucción, código de cómputo, código de computadora, segmentos de código, segmentos de código de computadora, palabras, valores, símbolos, o cualquier combinación de los mismos. Determinar sí se implementa una modalidad utilizando elementos de hardware y/o elementos de software puede variar de acuerdo con cualquier número de factores, tal como velocidad computacíonal deseada, niveles de energía, tolerancias de calor, presupuesto de ciclo de procesamiento, velocidades de datos de entrada, velocidades de datos de salida, recursos de memoria, velocidades de conductor común de datos y otras restricciones de diseño o desempeño, como se desea para un ¡mplementación dada.

Algunas modalidades pueden comprender un artículo de fabricación. Un artículo de fabricación puede comprender un medio de almacenamiento legible por computadora dispuesto para almacenar lógica. Ejemplos de un medio de almacenamiento legible por computadora incluyen cualquier medio de almacenamiento capaz de almacenar datos electrónicos, incluyendo memoria volátil "o memoria no volátil, memoria removible o no removible, memoria borrable o no borrable, memoria escribirle o reescribirle, y así sucesivamente. Ejemplos de la lógica pueden incluir varios elementos de software, tal como componentes de software, programas, aplicaciones, programas de computadora, programas de aplicación, programas de sistema, programas de máquina, software de sistema operativo, middleware, firmware, módulos de software, rutinas, subrutinas, funciones, métodos, procedimientos, interfases de software, interfases de programa de aplicación (API), grupos de instrucción, código de cómputo, código de computadora, segmentos de código, segmentos de código de computadora, palabras, valores, símbolos, o cualquier combinación de los mismos. En una modalidad, por ejemplo, un artículo de fabricación puede almacenar instrucciones de programa de computadora ejecutables que, cuando se ejecutan por una computadora, causan que la computadora realice métodos y/u operaciones de acuerdo con las modalidades descritas.

Las instrucciones de programa de computadora ejecutables pueden incluir cualquier tipo de código adecuado, tal como código de fuente, código recopilado, código interpretado, código ejecutable, código estático, código dinámico, y similares. Las instrucciones de programa de computadora ejecutables pueden implementarse de acuerdo con un lenguaje de computadora predefinido, forma sintaxis, para incluir una computadora a realizarse cierta función. Las instrucciones pueden implementarse utilizando cualquier lenguaje de programación recopilado y/o interpretado de alto nivel, bajo nivel, orientado a objeto, visual.

Algunas modalidades pueden describirse utilizando la expresión "una modalidad" o "una modalidad" junto con sus derivados. Estos términos significan que un aspecto, estructura o característica particular descrita en conexión con la modalidad se incluye al menos en una modalidad. Las apariciones de la frase "en una modalidad" en Y. varios lugares en la especificación no necesariamente están haciendo referencia todas a la misma modalidad.

Algunas modalidades pueden describirse utilizando la expresión "acoplado" y "conectado" junto con sus derivados. Estos términos no necesariamente se pretenden como sinónimos entre sí. Por ejemplo, algunas modalidades pueden describirse utilizando los términos "conectado" y/o "acoplado" para indicar que dos o más elementos están en contacto físico o eléctrico directo entre sí. El término "acoplado", sin embargo, puede significar también que dos o más elementos no están en contacto directo entre sí, sino que aún cooperan o ¡nteractúan entre sí.

Se enfatiza que el resumen de la descripción se proporciona para permitir al lector evaluar rápidamente la naturaleza de la descripción técnica. Se afirma con el entendimiento que no se utilizará para interpretar o limitar el alcance o significado de las reivindicaciones. Además, en la descripción detallada anterior, se puede observar que se agrupan varias características juntas en una modalidad individual para el propósito de transmitir la descripción. Este método de descripción no se interpreta como reflejando una intención que las modalidades reivindicadas requieren más características a lo mencionado expresamente en cada reivindicación. Más bien, como reflejan las siguientes reivindicaciones, el tema inventivo yace en menos de todas las características de una modalidad descrita individual. De esa forma las siguientes características se incorporan aquí en la descripción detallada, con cada reivindicación independiente como una modalidad separada. En las reivindicaciones enmendadas, los términos "que incluye" y "en donde" se utilizan como los equivalentes de inglés simple de los términos respectivos "que comprende" y "en donde", respectivamente. Además, los términos "primero", "segundo", "tercero", y así sucesivamente, se utilizan simplemente como etiquetas, y no pretenden imponer requisitos numéricos en sus objetos.

Aunque el tema se ha descrito en lenguaje específico a características estructurales y/o actos metodológicos, se entenderá que el tema definido en las reivindicaciones anexas río necesariamente está limitado a las características o actos específicos descritos anteriormente. Más bien, las características y actos específicos descritos anteriormente se describen como formas ilustrativas para implementar las reivindicaciones.

Claims (10)

REIVINDICACIONES

1. - Un método implementado por computadora, que comprende: recibir una directiva de control que representa un evento de usuario en una interfase de usuario de cliente; determinar si cambian propiedades de evento de usuario asociadas con el evento de usuario; enviar las propiedades de evento de usuario cambiadas a una aplicación de servidor que se ejecuta en un servidor; recibir un objeto independiente de interfase de usuario gráfica (GUI) que tiene propiedades de evento de usuario actualizadas de la aplicación de servidor; y actualizar la imagen presentada en la interfase de usuario de cliente basándose en el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor.

2. - El método implementado por computadora de acuerdo con la reivindicación 1, que comprende recibir el objeto independiente de GUI que tiene propiedades de evento de usuario actualizadas, las propiedades de evento de usuario actualizadas que comprenden al menos uno de: metadatos de objeto que tienen uno o más elementos de interfase de usuario, o una colección de propiedad/valor que tiene una o más tupias, cada tupia comprende un identif icador para un elemento de interfase de usuario, una propiedad para el elemento de interfase de usuario, y un valor para la propiedad.

3. - El método implementado por computadora de acuerdo con la reivindicación 1, que comprende enviar múltiples propiedades dé evento de usuario cambiadas para múltiples eventos de usuario en un mensaje a la aplicación de servidor que se ejecuta en el servidor.

4. - El método implementado por computadora de acuerdo con la reivindicación 1, que comprende actualizar uno o más elementos de interfase de usuario de la imagen presentada en la interfase de usuario de cliente basándose en el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor.

5. - El método implementado por computadora de acuerdo con la reivindicación 1, que comprende: crear un nuevo caso de un adaptador de cliente cuando un caso previo de un adaptador de cliente y su imagen presentada asociada compuesta de objetos dependientes de GUI han sido destruidos; reconectar el nuevo caso del adaptador de cliente a la aplicación de servidor; recibir un último estado conocido para todos los objetos independientes de GUI de la aplicación de servidor; y sincronizar en el nuevo caso del adaptador de cliente el último estado conocido para todos los objetos independientes de GUI recibidos de la aplicación de servidor.

6. - Un artículo de fabricación que comprende un medio de almacenamiento que contiene instrucciones que cuando se ejecutan permiten a un sistema realizar el método de acuerdo con cualquiera de las reivindicaciones 1, 2, 3, 4, o 5.

7. - Un aparato, que comprende: un dispositivo lógico; y un cliente web operable en el dispositivo lógico, el cliente web comprende un adaptador de cliente operativo para detectar un evento de usuario para una interfase de usuario de cliente, enviar cambios a propiedades de evento de usuario asociadas con el evento de usuario a una aplicación de servidor, recibir un objeto independiente de interfase de usuario gráfica (GUI) y propiedades de evento de usuario actualizadas de la aplicación de servidor, y actualizar una imagen presentada en la interfase de usuario de cliente utilizando el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor.

8. - El aparato de acuerdo con la reivindicación 7, en donde el objeto independiente de GUI que tiene propiedades de evento de usuario actualizadas, las propiedades de evento de usuario actualizadas que comprenden metadatos de objeto y una colección de propiedad/valor, los metadatos de objeto comprenden uno o más elementos de interfase de usuario, y la colección de propiedad/valor que comprende una o más tupias cada una comprende un identificador para un elemento de interfase de usuario, una propiedad para el elemento de interfase de usuario, y un valor para la propiedad.

9. - El aparato de acuerdo con la reivindicación 7, en donde el adaptador de cliente comprende al menos uno de: un administrador de interfase de usuario para controlar la interfase de usuario de cliente, o un procesador de presentación para actualizar la imagen presentada basándose en el objeto independiente de GUI y propiedades de evento de usuario actualizadas recibidas de la aplicación de servidor.

10.- El aparato de acuerdo con la reivindicación 7, el cliente web operativo para: crear un nuevo caso del adaptador de cliente cuando un caso previo del adaptador de cliente y su imagen presentada asociada compuesta de uno o más objetos dependientes de GUI han sido destruidos; en donde el nuevo caso del adaptador de cliente es operativo para reconectarse a la aplicación de servidor, recibir un último estado conocido para todos los objetos independientes de GÜI de la aplicación de servidor, y sincronizar en el nuevo caso del adaptador de cliente el último estado conocido para todos los objetos independientes de GUI recibidos de la aplicación de servidor.