ES2368366T3 - Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red. - Google Patents

Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red. Download PDF

Info

Publication number
ES2368366T3
ES2368366T3 ES08767554T ES08767554T ES2368366T3 ES 2368366 T3 ES2368366 T3 ES 2368366T3 ES 08767554 T ES08767554 T ES 08767554T ES 08767554 T ES08767554 T ES 08767554T ES 2368366 T3 ES2368366 T3 ES 2368366T3
Authority
ES
Spain
Prior art keywords
client
file
integrated device
files
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08767554T
Other languages
English (en)
Inventor
Ramon A. Vorne
Benjamin D. Saks
Ke Tang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
VORNE INDUSTRIES Inc
VORNE IND Inc
Original Assignee
VORNE INDUSTRIES Inc
VORNE IND Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by VORNE INDUSTRIES Inc, VORNE IND Inc filed Critical VORNE INDUSTRIES Inc
Application granted granted Critical
Publication of ES2368366T3 publication Critical patent/ES2368366T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/986—Document structures and storage, e.g. HTML extensions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G06F40/106—Display of layout of documents; Previewing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0742—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in a mobile device, e.g. mobile phones, handheld devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G06F13/4295—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using an embedded synchronisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Abstract

Método para permitir que un dispositivo integrado (102) funcione conjuntamente con un cliente (104) en un ordenador anfitrión (106), para acceder a contenido de un archivo accesible para el ordenador anfitrión (106), aunque no directamente accesible para el cliente (104), que comprende las etapas siguientes: seleccionar un archivo en el cliente (104); establecer un enlace de comunicaciones entre el cliente (104) y el dispositivo integrado (106); enviar una parte del archivo desde el cliente al dispositivo integrado de un tamaño que encaje dentro de las limitaciones de recursos del dispositivo integrado, el cual, a continuación, devuelve la parte al cliente; añadir la parte devuelta a cualesquiera partes previas recibidas en el cliente (104); y repetir las etapas previas de envío y adición hasta que el archivo se haya reconstruido completamente en el cliente (104); en donde el cliente (104) accede al archivo reconstruido como un proxy para el dispositivo integrado.

Description

Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red.
Antecedentes
La presente invención se refiere a dispositivos integrados conectados a redes que tienen clientes tales como navegadores web que se ejecutan en uno o más ordenadores anfitriones.
Los dispositivos integrados (es decir, dispositivos que combinan software y hardware electrónicos y posiblemente piezas mecánicas u otros componentes, y que están diseñados específicamente para ejecutar una función o tarea dedicada; por ejemplo, máquinas expendedoras, electrodomésticos, controladores de motores, impresoras) se diseñan frecuentemente para funcionar en combinación con ordenadores anfitriones con el fin de proporcionar características tales como interfaces de usuario mejoradas (que usan la pantalla del ordenador anfitrión), acceso remoto (a través de una red a la cual están conectados tanto el ordenador anfitrión como el dispositivo integrado), y modernizaciones de microprogramas (cargando una versión nueva del microprograma en el dispositivo integrado desde el ordenador anfitrión). Aprovechando las capacidades y los recursos del ordenador anfitrión, el dispositivo integrado puede superar las restricciones de recursos internos que son inherentes debido a las limitaciones de coste y/o tamaño del dispositivo integrado. Estas restricciones se manifiestan frecuentemente como limitaciones en la cantidad de memoria (por ejemplo, bytes de memoria de acceso aleatorio) y/o el poder de procesado (por ejemplo, velocidad del procesador, tamaño del bus de datos, conjunto de instrucciones, y periféricos incorporados) del dispositivo integrado.
Centrándose más en la cuestión de las restricciones de memoria en los dispositivos integrados, resulta particularmente preocupante la memoria de acceso aleatorio (RAM). Típicamente, los microcontroladores de un solo chip, que con frecuencia se usan en dispositivos integrados, tienen una RAM limitada y se basan en otros tipos de memoria (por ejemplo, memoria flash) para almacenar programas y otros datos constantes. Por ejemplo, una plataforma de microprocesador actualmente popular para dispositivos integrados es la ARM7. Dos de los proveedores líderes de ARM7, Atmel Corporation y NXP Semiconductors, ofrecen ambos, dispositivos ARM7 con conectividad de red (en forma de controladores de acceso a los medios de Ethernet). La familia AT91SAM7X de Atmel proporciona una memoria flash que es cuatro veces la cantidad de memoria RAM (por ejemplo, el AT91SAM7XC512 de gama alta incluye una flash de 512 KB y una RAM de 128 KB). La diferencia es aún más pronunciada en el NXP LPC2368, que incluye 512 KB de flash y solamente 58 KB de RAM. Puesto que la RAM es frecuentemente un recurso muy limitado en dispositivos integrados, resulta especialmente deseable reducir el uso de RAM en dispositivos integrados.
Dos técnicas comunes para aprovechar las capacidades y los recursos de los ordenadores anfitriones son: i) instalar software personalizado en cada ordenador anfitrión que interaccionará con el dispositivo integrado, o ii) incorporar un servidor HTTP en el dispositivo integrado que genere contenido adecuado para un cliente HTTP (es decir, un navegador web) en el ordenador anfitrión. Cada método tiene sus puntos fuertes y sus puntos débiles.
Un punto fuerte del software personalizado es que permite que los dispositivos integrados, limitados en cuanto a recursos, aprovechen exhaustivamente las capacidades y los recursos del ordenador anfitrión, debido a la capacidad del software personalizado de acceder a y controlar muchos aspectos del ordenador anfitrión.
Un punto débil del software personalizado es que típicamente necesita ser instalado y mantenido en cada ordenador anfitrión que accederá al dispositivo integrado. En la práctica, esto frecuentemente resulta farragoso, consume mucho tiempo, y es caro, especialmente en entornos comerciales en los que típicamente solo a los departamentos de IT se les permite instalar software. Cada versión nueva del software personalizado requiere actualizaciones o instalaciones nuevas, y con frecuencia surgen problemas de compatibilidad debido a interacciones entre el software personalizado y versiones diferentes de sistemas operativos del ordenador, combinaciones diferentes de otras aplicaciones de software personalizado instaladas en el ordenador anfitrión, y/o desadaptaciones entre versiones del software personalizado y versiones de los dispositivos integrados.
Un punto fuerte de incorporar un servidor HTTP en el dispositivo integrado es que proporciona un cliente que ocupa un “espacio cero”, lo cual significa que se puede usar un cliente HTTP convencional (por ejemplo, un navegador web) de un ordenador anfitrión para acceder al dispositivo integrado desde cualquier ordenador anfitrión que tenga instalado el cliente. Puesto que la gran mayoría de ordenadores personales tienen navegadores web pre-instalados, esto constituye una mejora principal con respecto al software personalizado.
Un punto débil de la incorporación de un servidor HTTP en el dispositivo integrado es que las restricciones de recursos del dispositivo integrado, tales como las limitaciones antes mencionadas de memoria y poder de procesado, pueden tener un impacto importante en la experiencia del usuario en términos de i) calidad, tal como la facilidad de utilización de una interfaz de usuario o la sofisticación de un informe que pueda ser generado, ii) cantidad, tal como el tamaño de un informe que pueda ser generado o el tamaño de un archivo que pueda ser leído, iii) sensibilidad, tal como la rapidez con la que el dispositivo integrado puede generar contenido solicitado, y/o iv) escalabilidad, tal como el número de clientes a los que se puede prestar servicio simultáneamente.
Aunque existen tecnologías disponibles que proporcionan grados variables de procesado del lado del cliente (por ejemplo, el Reproductor Flash® de Adobe Systems Incorporated, OpenLaszlo™ de Laszlo Systems Incorporated, y el Entorno en Tiempo de Ejecución Java™ de Sun Microsystems Incorporated), estas tecnologías típicamente no están diseñadas u optimizadas de manera específica para trabajar con dispositivos integrados, y, por lo tanto, típicamente no tienen en cuenta los requisitos y limitaciones especiales de los dispositivos integrados de recursos restringidos. Como consecuencia, las tecnologías existentes padecen en general uno o más de los siguientes problemas:
1.
No están diseñadas para minimizar explícitamente el uso de memoria (por ejemplo, RAM y/o flash) y/o el ancho de banda de procesado en el servidor (es decir, dispositivo integrado) y, por lo tanto, pueden no ejecutarse de manera eficaz en dispositivos integrados de recursos restringidos.
2.
No proporcionan herramientas para leer, escribir, y/o manipular de manera arbitraria archivos grandes cuando se tienen en cuenta los recursos limitados de los dispositivos integrados.
3.
No están diseñadas para actualizar dinámicamente contenido o lo hacen de manera ineficaz.
4.
No separan limpiamente el contenido estático (que puede ser almacenado en memoria caché por el cliente) del contenido dinámico.
5.
No están diseñadas para un procesado general en el lado del cliente (por ejemplo, se centran en el procesado de la capa de presentación).
6.
Requieren herramientas de desarrollo privativas (por ejemplo, disponibles solamente en una empresa en particular, y/o solamente para una plataforma en particular) limitando de este modo las opciones de desarrollo.
7.
Requieren componentes del lado del servidor, lenguajes de programación y/o lenguajes de guión de instrucciones (scripting) que en general no están disponibles para los dispositivos integrados o que resultan adecuados de manera deficiente para su uso en dichos dispositivos.
8.
Requieren la instalación de software adicional en el cliente (por ejemplo, módulos plug-in del navegador).
9.
No soportan una amplia gama de clientes (por ejemplo, una amplia gama de plataformas de navegador).
10.
Soportan solamente un tipo único de contenido (por ejemplo, archivos SWF Flash®) o una gama limitada de contenido.
11.
No proporcionan herramientas para acceder a recursos desde dominios externos.
Debe observarse que la lista anterior de problemas se proporciona a título ilustrativo, y no está destinada a servir como una lista exhaustiva de cada aspecto de las tecnologías existentes que las pueda hacer inapropiadas para dispositivos integrados.
Por lo tanto, se requiere un método eficaz para que dispositivos integrados de recursos limitados interaccionen con ordenadores anfitriones, el cual pueda proporcionar idealmente uno o más de los siguientes puntos:
1.
Un cliente que ocupe un espacio cero y que no requiera la instalación de ningún software personalizado en el ordenador anfitrión.
2.
Una reducción significativa en la cantidad de memoria y el poder de procesado que requiere el dispositivo integrado para producir contenido sofisticado, complejo, y de alta calidad, incluyendo contenido dinámico.
3.
Una capacidad de generar contenido que sea mucho más grande (potencialmente, órdenes de magnitud más grande) de lo que puede caber dentro de la memoria disponible del dispositivo integrado.
4.
Una capacidad de almacenar archivos arbitrariamente grandes en el ordenador anfitrión y/o en sistemas de archivos accesibles para el ordenador anfitrión.
5.
Una capacidad de leer, procesar, y extraer información de archivos arbitrariamente grandes del ordenador anfitrión y/o de sistemas de archivos accesibles para el ordenador anfitrión.
6.
Una solución que maximice la cantidad de contenido que puede almacenar en memoria caché el cliente.
7.
Una solución generalizada y “genérica” que no esté limitada significativamente en el tipo de contenido que se puede generar o el tipo de procesado que se puede realizar en el cliente.
8.
Una solución que no dependa de productos específicos de terceros, módulos plug-in de navegadores, herramientas de desarrollo, etcétera.
9.
Una solución que sea eficaz sobre una gama amplia de clientes y dispositivos integrados.
10.
Una solución que se pueda adaptar de manera sencilla y flexible a los requisitos de la aplicación específica y a los recursos del dispositivo integrado específico.
11.
Una capacidad de que el cliente acumule de manera eficaz datos de múltiples dispositivos integrados al mismo tiempo que planteando unos requisitos mínimos de memoria y procesado sobre los dispositivos integrados.
12.
Una experiencia global del usuario en general mejorada cuando se interacciona con el dispositivo integrado a través del ordenador anfitrión.
Sumario
En la presente memoria se da a conocer un MÉTODO Y SISTEMA PARA AMPLIAR LAS CAPACIDADES DE DISPOSITIVOS INTEGRADOS, A TRAVÉS DE CLIENTES DE RED, que aprovecha los recursos de memoria y procesado de clientes, tales como navegadores (“clientes”) web, que se ejecutan en uno o más ordenadores anfitriones.
El dispositivo integrado de recursos limitados, conectado en red (“dispositivo integrado”) actúa como un simple servidor de archivos y datos para clientes, y estos clientes asumen la responsabilidad de la generación de contenido y otras tareas computacionales. Puesto que los clientes que se ejecutan en ordenadores anfitriones en general tienen acceso a una memoria y un poder de procesado mayores, en órdenes de magnitud, que los dispositivos integrados típicos, en general son capaces de generar un contenido bastante más enriquecido y realizar tareas computacionales bastante más sofisticadas que los propios dispositivos integrados.
Además, múltiples clientes pueden procesar y manipular simultáneamente archivos y datos servidos desde un único dispositivo integrado. El resultado final es un sistema altamente escalable que maximiza el número de clientes que puede soportar simultáneamente un dispositivo integrado, y que mejora significativamente la calidad (y cantidad) de contenido que se puede generar y la sofisticación de las tareas computacionales que se pueden realizar.
Frecuentemente, puede existir una necesidad de almacenar o abrir este contenido generado, en el ordenador anfitrión, pero puede que el cliente no disponga de los medios para lograr esto, típicamente debido a restricciones de seguridad (por ejemplo, las restricciones impuestas sobre navegadores web usados comúnmente, para escribir archivos en el ordenador anfitrión y/o en sistemas de archivos accesibles para el ordenador anfitrión). Varias formas de realización de la invención incluyen también un método y un sistema para leer y escribir archivos arbitrariamente grandes desde y en el ordenador anfitrión y/o sistemas de archivos accesibles para el ordenador anfitrión (a lo cual se hace referencia como “rebote de archivos”) al mismo tiempo que superando las limitaciones de memoria y procesado del dispositivo integrado, así como superando las limitaciones impuestas por restricciones de seguridad del cliente.
El sistema, según varias formas de realización, comprende cuatro elementos principales: un motor de procesado del cliente, archivos de plantillas estáticas, conjuntos de datos dinámicos, y canales de comunicación gestionados. Estos elementos se describen de forma más detallada posteriormente.
El motor de procesado del cliente es responsable de coordinar trabajo realizado en el cliente en nombre del dispositivo integrado. Desde la perspectiva del dispositivo integrado, el motor de procesado del cliente es simplemente un recurso estático (o una colección de recursos estáticos) almacenado en el dispositivo integrado y transmitido al cliente bajo demanda.
No obstante, desde la perspectiva del cliente, una vez que el motor de procesado del cliente se ha cargado en el cliente, el mismo es un programa ejecutable (por ejemplo, un programa JavaScript) responsable de realizar el procesado del lado del cliente. El motor de procesado del cliente interpreta archivos de plantillas estáticas y lleva a cabo las instrucciones especificadas en los mismos. El motor de procesado del cliente está destinado y diseñado explícitamente para minimizar recursos y procesado requeridos dentro del dispositivo integrado y para transferir trabajo desde el dispositivo integrado al cliente. El motor de procesado del cliente en esencia se convierte en un “sistema operativo” que se ejecuta dentro del cliente, y eleva al cliente de ser un medio de entrega de contenido a ser un “nodo” de procesado en un sistema informático distribuido.
Los archivos de plantillas estáticas son responsables de proporcionar información necesaria para realizar tareas de procesado específicas (por ejemplo, generar un informe, reproducir una página web, etcétera). Desde la perspectiva del dispositivo integrado, un archivo de plantillas estáticas es simplemente un recurso estático transmitido al cliente bajo demanda. Desde la perspectiva del cliente, un archivo de plantillas estáticas contiene un conjunto de instrucciones de procesado para el motor de procesado del cliente. En esencia, el dispositivo integrado delega tareas de procesado contenidas por archivos de plantillas estáticas al cliente, con el fin de minimizar recursos y procesado requeridos dentro del dispositivo integrado y con el fin de transferir trabajo desde el dispositivo integrado al cliente.
Los conjuntos de datos dinámicos son colecciones de datos que se intercambian entre el dispositivo integrado y el cliente. A diferencia de los archivos de plantillas estáticas, que son recursos estáticos, cada conjunto de datos dinámicos se genera dinámicamente por medio del dispositivo integrado (o alternativamente por medio del cliente). La Notación de Objetos de JavaScript (JSON), descrita mediante la RFC 4627, resulta particularmente útil como formato de conjunto de datos dinámicos ya que resulta muy sencilla de analizar sintácticamente y de generar, y se diseñó específicamente para proporcionar una representación de datos compacta. Los conjuntos de datos dinámicos, en esencia, encapsulan el aspecto “dinámico” del contenido con una representación compacta de datos, y, conjuntamente con una variedad de técnicas que minimizan los recursos y el procesado requeridos dentro del dispositivo integrado, transfieren además trabajo desde el dispositivo integrado al cliente.
Los canales de comunicación gestionados son enlaces de comunicación bidireccionales entre el motor de procesado del cliente y un dispositivo integrado. El término “gestionado” se refiere al hecho de que los canales de comunicación son controlados por el motor de procesado del cliente, no directamente por el cliente como se produce tradicionalmente. El motor de procesado del cliente puede usar canales de comunicación gestionados, para mantener la comunicación en curso con uno o más dispositivos integrados de una manera ininterrumpida que resulta invisible para el usuario. Los canales de comunicación gestionados se pueden implementar con una variedad de técnicas, tales como la XHR (XMLHttpRequest) y la manipulación de documentos. Con la manipulación de documentos, el motor de procesado del cliente modifica contenido existente (por ejemplo, HTML, XHTML, etcétera), lo cual provoca que el cliente realice una solicitud de comunicación al dispositivo integrado. La manipulación de documentos se logra a través de técnicas tales como el método document.write () de JavaScript, modificaciones en el Modelo de Objeto de Documento, y modificaciones en la propiedad innerHTML del documento.
El motor de procesado del cliente analiza sintácticamente cada archivo de plantillas estáticas y se comunica con el dispositivo integrado usando uno o más canales de comunicación gestionados, para solicitar, recibir, y/o presentar conjuntos de datos dinámicos, que son usados por el motor de procesado del cliente conjuntamente con archivos de plantillas estáticas para generar, procesar, transformar, manipular, y/o acumular contenido así como realizar otras tareas computacionales.
El rebote de archivos se puede lograr usando, por ejemplo, el protocolo HTTP, para enviar archivos al dispositivo integrado en una serie de uno o más paquetes que el dispositivo integrado simplemente hace “rebotar” de vuelta al cliente. El dispositivo integrado únicamente conserva un paquete dado durante el tiempo que se tarda en hacer rebotar ese paquete hacia el cliente, después de lo cual el paquete se puede descartar. Los paquetes pueden tener un tamaño arbitrario, y el dispositivo integrado únicamente necesita reservar recursos de memoria suficientes para almacenar en memoria intermedia un único paquete cada vez (es decir, el dispositivo integrado no necesita almacenar el archivo completo o ni siquiera una parte significativa del mismo).
Los archivos que se leen desde el ordenador anfitrión y/o desde sistemas de archivos accesibles para el ordenador anfitrión (por ejemplo, usando la carga de archivos basada en formularios HTML) haciendo uso del rebote de archivos están totalmente disponibles para el motor de procesado del cliente, el cual puede manipular, transformar, y/o acceder de manera selectiva a su contenido como un proxy para el dispositivo integrado.
Los archivos que se escriben en el ordenador anfitrión y/o en sistemas de archivos accesibles para el ordenador anfitrión (por ejemplo, usando el encabezamiento Disposición de Contenido de HTTP) haciendo uso del rebote de archivos se generan típicamente por medio del motor de procesado del cliente a partir de archivos de plantillas estáticas y/o conjuntos de datos dinámicos. Los conjuntos de datos dinámicos se pueden enviar por flujo continuo desde el dispositivo integrado al cliente a medida que se producen los datos subyacentes, haciendo que, desde la perspectiva del dispositivo integrado, esto resulte transitorio. Mientras se generan archivos, el motor de procesado del cliente puede manipular y/o transformar contenido en nombre del dispositivo integrado.
El rebote de archivos puede reducir drásticamente los recursos requeridos por un dispositivo integrado para leer, acceder a, generar, y escribir archivos arbitrariamente grandes desde y en el ordenador anfitrión.
Estos y otros aspectos de la invención se pondrán más claramente de manifiesto a partir de la siguiente descripción y los dibujos adjuntos.
Breve descripción de los dibujos
La invención se describe haciendo referencia a varias formas de realización que se ilustran en los dibujos y siguiendo la descripción detallada proporcionada a continuación.
La FIG. 1 es un diagrama de bloques que muestra una vista de nivel superior de dispositivos integrados conectados en red y ordenadores anfitriones con clientes.
La FIG. 2 es un diagrama de bloques que muestra relaciones entre elementos principales del sistema.
La FIG. 3 es un diagrama de bloques que muestra subcomponentes del motor de procesado del cliente.
La FIG. 4 es un ejemplo de un conjunto de datos dinámicos que contiene datos de tiempo real generados por un dispositivo integrado.
La FIG. 5 es un ejemplo de un archivo de plantillas estáticas abstractas.
La FIG. 6 es un ejemplo de contenido generado por el motor de procesado del cliente a partir del archivo de plantillas estáticas abstractas de la FIG. 5 y el conjunto de datos dinámicos de la FIG. 4.
La FIG. 7 muestra el contenido de la FIG. 6 según es reproducido por un navegador web.
La FIG. 8 es un ejemplo de un archivo de plantillas estáticas literales para generar un documento de Formato de Texto Enriquecido.
La FIG. 9 es el contenido generado por el motor de procesado del cliente a partir del archivo de plantillas estáticas literales de la FIG. 8 y el conjunto de datos dinámicos de la FIG. 4.
La FIG. 10 muestra el contenido de la FIG. 9 según es reproducido por un procesador de texto.
La FIG. 11 es un diagrama de secuencias que muestra etapas para generar contenido con elementos tanto estáticos como dinámicos.
La FIG. 12 es un diagrama de secuencias que muestra etapas para usar el rebote de archivos con el fin de almacenar en el ordenador anfitrión contenido generado en el cliente.
La FIG. 13 es un diagrama de secuencias que muestra etapas para usar el rebote de archivos con el fin de cargar en el cliente un archivo accesible para el ordenador anfitrión (pero no directamente accesible para el cliente).
Descripción detallada
Aunque la presente invención puede materializarse en formas de realización de muchas maneras diferentes, en los dibujos se muestra, y en la presente memoria se describirá detalladamente, una forma de realización preferida de la invención, entendiendo que la presente exposición debe considerarse como una ejemplificación de los fundamentos de la invención y no pretende limitar el amplio aspecto de la invención a formas de realización ilustradas.
Varias formas de realización de la invención proporcionan un método y un sistema para permitir que dispositivos integrados de recursos limitados, conectados en red (a los que, a continuación, se hará referencia simplemente como “dispositivos integrados”) aprovechen los recursos de memoria y procesado de clientes, tales como navegadores web (a los que, en lo sucesivo, se hará referencia como “clientes”), que están instalados en dispositivos computacionales anfitriones, tales como ordenadores personales o clientes ligeros (a los que, en lo sucesivo, se hará referencia como “ordenadores anfitriones”), de tal manera que se superen restricciones de recursos internos de los dispositivos integrados. En la FIG. 1 puede verse una vista de nivel superior, que muestra una pluralidad de dispositivos integrados 102, y una pluralidad de clientes 104 en ordenadores anfitriones 106, conectados a una red de comunicaciones compartida (es decir, común) 108.
La capacidad de usar un navegador web convencional como cliente 104 para interaccionar con el dispositivo integrado 102 hace que la solución ocupe un “espacio cero” desde la perspectiva del ordenador anfitrión 106 – no es necesario instalar ningún software personalizado puesto que la gran mayoría de ordenadores anfitriones tienen dichos clientes preinstalados.
Para minimizar el procesado realizado por el dispositivo integrado 102, el dispositivo integrado adopta la función de un simple servidor de archivos y datos que entrega dos tipos básicos de información, tal como puede observarse en la FIG. 2:
•
Archivos de recursos estáticos 202 tales como JavaScript y XML
•
Conjuntos de datos dinámicos 204 tales como datos de tiempo real, en un formato compacto tal como JSON (Notación de Objetos de JavaScript)
Para ser considerado como “archivo” a efectos de esta descripción, no es necesario que un recurso estático esté almacenado en un sistema de archivos tradicional. Por ejemplo, un recurso estático se podría almacenar como un objeto de algún tipo (por ejemplo, una secuencia de bytes) en memoria flash.
En el caso de archivos de recursos estáticos 202, el dispositivo integrado 102 simplemente transmite estos archivos al cliente 104 cada vez que los mismos son solicitados. No realiza ningún procesado significativo sobre los archivos más allá de la transmisión. Los archivos de recursos estáticos se pueden almacenar en memoria flash del dispositivo integrado, y se pueden transmitir como una secuencia de “paquetes” pequeños hacia el cliente, minimizando de este modo el uso de recursos de la RAM.
En el caso de conjuntos de datos dinámicos 204, el dispositivo integrado 102 transmite datos en un formato sencillo y compacto, tal como el formato JSON mostrado en la FIG. 4.
Haciendo referencia a la FIG. 2, el procesado de conjuntos de datos dinámicos 204 por parte del dispositivo integrado 102 se puede minimizar representando cada elemento de datos de una manera que sea muy parecida a su representación interna nativa en el dispositivo integrado. Por ejemplo, en el conjunto de datos dinámicos de la FIG. 4, el elemento de datos fecha/hora 404 tiene un valor de 202809600, lo cual representa el número de segundos desde el cambio de siglo (segundos desde 1/1/2000 12:00 AM), que, en este ejemplo, es también la representación interna de la fecha/hora del dispositivo integrado. El motor de procesado del cliente puede ser capaz de dar formato a este elemento de datos de muchas maneras diferentes, tales como 5/6/2006, 2006-06-05T08:00:00, ó 5 de junio de 2006 8:00 AM. Por ejemplo, el motor de procesado de cliente da formato a la fecha/hora 404 como 5/6/2006 8:00 AM dentro del subtítulo 704 (FIG. 7) y el subtítulo 1002 (FIG. 10).
Haciendo referencia a la FIG. 2, el dispositivo integrado 102 se centra en servir archivos y datos sin procesar en lugar de centrarse en la generación de contenido final (por ejemplo, páginas web XHTML, informes de Formato de Texto Enriquecido, etcétera). El motor de procesado del cliente 206 es responsable de transformar los archivos de plantillas estáticas 208 y los conjuntos de datos dinámicos 204 que recibe desde el dispositivo integrado para producir el contenido generado 212. Esta división de responsabilidades se aprovecha del hecho de que los ordenadores anfitriones 106, y los clientes 104 que se ejecutan en ellos, típicamente tienen unos recursos de memoria y de procesado bastante mayores que los dispositivos integrados, con frecuencia multiplicados por órdenes de magnitud.
De este modo, adoptando la función de un servidor básico de archivos y datos tal como se ha descrito anteriormente, el dispositivo integrado puede prestar servicio a muchos clientes con pocos recursos. Adicionalmente, múltiples clientes pueden procesar y manipular simultáneamente archivos y datos servidos desde un único dispositivo integrado. El resultado final es un sistema altamente escalable que maximiza el número de clientes que puede soportar simultáneamente un dispositivo integrado, y que mejora significativamente la calidad de contenido que se puede generar.
Es importante enfatizar que el dispositivo integrado 102 no es responsable de la generación de contenido. No genera interfaces de usuario, interfaces de diagnóstico, pantallas de información, informes, archivos de configuración, etcétera. Esa responsabilidad queda delega al cliente 104 a través del motor de procesado del cliente
206. Los archivos y datos servidos por el dispositivo integrado son procesados, transformados, manipulados, y combinados por el motor de procesado del cliente para generar varias formas de contenido 212. Y, tal como se ilustra en la FIG. 2, el motor de procesado del cliente 206 puede ser almacenado en memoria caché por el cliente 104, de modo que únicamente es necesario cargarlo desde el dispositivo integrado una vez por cliente.
Es también importante enfatizar que, aunque esta descripción se centra en la generación de contenido del lado del cliente, al cliente también se le pueden delegar otras tareas de procesado (por ejemplo, procesado intensivo (crunching) de números, análisis de datos, y validación de datos).
Existen cuatro elementos principales que interaccionan y que son compartidos entre el dispositivo integrado 102 y el cliente 104: archivos de plantillas estáticas 208, conjuntos de datos dinámicos 204, motor de procesado del cliente 206, y canales de comunicación gestionados 210.
Archivos de plantillas estáticas
El primer elemento es el archivo de plantillas estáticas 208. Cada archivo de plantillas estáticas se almacena en el dispositivo integrado 102 (por ejemplo, en memoria flash) y se transfiere al cliente 104 según sea necesario. Puesto que cada archivo de plantillas estáticas es un archivo de recursos estáticos, el dispositivo integrado simplemente lo lee de su memoria y lo transmite al cliente. No es necesario ningún procesado adicional significativo en el dispositivo integrado. Típicamente, habrá una pluralidad de archivos de plantillas estáticas almacenados en el dispositivo integrado.
Desde la perspectiva del cliente 104, un archivo de plantillas estáticas 208 proporciona un conjunto de instrucciones de procesado. Por ejemplo, un archivo de plantillas estáticas puede contener instrucciones que se pueden usar para generar una página web, o un informe, o puede contener instrucciones computacionales generales. Los archivos de plantillas estáticas se escriben generalmente de una manera sencilla y compacta que pueda ser analizada sintácticamente de forma fácil para generar contenido o realizar otro procesado. El XML es un formato lógico para archivos de plantillas estáticas, ya que los documentos XML pueden resultar tan sencillos o complejos como se necesite para una aplicación particular, y el XML es analizado sintácticamente de manera fácil por clientes tales como navegadores web.
La FIG. 5 muestra un ejemplo de un archivo de plantillas estáticas que se podría usar para generar una página web, la FIG. 6 muestra contenido XHTML correspondiente generado por el motor de procesado del cliente, y la FIG. 7 muestra la página web generada, tal como aparece en un navegador web. De modo similar, la FIG. 8 muestra un ejemplo de un archivo de plantillas estáticas usado específicamente para generar un informe de Formato de Texto Enriquecido, la FIG. 9 muestra contenido correspondiente de Formato de Texto Enriquecido generado por el motor de procesado del cliente, y la FIG. 10 muestra el informe generado tal como aparece en un procesador de texto. En ambos casos, la fuente de datos dinámicos es el conjunto de datos dinámicos de la FIG. 4.
Los archivos de plantillas estáticas pueden proporcionar instrucciones de procesado que son abstractas (es decir, que describen el resultado final deseado sin proporcionar instrucciones explícitas sobre cómo lograrlo) y/o literales (es decir, que describen explícitamente cómo lograr el resultado final deseado).
El archivo de plantillas estáticas mostrado en la FIG. 5 contiene instrucciones abstractas que se pueden usar para generar la página web mostrada en la FIG. 7. Algunos de los elementos y atributos clave son los siguientes:
•
El atributo de etiqueta 504 (FIG. 5) se usa para proporcionar etiquetas de texto para muchas partes de la página web mostrada en la FIG. 7, incluyendo el título 702, el subtítulo 704, el recuadro de variables 706 (cada recuadro de variables agrupa una colección de pares relacionados de nombre/valor), y la variable 708 (cada variable representa un único par nombre/valor).
•
Haciendo referencia de nuevo a la FIG. 5, el atributo de índice 502 identifica un elemento de datos de un conjunto de datos dinámicos asociado a insertar en la página web (por ejemplo, como la parte de valor de un par de nombre/valor). Este atributo es solamente necesario si el orden en el que se usan los elementos de datos del conjunto de datos dinámicos dentro del archivo de plantillas estáticas es diferente de su orden en el conjunto de datos dinámicos. Por ejemplo, el atributo de índice 502 en el elemento de título, que tiene un valor de índice de “0”, identifica y estaría asociado al elemento de datos “Línea de Ensamblaje 12” 402 (FIG. 4) del conjunto de datos dinámicos. Debe observarse que el índice tiene base en cero.
•
El atributo de formato 506 se usa para proporcionar instrucciones de formateo para elementos de datos. En este ejemplo, la convención de instrucciones de formateo (por ejemplo, “#0.00%”) es muy similar a los códigos de formato personalizado usados en el producto de hojas de cálculo Excel® de Microsoft Corporation.
•
El elemento de pie de página 508 es una instrucción abstracta usada para indicar que se debería dibujar un pie de página en la parte inferior de la misma. Un identificador de pie de página individual resulta adecuado para aplicaciones que usan un pie de página uniforme en parte o en la totalidad de las páginas, en cuyo caso la generación completa del pie de página la puede realizar el motor de procesado del cliente. Esto ilustra otra ventaja del uso de archivos de plantillas estáticas – las instrucciones de procesado abstractas pueden hacer que resulte más sencillo diseñar el contenido, y el motor de procesado del cliente se puede usar para proporcionar un grado de uniformidad en el aspecto y la funcionalidad del contenido generado. Un ejemplo de funcionalidad generada por un motor de procesado del cliente es el hiperenlace 602 (FIG. 6) incluido en el pie de página generado.
•
Los elementos de recuadro_variables 512 y panel_apilamiento 510 son otros ejemplos de instrucciones abstractas. Un recuadro_variables describe un cierto tipo de objeto de presentación (en este caso, un grupo de pares nombre/valor relacionados, donde cada par nombre/valor es un elemento variable), y un panel_apilamiento describe cómo distribuir objetos de presentación (en este caso horizontalmente).
El archivo de plantillas estáticas mostrado en la FIG. 8 usa instrucciones literales para describir el informe de Formato de Texto Enriquecido (RTF) mostrado en la FIG. 10. El archivo ejemplificativo de plantillas estáticas de la FIG. 8 soporta un formato de informe que consta de contenido de elemento de encabezamiento 802 que se sitúa en el comienzo del informe, contenido de elemento de cuerpo_registro 808 que se repite para cada “registro de datos”, contenido de elemento de separador_registros 806 que se sitúa entre cada registro de datos, y contenido de elemento de pie de página 804 que se sitúa en el mismo final del informe. De este modo, el archivo ejemplificativo de plantillas estáticas de la FIG. 8 se podría usar para generar un informe de una sola página o un informe de 1.000
páginas. Por brevedad, la FIG. 9 y la FIG. 10 representan un informe de una sola página generado a partir del registro de datos individual mostrado en el conjunto de datos dinámicos de la FIG. 4. La mayor parte del archivo ejemplificativo de plantillas estáticas de la FIG. 8 es contenido RTF literal que se copiará en el informe. Algunos de los elementos y atributos clave son los siguientes:
•
El elemento de encabezamiento 802 y el elemento de pie de página 804 contienen texto literal que se situará en el comienzo y el final, respectivamente, del informe generado. De manera similar, el elemento de separador_registros 806 contiene texto literal que se situará entre registros individuales (pero antes del primer registro y no después del último registro).
•
El elemento de cuerpo_registro 808 contiene principalmente texto literal que se copia directamente en el informe, eliminando cualquier espacio en blanco anterior y posterior.
•
El elemento de definición 810 y el elemento de inserción 812 proporcionan un mecanismo sencillo usado para evitar la repetición de texto literal, y de este modo reducen el tamaño de un archivo de plantillas estáticas. El elemento de definición captura un bloque de texto literal en su punto de primer uso de manera que se pueda repetir (es decir, insertar) posteriormente con un elemento de inserción.
•
El elemento de variable 814 marca cada lugar en el que se van a insertar datos dinámicos con formato en el informe. Debe observarse que no se requiere un atributo de etiqueta 504 (FIG. 5) puesto que la etiqueta se incluye como parte del texto literal, y no se requiere un atributo de índice 502 (FIG. 5) ya que el orden de los elementos de datos del elemento de variable es el mismo que su orden en el conjunto de datos dinámicos. Debe observarse también que el atributo de formato 506 (FIG. 8) tiene el mismo comportamiento que el atributo de formato 506 (FIG. 5).
Un archivo de plantillas estáticas podría incluir referencias a otros archivos de plantillas estáticas (o incluso a sí mismo), permitiendo de este modo un planteamiento “modular” para la construcción de conjuntos de instrucciones de procesado para el motor de procesado del cliente. Como archivos de recursos estáticos, en el dispositivo integrado se pueden almacenar archivos de plantilla estáticas en forma comprimida (por ejemplo, el formato zip de GNU, al que se hace referencia también como formato gzip), lo cual reduce el espacio ocupado por la memoria en el dispositivo integrado. Los mismos también se pueden transferir al cliente en forma comprimida (por ejemplo, formato gzip) para reducir el tiempo de transferencia y conservar recursos. El espacio ocupado por la memoria en el dispositivo integrado se puede reducir todavía más cargando archivos de plantillas estáticas desde una o más fuentes que no sean el dispositivo integrado (por ejemplo, desde un anfitrión externo).
Los archivos de plantillas estáticas también se pueden crear y/o modificar en el cliente. Por ejemplo, además de analizar sintácticamente archivos de plantillas estáticas, el motor de procesado del cliente puede contener lógica para generarlos (típicamente de manera conjunta con información recopilada a través de una interfaz de usuario). Los archivos de plantillas estáticas creados y/o modificados de tal manera se pueden almacenar dentro del dispositivo integrado y/o se pueden interpretar inmediatamente por medio del motor de procesado del cliente (por ejemplo, para una ejecución “de una sola vez” o para proporcionar una característica de vista previa). Los archivos de plantillas estáticas creados y/o modificados de tal manera, que a continuación se almacenan dentro del dispositivo integrado, siguen siendo “estáticos” desde la perspectiva tanto del dispositivo integrado (que no necesita realizar ningún procesado significativo sobre ellos) como del cliente (que puede almacenarlos en memoria caché).
Debe observarse que, aunque la FIG. 5 muestra instrucciones de archivos de plantillas estáticas abstractas, que se usan para generar XHTML, y la FIG. 8 muestra instrucciones de archivos de plantillas estáticas literales para generar RTF, esto simplemente tiene fines ilustrativos. No hay nada del XHTML que requiera instrucciones de archivos de plantillas estáticas abstractas, y no hay nada del RTF que requiera instrucciones de archivos de plantillas estáticas literales. El XHTML, el RTF y otros tipos de contenido (por ejemplo, diagramas, gráficos, informes, documentos, hojas de cálculos, páginas web, etcétera) se pueden generar usando instrucciones de archivos de plantillas estáticas abstractas y/o literales.
Por otra parte, las instrucciones de archivos de plantillas estáticas abstractas, mostradas en la FIG. 5, no se limitan a la generación de XHTML. Se podría usar el mismo archivo de plantillas estáticas para generar un informe RTF similar al mostrado en la FIG. 10, simplemente ordenando al motor de procesado del cliente que genere RTF en lugar de XHTML. De esta manera, un archivo dado de plantillas estáticas y el conjunto de datos dinámicos asociado se podrían usar para generar muchos tipos diferentes de contenido (por ejemplo, informes, documentos, hojas de cálculo, páginas web, etcétera), siempre que el motor de procesado del cliente soporte los tipos de contenido objetivo).
Tal como se ha descrito previamente, el dispositivo integrado puede delegar al cliente otras tareas además de la generación de contenidos. Por ejemplo, un archivo de plantillas estáticas puede contener instrucciones para recuperar un conjunto de datos dinámicos, transformarlo, y a continuación presentarlo de vuelta al dispositivo integrado. Esta capacidad permite que clientes funcionen como nodos en una red informática distribuida, con el dispositivo integrado transfiriendo tareas intensivas, desde el punto de vista computacional, a uno o más clientes que proporcionen soporte de procesado distribuido para un dispositivo integrado dado en cualquier instante de tiempo dado.
La FIG. 5 y la FIG. 8 se proporcionan con fines ilustrativos, y no pretenden fijar límites o restricciones al alcance de las instrucciones de procesado de archivos de plantillas estáticas. Por ejemplo, las instrucciones de procesado de archivos de plantillas estáticas se podrían usar para implementar un sistema de acontecimientos con el fin de responder a acciones de usuario o para implementar un sistema para entradas, por parte del usuario, que validen números (por ejemplo, especificar valores permitidos mínimo, máximo, y especial) y/o cadenas de texto (por ejemplo, especificar patrones de texto permitidos). Un punto importante es que los archivos de plantillas estáticas están destinados y diseñados para funcionar como plantillas de “producción en serie” que proporcionan instrucciones para generar contenido y/o instrucciones de procesado computacional al motor de procesado del cliente, con el fin de minimizar recursos requeridos dentro del dispositivo integrado y con el fin de transferir trabajo desde el dispositivo integrado al cliente.
Conjuntos de datos dinámicos
Haciendo referencia a la FIG. 2, el segundo elemento es el conjunto de datos dinámicos 204. Cada conjunto de datos dinámicos contiene un conjunto (es decir, una “colección” o “paquete”) de datos que se intercambia entre el dispositivo integrado 102 y el cliente 104. A diferencia de los archivos de plantillas estáticas, que son recursos estáticos, cada conjunto de datos dinámicos es generado dinámicamente por el dispositivo integrado (o cliente). Son formatos ejemplificativos para conjuntos de datos dinámicos el JSON y el XML. El JSON es sencillo de analizar sintácticamente y de generar, puede representar objetos de datos de complejidad arbitraria, y se diseñó específicamente para proporcionar una representación compacta de datos. La FIG. 4 es un ejemplo de un conjunto de datos dinámicos simple en formato JSON con diez elementos de datos (separado cada uno de ellos por una coma), el cual se usa para generar la página web de la FIG. 7 y el informe de la FIG. 10. Tal como puede observarse en la FIG. 4, el conjunto ejemplificativo de datos dinámicos de JSON está compuesto casi en su totalidad por datos puros.
El uso de una representación compacta y (casi) pura de datos y la minimización del procesado de datos dinámicos por parte del dispositivo integrado, tal como se ha descrito previamente, son muy importantes para optimizar (es decir, aumentar) la velocidad de transferencia de conjuntos de datos dinámicos y mejorar la escalabilidad y la sensibilidad del dispositivo integrado. Por ejemplo, un informe que muestre resultados del rendimiento de fabricación por turno durante el último año puede contener datos para 1.000 turnos, donde cada turno viene representado por una parte (por ejemplo, un registro de datos) de un conjunto grande de datos dinámicos (por ejemplo, múltiples registros de datos). Alternativamente, una página web que muestre resultados actuales de fabricación se puede actualizar múltiples veces por segundo, generando de este modo muchos miles de transacciones de conjuntos de datos dinámicos en una hora. En ambos casos, es probable que la cantidad de datos dinámicos generados sea significativa, y por lo tanto, es probable también que lo que se ahorra con una representación de datos compacta sea también significativo. El espacio ocupado en memoria de un conjunto de datos dinámicos se puede reducir adicionalmente comprimiéndolo antes de transferirlo al cliente (por ejemplo, usando una compresión gzip).
Una representación compacta de datos conserva RAM y otros recursos dentro del dispositivo integrado. El uso de recursos dentro del dispositivo integrado se puede reducir adicionalmente generando la respuesta a una solicitud de conjunto de datos dinámicos de cliente en múltiples partes, de tal manera que solamente una parte de la respuesta se almacena en la memoria del dispositivo integrado en un momento cualquiera. Por ejemplo, un conjunto de datos dinámicos que contiene diez registros de datos se puede generar en diez partes, una para cada registro, de tal manera que solamente uno de los diez registros de datos de la respuesta se almacene en la RAM del dispositivo integrado en un momento cualquiera.
La información necesaria para construir una solicitud de conjunto de datos dinámicos puede estar asociada implícitamente a un archivo de plantillas estáticas o se puede incluir explícitamente dentro de un archivo de plantillas estáticas. Los ejemplos de archivo de plantillas estáticas de la FIG. 5 y la FIG. 8 se basan ambos en una asociación implícita con el recurso del archivo de plantillas estáticas (nada del archivo de plantillas estáticas identifica explícitamente la solicitud de conjunto de datos dinámicos). La inclusión explícita de una solicitud de conjunto de datos dinámicos dentro de un archivo de plantillas estáticas puede ser tan sencilla como incluir un elemento conjunto_datos_dinámicos con un atributo de consulta tal como query=”SELECT * FROM Table1”. Alternativamente, el archivo de plantillas estáticas puede remitir explícitamente a uno o más datos dentro del dispositivo integrado. Por ejemplo, el atributo de índice 502 (FIG. 5) se podría modificar para remitir a un dato particular dentro del dispositivo integrado, construyendo automáticamente el motor de procesado del cliente una consulta de conjunto de datos dinámicos a partir de los atributos de índice.
Aunque no es necesario, la especificación y generación de conjuntos de datos dinámicos se puede simplificar organizando lógicamente en tablas datos dentro del dispositivo integrado (como en una base de datos). Los datos a continuación se pueden consultar usando sentencias SELECT SQL convencionales incluso si la gestión de datos subyacentes en el dispositivo integrado no es una base de datos siempre que el dispositivo integrado incluya un “intérprete” adecuado para el SQL. Esto es consistente con la interpretación del dispositivo integrado como un servidor de datos. Además, usando la organización tabular, se puede referenciar cualquier dato en el dispositivo integrado con un simple identificador compuesto por una ID de tabla, una ID de fila, y una ID de columna.
Un único conjunto de datos dinámicos puede contener una cantidad arbitraria de datos, que pueden estar organizados linealmente (por ejemplo, como datos tabulares) o jerárquicamente (por ejemplo, como un “objeto” de complejidad arbitraria).
Los conjuntos de datos dinámicos pueden ser generados por el dispositivo integrado y transmitidos al cliente, o alternativamente pueden ser generados por el cliente y ser transmitidos al dispositivo integrado. Por ejemplo, los datos introducidos en el cliente por el usuario se pueden “enviar” al dispositivo integrado como un conjunto de datos dinámicos.
Los conjuntos de datos dinámicos también se pueden cifrar para proporcionar seguridad de datos, la cual consiga que este sistema resulte adecuado para su uso en aplicaciones de alta seguridad.
Los conjuntos de datos dinámicos pueden ser procesados por el motor de procesado del cliente para generar información nueva a partir de elementos de datos existentes (por ejemplo, calcular sumas y medias) sin necesitar un trabajo adicional del dispositivo integrado. El motor de procesado del cliente puede realizar muchos tipos diferentes de manipulación y transformación de datos, tales como filtrado, clasificación, agrupamiento y resumen. Esta técnica puede ser especialmente útil cuando el cliente acumula datos de múltiples dispositivos integrados tal como se describe posteriormente.
Debe observarse que los métodos y técnicas descritos en la presente memoria se proporcionan con fines ilustrativos, y no pretenden fijar límites o restricciones en el alcance de las operaciones de los conjuntos de datos dinámicos. Un punto importante es que los conjuntos de datos dinámicos están destinados a y diseñados para encapsular el aspecto “dinámico” del contenido con una representación compacta, con el fin de minimizar los recursos requeridos dentro del dispositivo integrado y con el fin de transferir trabajo desde el dispositivo integrado al cliente.
Motor de procesado del cliente
En referencia a la FIG. 2, el tercer elemento es el motor de procesado del cliente 206, que es un archivo de recursos estáticos, o pluralidad de archivos de recursos estáticos, almacenados en el dispositivo integrado 102 (por ejemplo, en memoria flash) y transmitidos al cliente 104 según se requiera. El motor de procesado del cliente es un archivo de recursos estáticos, lo cual significa que el dispositivo integrado simplemente lee el archivo de su memoria y lo transmite al cliente. No es necesario ningún otro procesado significativo en el dispositivo integrado.
Una vez que el mismo ha sido cargado por el cliente 104, el motor de procesado del cliente 206 es un programa ejecutable, tal como un programa JavaScript, que interpreta archivos de plantillas estáticas y lleva a cabo las instrucciones especificadas en los mismos. La ejecución de dichas instrucciones requiere generalmente que el motor de procesado del cliente disponga de capacidades adicionales. En referencia a la FIG. 3, el motor de procesado del cliente puede comprender un núcleo de procesado 302 (que dirige y controla los otros sub-componentes del motor de procesado del cliente), un procesador de archivos de plantillas estáticas 304, un generador de interfaces de usuario 306, un generador de informes 308, un formateador de datos 310, un validador de datos 312, un gestor de canales de comunicación 314, un rebotador de archivos 316 (que memoriza y carga archivos en y desde el ordenador anfitrión y/o sistemas de archivos accesibles para el ordenador anfitrión), y posiblemente componentes adicionales 318. Un punto importante es que el motor de procesado del cliente 206 está explícitamente destinado a y diseñado para minimizar recursos requeridos dentro del dispositivo integrado y para transferir trabajo desde el dispositivo integrado al cliente. De este modo, la FIG. 3 se proporciona con fines ilustrativos, y no pretende fijar límites o restricciones en el alcance del motor de procesado del cliente.
Con el estado actual de la tecnología de clientes, escribir el motor de procesado del cliente en el lenguaje JavaScript y escribir archivos de plantillas estáticas en XML puede proporcionar ventajas significativas, ya que permite que el motor de procesado del cliente se aproveche de capacidades que son nativas para los clientes, tales como la disponibilidad de funcionalidad exhaustiva para analizar sintácticamente, manipular, y trabajar de otro modo con documentos XML, lo cual puede reducir drásticamente la complejidad del motor de procesado del cliente.
El motor de procesado del cliente puede ser tan simple o complejo como requiera una aplicación en particular (es decir, tipo de dispositivo integrado). Por ejemplo, se puede construir un motor importante (aunque limitado) de procesado del cliente con 5 KB ó menos de JavaScript, mientras que uno que sea rico en características podría incluir 50 KB ó más de JavaScript.
El motor de procesado del cliente también se puede diseñar como una serie de módulos (es decir, archivos más pequeños) que se carguen dinámicamente (que se transmitan al cliente bajo demanda). Esto reduce el tiempo de carga inicial para un cliente nuevo. Igual que otros archivos de recursos estáticos, el(los) archivo(s) que comprende(n) el motor de procesado del cliente también se puede(n) almacenar de una manera comprimida (por ejemplo, formato gzip), lo cual reduce tanto el espacio ocupado de memoria en el dispositivo integrado como el tiempo de carga inicial. El espacio ocupado por la memoria en el dispositivo integrado se puede reducir todavía más cargando el motor de procesado del cliente o módulos del mismo desde una o más fuentes que no sean el dispositivo integrado (por ejemplo, desde un anfitrión externo según remitan otros recursos cargados desde el dispositivo integrado).
El motor de procesado del cliente juega un papel central en la mejora de la escalabilidad del sistema, ya que se puede ejecutar simultáneamente en un número cualquiera de clientes. Además, el motor de procesado del cliente realiza tanto tareas de presentación como tareas lógicas comerciales (entre los ejemplos de estas últimas se incluyen gestión de comunicación, realización de validación de datos y manipulación de datos, y generación de informes complejos), lo cual eleva al cliente de ser un medio de entrega de contenido a ser un “nodo” de procesado en un sistema informático distribuido.
Canal de comunicación gestionado
En referencia a la FIG. 2, el cuarto elemento es el canal de comunicación gestionado 210. Los canales de comunicación gestionados son usados por el cliente 104, específicamente el motor de procesado del cliente 206, para comunicarse con uno o más dispositivos integrados. El término “gestionado” se refiere al hecho de que el canal de comunicación es controlado por el motor de procesado del cliente, no directamente por el cliente tal como se produce tradicionalmente. Los canales de comunicación gestionados permiten que el motor de procesado del cliente mantenga la comunicación en curso con uno o más dispositivos integrados, transfiriendo información entre el cliente y el dispositivo integrado de una manera ininterrumpida que es invisible para el usuario, de manera que se proporciona una experiencia superior para el usuario. Por ejemplo, el motor de procesado del cliente puede usar un canal de comunicación gestionado para recuperar información que se usa con el fin de actualizar dinámicamente una página web que muestra datos de rendimiento de fabricación en tiempo real (por ejemplo, actualizándose diez veces por segundo) sin parpadeos, actualizaciones de páginas u otros artefactos visuales.
Los canales de comunicación gestionados 210 también pueden ser usados por el cliente para recuperar código ejecutable (tal como JavaScript) del dispositivo integrado 102 “bajo demanda” (es decir, solo cuando realmente sea necesario), tal como cuando el motor de procesado del cliente 206 está diseñado en forma de una serie de módulos cargados dinámicamente (tal como se ha descrito previamente).
Existen varios métodos diferentes que se pueden usar para implementar un canal de comunicación gestionado. Dos métodos muy útiles son el XMLHttpRequest (al que se hace referencia también como XHR) y la manipulación de documentos.
El XHR es una norma de facto para la comunicación cliente-servidor HTTP y está disponible en varias formas para las versiones actuales de clientes populares, tales como los navegadores web Internet Explorer® 6 e Internet Explorer® 7 de Microsoft Corporation, los navegadores web Firefox® 1.5 y Firefox® 2 de Mozilla Corporation, el navegador web Safari™ 2 de Apple Inc., y el navegador web Opera™ 9 de Opera Software ASA. El XHR se puede usar para solicitar datos del dispositivo integrado (usando GET) o para enviar datos al dispositivo integrado (usando POST). Además, las solicitudes XHR se pueden designar o bien como síncronas o bien como asíncronas según se necesite. No obstante, el XHR se limita en general al acceso a recursos en el dominio local.
El XHR también se puede usar indirectamente para cargar código ejecutable bajo demanda recuperando ese código en forma de una cadena de texto. Por ejemplo, lo siguiente ilustra una técnica JavaScript conocida de plataforma cruzada que consigue que el código de una cadena de texto forme parte del ámbito global (en donde es accesible para el motor de procesado del cliente):
función añadir_a_ámbito_global (cadena_código)
{
var global = esto;
si (window.execScript)
{
window.execScript (cadena_código);
return null;
}
return global.eval ? global.eval (cadena_código): eval (cadena_código); }
Por otro lado, la manipulación de documentos resulta particularmente útil si se requiere un acceso a dominio no local (es decir, cruzado). La manipulación de documentos es una técnica menos conocida pero muy útil para la comunicación gestionada, en la que se descarga un recurso añadiendo dinámicamente un identificador nuevo a una página web existente, en donde dicho identificador remite al recurso deseado. Por ejemplo, se puede descargar un archivo JavaScript añadiendo dinámicamente un identificador <script> a la página actual, tal como <script src=”http://192.168.1.240/data_1138.js”>. El DOM del W3C (Modelo de Objeto de Documento del Consorcio de la Malla Multimedia Mundial), el método document.write() de JavaScript, y la propiedad innerHTML se pueden usar todos ellos para realizar la manipulación de documentos.
En referencia a la FIG. 1, un uso importante de la manipulación de documentos en esta forma de realización es solicitar conjuntos de datos dinámicos de múltiples dispositivos integrados 102 (es decir, de múltiples dominios y/o direcciones IP). Esto permite que cualquier cliente individual 104 con un motor de procesado del cliente 206 (FIG. 2) solicite, manipule, transforme, acumule, y presente datos de una pluralidad de dispositivos integrados. Por ejemplo, el dispositivo integrado puede servir un conjunto de datos dinámicos en forma de un archivo JavaScript generado dinámicamente dando formato a los datos como JSON y asignando esos datos formateados a una variable JavaScript (consiguiendo de este modo que los datos formen parte de una sentencia JavaScript completa). Cada vez que se remita a dicho archivo en el cliente (por ejemplo, a través de un identificador <script> generado dinámicamente tal como se ha descrito anteriormente), el mismo será solicitado automáticamente desde el dispositivo integrado que se especifica en el URL del recurso (es decir, en el atributo src del identificador <script>).
Los canales de comunicación gestionados están vinculados solo de manera moderada con los métodos de comunicación antes descritos. Los mismos se pueden adaptar fácilmente para usar otros métodos a medida que evolucionen las normas (de facto u otras) de Internet, tales como la norma W3C propuesta “Document Object Model (DOM) Level 3 Load and Save Specification”.
Algunas de las técnicas antes descritas funcionarán con una comunicación tanto síncrona como asíncrona. Se recomienda la comunicación asíncrona ya que en general proporciona una experiencia superior para el usuario. Debe observarse que esto constituye una preferencia, no un requisito. En muchos casos, el motor de procesado del cliente seguirá funcionando de manera eficaz si los canales de comunicación gestionados usan una comunicación síncrona en lugar de una comunicación asíncrona.
Debe observarse que los métodos y técnicas descritos en la presente memoria se proporcionan con fines ilustrativos, y no pretenden fijar límites o restricciones en el alcance de las operaciones de los canales de comunicación gestionados. Un punto importante es que los canales de comunicación gestionados actúan como enlaces de comunicación bidireccionales entre el motor de procesado del cliente que se ejecuta en un cliente y uno
o más dispositivos integrados. Los mismos se usan para intercambiar información que soporta los objetivos de minimizar los recursos requeridos dentro del dispositivo integrado y transferir trabajo desde el dispositivo integrado al cliente.
Interacción de elementos principales
Para entender mejor cómo interaccionan el motor de procesado del cliente, los archivos de plantillas estáticas, los conjuntos de datos dinámicos, y los canales de comunicación gestionados, se muestran las etapas necesarias para generar una página web con elementos tanto estáticos como dinámicos, en forma de un diagrama de secuencias en la FIG. 11, y las mismas se describen de forma detallada a continuación.
En una forma de realización de la invención, según se ilustra en la FIG. 11, se genera contenido puramente estático de la manera siguiente:
1.
El usuario solicita una página web específica (por ejemplo, siguiendo un enlace o introduciendo directamente un URL) (etapa 1102).
2.
El cliente se conecta el dispositivo integrado y solicita la página web específica (URL) (etapa 1104).
3.
El dispositivo integrado transmite la página web solicitada al cliente. A esta página se le hace referencia como página de “arranque”, puesto que en lugar del contenido solicitado por el usuario, contiene los medios para generar este contenido, a través de referencias al motor de procesado del cliente, uno o más archivos de plantillas estáticas, y opcionalmente uno o más conjuntos de datos dinámicos y otros recursos (etapa 1106).
4.
La página de arranque contiene una referencia al motor de procesado del cliente (por ejemplo, a través de un identificador <script> HTML), que provoca que el cliente solicite el motor del procesado del cliente del dispositivo integrado (etapa 1108).
5.
El dispositivo integrado transmite el motor de procesado del cliente al cliente (etapa 1110).
6.
La página de arranque recibida en el punto 3 anterior contiene una llamada a la función de entrada en el motor de procesado del cliente, que provoca que el cliente llame a la función de entrada y comience a ejecutar el motor de procesado del cliente (etapa 1112).
7.
La página de arranque recibida en el anterior punto 3 especifica el URL de un archivo de plantillas estáticas que contiene instrucciones para generar el contenido deseado, y el motor de procesado del cliente solicita ese archivo de plantillas estáticas usando un canal de comunicación gestionado (etapa 1114).
8.
El dispositivo integrado transmite el archivo de plantillas estáticas al cliente (etapa 1116).
9.
El motor de procesado del cliente analiza sintácticamente el archivo de plantillas estáticas y genera el contenido estático asociado de manera correspondiente a partir de instrucciones de procesado abstractas y/o literales (etapa 1118).
10.
El contenido estático está preparado (etapa 1120).
Cuando el contenido incluye elementos dinámicos, se realizan las siguientes etapas adicionales:
11.
El motor de procesado del cliente identifica un requisito de conjunto de datos dinámicos asociado al archivo de plantillas estáticas (por ejemplo, una sentencia SELECT SQL que está incluida en el archivo de plantillas estáticas). El requisito de conjunto de datos dinámicos puede ser implícito o explícito tal como se ha descrito anteriormente (etapa 1122).
12.
El motor de procesado del cliente usa un canal de comunicación gestionado para solicitar un conjunto de datos dinámicos (etapa 1124).
13.
El dispositivo integrado genera el conjunto de datos dinámicos y lo transmite al cliente (etapa 1126).
14.
El motor de procesado del cliente transforma los datos del conjunto de datos dinámicos basándose en instrucciones de procesado del archivo de plantillas estáticas y acumula los datos transformados y el contenido estático del punto 10 (etapa 1128); y
15.
Para contenido que cambia con el tiempo, tal como una página de rendimiento de fabricación en tiempo real, el motor de procesado del cliente repite los puntos 12 a 14 siempre que la página web se mantenga abierta (etapa 1130).
Las etapas anteriores se centran en las interacciones entre el archivo de plantillas estáticas, el conjunto de datos dinámicos, el motor de procesado del cliente y el canal de comunicación gestionado. En implementaciones reales, es probable que se carguen archivos de recursos estáticos adicionales, tales como archivos CSS (Hojas de Estilo en Cascada), archivos de imágenes, etcétera, o bien directamente, tal como a través de referencias en la página web de arranque, o bien indirectamente como solicitudes de recursos del motor de procesado del cliente a través de un canal de comunicación gestionado. Debe observarse también que una página de arranque puede remitir a más de un archivo de plantillas estáticas, en cuyo caso los puntos 7 a 9 se repetirán para cada archivo de plantillas estáticas. De manera similar, puede haber más de un conjunto de datos dinámicos asociado a un archivo de plantillas estáticas dado, en cuyo caso se repetirán los puntos 11 a 13 hasta que se hayan recibido todos los conjuntos de datos dinámicos. Resultará evidente para los expertos en la materia, que, en las etapas antes descritas, se pueden realizar estas y otras modificaciones sin desviarse con respecto al espíritu y el alcance de esta forma de realización particular.
Haciendo referencia a la FIG. 2, los archivos de recursos estáticos, tales como los archivos de plantillas estáticas 208, el motor de procesado del cliente 206, y otros según se ha mencionado anteriormente, deberían ser almacenados en memoria caché por el cliente 104 siempre que sea posible. El cliente lleva a cabo esto almacenando copias de los archivos de plantillas estáticas, el motor de procesado del cliente, y otros archivos en el ordenador anfitrión 106. Puesto que el recurso es estático y, por lo tanto, no varía, el cliente puede satisfacer solicitudes adicionales para el mismo recurso usando esta copia almacenada, ahorrando tiempo y recursos dentro del dispositivo integrado 102 (que no necesita retransmitir el mismo archivo). El almacenamiento en memoria caché del cliente puede reducir significativamente la carga de trabajo del dispositivo integrado, así como mejorar la sensibilidad del cliente, de manera que es importante que el dispositivo integrado proporcione soporte para el almacenamiento en memoria caché del cliente (por ejemplo, usando encabezamientos HTTP apropiados). Haciendo referencia a la FIG. 11, debe observarse que si la página de arranque transmitida por el dispositivo integrado 102 en la etapa 1106, el motor de procesado del cliente transmitido por el dispositivo integrado en la etapa 1110, y el archivo de plantillas estáticas transmitido por el dispositivo integrado en la etapa 1116 son almacenados en memoria caché por el cliente (tal como debería producirse típicamente), el dispositivo integrado no necesitará transmitir los mismos nuevamente. Debe observarse también que, con el almacenamiento en memoria caché del cliente, el motor de procesado del cliente se recibe una vez y, a continuación, está disponible para cada una de las páginas de arranque cargadas desde el dispositivo integrado.
Haciendo referencia nuevamente a la FIG. 2, debe observarse que el dispositivo integrado 102 no tiene que realizar ningún procesado significativo en relación con su archivo de plantillas estáticas almacenado 208 y los archivos del motor de procesado del cliente 206. Simplemente los transmite al cliente 104. De manera similar, cada conjunto de datos dinámicos 204 requiere un procesado mínimo del dispositivo integrado. Los conjuntos de datos dinámicos son datos (casi) puros con un formateo mínimo; y el motor de procesado del cliente puede leer instrucciones del archivo de plantillas estáticas y transformar los datos de manera correspondiente. Tal como se ha descrito anteriormente, el dispositivo integrado actúa como un servidor de archivos y datos, y el motor de procesado del cliente es responsable de transformar archivos de plantillas estáticas y conjuntos de datos dinámicos en contenido útil. Esta división del trabajo transfiere una gran cantidad de tarea de procesado desde el dispositivo integrado a los clientes de red, mejorando significativamente la escalabilidad de la solución global.
Rebote de archivos
Otra característica de varias formas de realización de la presente invención es la capacidad de leer archivos arbitrariamente grandes del ordenador anfitrión (incluyendo la lectura de dichos archivos de cualesquiera sistemas de archivos accesibles para el ordenador anfitrión) y de escribir archivos arbitrariamente grandes en el ordenador anfitrión (incluyendo la escritura o el almacenamiento de dichos archivos en cualesquiera sistemas de archivos accesibles para el ordenador anfitrión y la abertura de dichos archivos en el ordenador anfitrión). Por ejemplo, el usuario puede desear almacenar un informe generado por el cliente (por ejemplo, un informe generado por el motor de procesado del cliente) en el ordenador anfitrión para acceder al mismo posteriormente o para archivarlo. Como ejemplo adicional, un dispositivo integrado puede necesitar acceder a un archivo que está almacenado en el ordenador anfitrión con el fin de realizar ciertas tareas, pero dispone de limitaciones de recursos que le evitan almacenar el archivo dentro de su memoria.
La implementación de esta característica puede resultar problemática ya que los clientes (por ejemplo, navegadores web) pueden controlar minuciosamente el acceso a sistemas de archivos del ordenador anfitrión por razones de seguridad. La finalidad principal de este control es típicamente evitar que programas potencialmente maliciosos (por ejemplo, JavaScript malicioso) accedan al sistema de archivos. Estas restricciones hacen también que resulte difícil, cuando no imposible, que el motor de procesado del cliente lea y escriba archivos desde y en el ordenador anfitrión por sí mismo, incluso con el permiso explícito del usuario. Los clientes de navegadores web sí permiten típicamente que el usuario conceda permiso para cargar archivos accesibles para el ordenador anfitrión en un servidor HTTP y descargar archivos desde un servidor HTTP al ordenador anfitrión (debería observarse que, en dichas operaciones, podrían participar dispositivos integrados que incluyen servidores HTTP). No obstante, tal como se ha mencionado anteriormente, el dispositivo integrado puede que no disponga de los recursos necesarios para almacenar un archivo completo, o ni siquiera una parte significativa de un archivo, en memoria, ni siquiera durante un periodo de tiempo breve. Esto es así particularmente cuando es deseable que el dispositivo integrado pueda gestionar múltiples archivos de esta manera simultáneamente. Además, tal como se ha mencionado previamente, es necesario un mecanismo para que el contenido (por ejemplo, informes, documentos, hojas de cálculo, etcétera) generado por el motor de procesado del cliente pueda ser almacenado o abierto por el ordenador anfitrión.
La solución a estos problemas es un sistema y un método que afrontan las restricciones de seguridad antes mencionadas, aunque, al mismo tiempo, permitiendo que dispositivos integrados de recursos limitados lean y escriban archivos arbitrariamente grandes desde y en el ordenador anfitrión (con el permiso del usuario).
El rebote de archivos facilita los siguientes escenarios:
•
Los archivos del ordenador anfitrión, con el permiso del usuario, se pueden cargar en el cliente, que, con frecuencia, dispondrá de una memoria órdenes de magnitud mayor que el dispositivo integrado. Una vez cargados dentro del cliente, se puede acceder a los archivos y los mismos se pueden manipular a deseo por medio del dispositivo integrado, usando, como su intermediario, el motor de procesado del cliente.
•
El contenido generado por el cliente (típicamente por medio del funcionamiento del motor de procesado del cliente como proxy para el dispositivo integrado), con el permiso del usuario, se puede almacenar o abrir como un archivo en el ordenador anfitrión.
Con el rebote de archivos, el cliente envía el archivo (es decir, el contenido del archivo) al dispositivo integrado en una serie de uno o más paquetes, que el dispositivo integrado simplemente “hace rebotar” de vuelta al cliente (de aquí el nombre “rebote de archivos”). El dispositivo integrado conserva únicamente un paquete dado durante el tiempo que se tarda en hacer rebotar ese paquete de vuelta al cliente, después de lo cual el paquete se descarta. De este modo, el dispositivo integrado no necesita almacenar el archivo completo, y realiza un procesado mínimo sobre los paquetes. Los paquetes pueden tener un tamaño arbitrario, y el dispositivo integrado únicamente necesita reservar recursos de memoria suficientes para almacenar en memoria intermedia un único paquete cada vez (aunque se puede mejorar el rendimiento almacenando en memoria intermedia simultáneamente múltiples paquetes). Cuando se “hace rebotar” simultáneamente más de un archivo, se dice que cada archivo usa un “canal” de rebote de archivos diferente.
El rebote de archivos se podría realizar haciendo que el cliente envíe un paquete (es decir, una parte del archivo) al dispositivo integrado, de manera que el dispositivo integrado envía el paquete de vuelta al cliente y espera a que el cliente envíe el siguiente paquete, y el proceso se repite hasta que no haya más paquetes a enviar (es decir, se ha “hecho rebotar” el archivo completo). No obstante, no todos los protocolos y/o clientes de comunicación soportan este tipo de comportamiento. Por ejemplo, un protocolo de comunicación según se especifica o según se implementa (tal como el HTTP) podría requerir que el cliente enviase su solicitud completa (es decir, el archivo completo) antes de que el servidor (es decir, el dispositivo integrado) pueda comenzar a enviar su respuesta. Por lo tanto, una solución más generalizada es usar dos conexiones cooperativas para lograr un resultado similar: los paquetes recibidos desde el cliente a través de la primera conexión se devuelven al cliente a través de la segunda conexión, tal como se describe posteriormente y según se ilustra en la FIG. 12 y la FIG. 13.
En una forma de realización de la invención, las etapas para almacenar (es decir, escribir) un archivo generado por el cliente en el ordenador anfitrión se muestran en la FIG. 12, y se describen en líneas generales de forma más detallada posteriormente. Resultará evidente para los expertos en la materia que, en las etapas descritas en el presente caso, se pueden aplicar varias modificaciones sin desviarse con respecto al espíritu y el alcance de esta forma de realización.
1.
El usuario realiza una solicitud que invocará el rebote de archivos de alguna manera específica de la aplicación (etapa 1202).
2.
El motor de procesado del cliente usa un canal de comunicación gestionado para solicitar una ID de canal de rebote de archivos (cada ID de canal reserva recursos en el dispositivo integrado, incluyendo los recursos para dos conexiones HTTP) (etapa 1204).
3.
El dispositivo integrado busca una ID de canal disponible (etapa 1206).
•
Si tiene una ID de canal disponible, marca el canal correspondiente como reservado.
•
Si no tiene una ID de canal disponible, en este momento no se puede realizar un rebote de archivo (se envía una respuesta apropiada al cliente, el cual, a su vez, visualiza un mensaje para el usuario, y el proceso finaliza aquí).
4.
El dispositivo integrado transmite la ID de canal correspondiente al canal reservado en el punto anterior 3 al cliente (etapa 1208).
5.
Si todavía no se ha generado el archivo a almacenar (por ejemplo, un informe), el motor de procesado del cliente realiza cualquier acción necesaria para generar el archivo (etapa 1210).
6.
El motor de procesado del cliente usa un canal de comunicación gestionado para iniciar un POST del archivo generado, junto con la ID de canal y cualesquiera otros metadatos asociados (por ejemplo, nombre de archivo, tamaño de archivo, tipo MIME de archivo, etcétera) hacia el dispositivo integrado. Debe observarse que el dispositivo integrado coloca los datos de archivos (es decir, contenido, no metadatos) incluidos en este POST en una memoria intermedia asociada a la ID de canal especificada (etapa 1212).
7.
El motor de procesado del cliente al mismo tiempo emite una solicitud GET que incluye la ID de canal como parámetro de URL para iniciar la recuperación del archivo que se está haciendo rebotar. Esta solicitud se realiza a través de un marco flotante (iframe) oculto en la página web para separar claramente la solicitud GET de la solicitud POST. Algunos clientes pueden plantear restricciones sobre la abertura del marco flotante por acción del programa, en cuyo caso, para activar su creación se puede usar una acción del usuario tal como un clic de un botón (etapa 1214).
8.
El dispositivo integrado transmite los encabezamientos HTTP apropiados en respuesta a la solicitud GET del punto 7 anterior, incluyendo un encabezamiento Disposición de Contenido HTTP para el archivo que está haciendo rebotar. La primera parte del archivo también puede ser transmitida por el dispositivo integrado en este momento. Consúltese el uso de la memoria intermedia según se describe en los puntos 10 y 11 posteriores (etapa 1216).
9.
Cuando el cliente (navegador) recibe el encabezamiento de Disposición de Contenido, abre un recuadro de diálogo que permite que el usuario seleccione si el archivo se debería abrir o memorizar en el ordenador anfitrión cuando se haya completado la descarga (etapa 1218).
10.
Como consecuencia de la solicitud de POST iniciada en el punto 6 anterior, el dispositivo integrado recibe del cliente datos que equivalen hasta una ventana de TCP, los cuales se sitúan en una memoria intermedia asociada a la ID de canal especificada (etapa 1220).
11.
El dispositivo integrado extrae datos (es decir, contenido de archivo) de la memoria intermedia asociada a la ID de canal especificada (véase el punto 10 anterior) y los transmite al cliente (a través de la respuesta GET iniciada en el punto 7 anterior) (etapa 1222).
12.
Los puntos 10 y 11 anteriores se repiten hasta que se ha “hecho rebotar” el archivo completo, momento en el que el archivo será abierto o memorizado en el ordenador anfitrión (dependiendo de la selección del usuario en el punto 9 anterior) (etapa 1224).
13.
El dispositivo integrado marca la ID de canal como libre (etapa 1226).
14.
El dispositivo integrado envía una respuesta apropiada (específica de la aplicación) al cliente para confirmar que se ha completado la solicitud POST del punto 6 anterior (etapa 1228).
En una forma de realización de la invención, las etapas para cargar (es decir, leer) un archivo desde el ordenador anfitrión al cliente (navegador web) se muestran en la FIG. 13, y se describen en líneas generales de forma más detallada posteriormente. Resultará evidente para los expertos en la materia que, en las etapas descritas en el presente caso, se pueden aplicar varias modificaciones sin desviarse con respecto al espíritu y el alcance de esta forma de realización.
1.
El usuario navega a una página web que invocará el rebote de archivos para seleccionar (y finalmente cargar) un archivo desde el ordenador anfitrión. A esta página se le hace referencia como madre (etapa 1302).
2.
El cliente se conecta al dispositivo integrado y solicita la página web madre (etapa 1304).
3.
El dispositivo integrado transmite la madre al cliente, que contiene un marco flotante (iframe) (al que se hace referencia como hijo). Debe observarse que el hijo se usa para seleccionar el archivo y aplicarle un POST y la madre se usa para aplicar al archivo un GET y acceder al mismo (etapa 1306).
4.
El cliente solicita el contenido del cuadro flotante (es decir, el hijo) del dispositivo integrado (etapa 1308).
5.
El dispositivo integrado transmite el hijo (que incluye un control de carga de archivos basado en formularios HTML que se usará para seleccionar el archivo a cargar) hacia el cliente (etapa 1310).
6.
El motor de procesado del cliente usa un canal de comunicación gestionado (desde el hijo) para solicitar una ID de canal de rebote de archivos desde el dispositivo integrado (cada ID de canal reserva recursos en el dispositivo integrado, incluyendo los recursos para dos conexiones HTTP) (etapa 1312).
7.
El dispositivo integrado busca una ID de canal disponible (etapa 1314).
•
Si tiene una ID de canal disponible, marca el canal correspondiente como reservado.
•
Si no tiene una ID de canal disponible, no se puede realizar un rebote de archivo en este momento (se envía una respuesta apropiada al hijo, el cual, a su vez, visualiza un mensaje para el usuario, y el proceso finaliza aquí).
8.
El dispositivo integrado transmite la ID de canal correspondiente al canal reservado en el punto 7 anterior al cliente (etapa 1316).
9.
El hijo almacena la ID de canal en un campo oculto dentro del formulario HTML que contiene el control de carga de archivo (lo cual provoca que se cargue con el resto del formulario posteriormente) (etapa 1318).
10.
El usuario selecciona el archivo deseado del ordenador anfitrión con el control de carga de archivos, y hace clic en un botón de confirmación cuando el archivo ha sido seleccionado (1320).
11.
El hijo notifica a la madre que el archivo está preparado para hacerlo rebotar y proporcionar la ID de canal a la madre (etapa 1322).
12.
Tras haber recibido una notificación por parte del hijo, la madre usa un canal de comunicación gestionado para iniciar una solicitud GET con el fin de recuperar el archivo desde el dispositivo integrado. El dispositivo integrado coloca esta solicitud en espera y aguarda a los datos de archivo del hijo (etapa 1324).
13.
El hijo usa una solicitud POST convencional (es decir, no se requiere un canal de comunicación gestionado) para iniciar la presentación del formulario (debe observarse que, debido al control de carga de archivos basado en formularios HTML, la presentación del formulario incluye el archivo). Debe observarse que el dispositivo integrado coloca los datos del archivo (es decir, contenido, no metadatos) incluidos en este POST en una memoria intermedia asociada a la ID de canal especificada (etapa 1326).
14.
El dispositivo integrado transmite los encabezamientos HTTP apropiados hacia la madre en respuesta a la solicitud GET del punto 12 anterior. En este momento el dispositivo integrado también puede transmitir la
primera parte del archivo. Consúltese el uso de la memoria intermedia según se describe en los puntos 15 y 16 a continuación (etapa 1328).
15.
Como consecuencia de la solicitud POST iniciada en el punto 13 anterior, el dispositivo integrado recibe datos equivalentes hasta a una ventana de TCP, desde el hijo, y los coloca en una memoria intermedia asociada a la ID de canal especificada (etapa 1330).
16.
El dispositivo integrado extrae datos (es decir, contenido del archivo) de la memoria intermedia asociada a la ID de canal especificada (véase el punto 15 anterior) y los transmite a la madre (etapa 1332).
17.
Los puntos 15 y 16 anteriores se repiten hasta que se haya “hecho rebotar” el archivo completo, momento en el cual el archivo completo ha sido cargado en la madre, donde el motor de procesado del cliente puede acceder a y manipular el mismo libremente (etapa 1334).
18.
El dispositivo integrado marca la ID de canal como libre (etapa 1336).
19.
El dispositivo integrado envía una respuesta apropiada (específica de aplicación) al hijo para confirmar que se ha completado la solicitud POST del punto 13 anterior (etapa 1338).
Debe observarse que en ambos ejemplos descritos anteriormente en líneas generales, únicamente es necesario que resida en el dispositivo integrado una parte muy pequeña del archivo en cualquier momento. Por ejemplo, usando el rebote de archivos, se puede leer o escribir un archivo de 10 MB (o mayor) con solo una memoria intermedia RAM de 10 KB (o menor) en el dispositivo integrado, ofreciendo una reducción de 1.000 veces (o mayor) de la memoria requerida para el dispositivo integrado.
El rebote de archivos puede usar la ventana de TCP (que controla el número de bytes de datos que se pueden transmitir a través de una conexión dada sin un acuse de recibo desde el receptor) para proporcionar un control de flujo automático y un grado de sincronización entre dos conexiones cooperativas usadas para implementar un canal de rebote de archivos. A medida que se cargan datos en el dispositivo integrado, se llena la ventana TCP de la conexión POST del dispositivo integrado, y a medida que se descargan datos en el cliente a través de la conexión GET, se vacía la ventana TCP de la conexión POST del dispositivo integrado. De esta manera, la ventana TCP de la conexión POST se puede usar para “marcar el ritmo” del rebote del archivo. Esto permite una vinculación moderada entre las dos conexiones HTTP asociadas a un canal de rebote de archivos en el dispositivo integrado. El cliente únicamente transmitirá datos al dispositivo integrado (a través de la conexión POST) si el dispositivo integrado tiene espacio de memoria intermedia dentro de su ventana TCP de la conexión POST, y el dispositivo integrado simplemente transmitirá datos al cliente (a través de la conexión GET) todo lo rápido que pueda (según lo permita la ventana TCP análoga del cliente).
Este uso de dos conexiones HTTP cooperativas hace que el rebote de archivos resulte algo inusual. Por ejemplo, los servidores HTTP normalmente gestionan cada conexión de manera independiente; mientras que el rebote de archivos utiliza un grado de coordinación y cooperación entre las dos conexiones HTTP que participan en un canal dado de rebote de archivos (esencialmente están “emparejadas”). Debe observarse que, debido a que las dos conexiones HTTP usadas en el rebote de archivos funcionan simultáneamente, los canales de comunicación gestionados descritos en esta sección usan una comunicación asíncrona.
Otro aspecto inusual del rebote de archivos es cómo trata el contenido (los archivos). Normalmente, los archivos se almacenan en su totalidad dentro del servidor HTTP. Incluso los archivos generados dinámicamente se pueden considerar en general que tienen una existencia continua, en el sentido de que el servidor puede generar una copia del archivo según se necesite. No obstante, con el rebote de archivos, los archivos rebotados son completamente transitorios desde la perspectiva del servidor (es decir, del dispositivo integrado). Una vez que se ha transmitido un paquete dado desde el dispositivo integrado (y el cliente ha acusado su recibo), el mismo desaparece desde la perspectiva del dispositivo integrado (ya no es necesario).
Los ejemplos dados usan pares de conexiones HTTP; no obstante, es también posible usar conexiones FTP para el rebote de archivos. Los expertos en la materia percibirán que son posibles varias combinaciones de tipos de conexión.
Es interesante echar una mirada a resultados basados en el tiempo registrados a partir de una implementación de prueba de generación de contenido del lado del cliente combinada con rebote de archivos. Un ordenador anfitrión (con un procesador Pentium® D de 3 GHz de Intel Corporation) y un dispositivo integrado (con un núcleo ARM920T® de 200 MHz de ARM Limited) se conectaron a través de una red de área local (Ethernet de 100 Mbps). El cliente (navegador web Internet Explorer® 6 de Microsoft Corporation) recuperó una página de arranque, un motor de procesado del cliente, un archivo de plantillas estáticas (para generar un informe de Formato de Texto Enriquecido) y un conjunto de datos dinámicos del dispositivo integrado, usando canales de comunicación gestionados, según resultó apropiado, en aproximadamente 4 segundos, después de lo cual el cliente generó un informe de 1.000 páginas (3,6 MB) en aproximadamente 35 segundos, seguido por la participación del cliente y del dispositivo integrado en una sesión de rebote de archivos para memorizar el informe en el sistema de archivos del ordenador anfitrión en aproximadamente 8 segundos.
Una de las ventajas del sistema descrito es la escalabilidad mejorada. Por ejemplo:
•
El motor de procesado del cliente se puede carga en un número cualquiera de clientes, convirtiéndose cada uno de ellos en otra entidad de procesado en el sistema. Por ejemplo, un dispositivo integrado puede tener 100 clientes, cada uno de los cuales usa el motor de procesado del cliente para transferir trabajo desde el dispositivo integrado.
•
Se puede usar un archivo de plantillas estáticas para generar contenido que se actualiza repetidamente (es decir, elementos dinámicos del contenido se renuevan repetidamente) en periodos de tiempo arbitrarios. Por ejemplo, el motor de procesado del cliente puede usar un archivo de plantillas estáticas para generar una página web que se renueva en tiempo real (por ejemplo, diez veces por segundo) con datos nuevos del dispositivo integrado, al mismo tiempo que se impone una carga mínima sobre el dispositivo integrado. Usando el ejemplo de la FIG. 4 (un conjunto de datos dinámicos de aproximadamente 74 caracteres), la FIG. 5 (un archivo de plantillas estáticas de aproximadamente 817 caracteres), y la FIG. 6 (un documento generado de aproximadamente 2.093 caracteres), y suponiendo que la página web se renueva diez veces por segundo durante un minuto (600 actualizaciones), se puede realizar una comparación entre el motor de procesado del cliente que genera contenido y que requiere aproximadamente 45.000 bytes para ser transmitidos desde el dispositivo integrado al cliente (817 bytes para el archivo de plantillas estáticas y 74 bytes por cada conjunto de datos dinámicos multiplicado por 600 actualizaciones) con el dispositivo integrado que genera el mismo contenido y que requiere la transmisión aproximadamente de 1.256.000 bytes desde el dispositivo integrado al cliente (2.093 caracteres por página multiplicado por 600 actualización).
•
Se puede usar un archivo de plantillas estáticas para generar contenido de “profundidad” arbitraria, que actúa esencialmente como un “molde de producción en serie” de contenido. Por ejemplo, el motor de procesado del cliente puede usar un archivo de plantillas estáticas para generar cien o incluso mil informes de páginas, donde cada página se genera a partir del archivo de plantillas estáticas y un registro de un conjunto de datos dinámicos de múltiples registro.
•
La división de recursos estáticos (por ejemplo, el motor de procesado del cliente y los archivos de plantillas estáticas) con respecto a recursos dinámicos (los conjuntos de datos dinámicos), maximiza la cantidad de información almacenable en memoria caché. En general, los únicos recursos que no se pueden almacenar en memoria caché son conjuntos de datos dinámicos, que están compuestos en su totalidad por datos dinámicos
– la totalidad del resto de recursos puede ser almacenada típicamente en memoria caché por el cliente. Esto proporciona una ventaja muy significativa con respecto a páginas web dinámicas generadas por el lado del servidor (es decir, por el dispositivo integrado), que no se pueden almacenar en memoria caché pero que todavía podrían contener una gran cantidad de contenido estático. Esto significa también que el dispositivo integrado consume la mayor parte de su tiempo en la tarea central de servir datos dinámicos (a través de conjuntos de datos dinámicos). Esta ventaja se ve amplificada adicionalmente por el uso de datos (casi) puros en el conjunto de datos dinámicos según se ejemplifica en la forma de realización preferida.
La división entre recursos estáticos y recursos dinámicos proporciona además otras ventajas. Por ejemplo, separa claramente la información de presentación y de estilo (que se halla dentro del archivo de plantillas estáticas) con respecto a los datos (que se hallan dentro del conjunto de datos dinámicos). Esto permite que los dos varíen de manera independiente – los datos de varios conjuntos de datos dinámicos se pueden presentar con el mismo estilo, y un único conjunto de datos dinámicos se puede presentar con varios estilos diferentes. Puede verse un ejemplo de esto último en una comparación entre la FIG. 6 y la FIG. 9, que ilustra cómo se puede usar el mismo conjunto de datos dinámicos (mostrado en la FIG. 4), en combinación con dos archivos diferentes de plantillas estáticas (FIG. 5 y FIG. 8), para generar una salida notablemente diferente (la página web de la FIG. 7 y el informe RTF de la FIG. 10); o, alternativamente, cómo se puede usar el mismo conjunto de datos dinámicos (FIG. 4) y archivo de plantillas estáticas (FIG. 5) para generar una salida notablemente diferente (la página web de la FIG. 7 y el informe RTF de la FIG. 10) meramente ordenando al motor de procesado del cliente que genere un tipo diferente de contenido.
Además, esta división entre recursos estáticos y recursos dinámicos puede reducir considerablemente el procesado y los recursos requeridos para el cifrado de datos. La seguridad de los datos se puede proporcionar simplemente cifrando los conjuntos de datos dinámicos. Los recursos estáticos típicamente no contienen información privada y se pueden transferir libremente sin cifrado. Por lo tanto, el sistema descrito puede reducir considerablemente la cantidad de información a cifrar. Una vez más, esta ventaja se ve amplificada adicionalmente por el uso de datos (casi) puros en el conjunto de datos dinámicos según se ejemplifica en la forma de realización preferida.
El sistema descrito mantiene también muy bajos los requisitos de RAM del dispositivo integrado. Por ejemplo, los archivos de recursos estáticos, tales como el motor de procesado del cliente, y los archivos de plantillas estáticas se pueden almacenar en memoria flash u otros medios de almacenamiento de bajo coste, limitándose el uso de la RAM a un número pequeño de “paquetes” excepcionales cuando se está transmitiendo un archivo a un cliente. Además, la separación de recursos estáticos y recursos dinámicos minimiza la cantidad de RAM requerida para construir y almacenar un conjunto de datos dinámicos mientras el mismo está siendo transmitido a un cliente, puesto que los conjuntos de datos dinámicos son en su totalidad datos dinámicos en lugar de una mezcla de contenido estático y dinámico. Además, el uso de rebote de archivos minimiza la memoria (típicamente RAM) requerida por el dispositivo integrado para leer y escribir archivos desde y en el ordenador anfitrión.
Aunque el sistema descrito requiere solamente recursos mínimos del dispositivo integrado, la transferencia de la generación de contenido y otro procesado al ordenador anfitrión significa que ello no va en detrimento de la experiencia del usuario. Todo lo contrario, debido a que los ordenadores anfitriones están en general órdenes de magnitud por encima de los dispositivos integrados en términos de memoria y poder de procesado, son capaces de generar contenido que es mucho mayor y más sofisticado que el que sería posible para el dispositivo integrado por sí solo.
Debería indicarse explícitamente que las formas de realización descritas no dependen de empresas, productos, o herramientas de desarrollo específicos, de terceros; y no requieren la instalación de ningún software personalizado, incluyendo ningún módulo plug-in de navegador especial, en el ordenador anfitrión. Son “genéricas” en cuanto a sus requisitos -la totalidad de los archivos requeridos (por ejemplo, el motor de procesado del cliente y el archivo de plantillas estáticas) se puede crear con un simple editor de texto (tal como el editor de texto Bloc de Notas de Microsoft Corporation) y no se imponen requisitos “especiales” sobre el ordenador anfitrión. Por ejemplo, los elementos principales de las formas de realización descritas se han sometido satisfactoriamente a prueba pasando por una gama de clientes HTTP populares, incluyendo los navegadores web Internet Explorer® 6 e Internet Explorer® 7 de Microsoft Corporation, los navegadores web Firefox® 1.5 y Firefox® 2 de Mozilla Corporation, el navegador web Safari™ 2 de Apple Inc., y el navegador web Opera™ 9 de Opera Software ASA.
Además, debería observarse que las formas de realización descritas requieren solamente un soporte HTTP muy básico del dispositivo integrado, lo cual es una consideración importante para dispositivos integrados de recursos limitados. Nada de las formas de realización descritas en la presente memoria requiere soporte para tecnologías adicionales del lado del servidor tales como PHP, CGI, o ASP.NET. Esto ayuda a mantener bajos los requisitos de recursos, permitiendo el uso de varias formas de realización de la invención incluso en sistemas integrados muy “pequeños”.

Claims (14)

  1. REIVINDICACIONES
    1. Método para permitir que un dispositivo integrado (102) funcione conjuntamente con un cliente (104) en un ordenador anfitrión (106), para acceder a contenido de un archivo accesible para el ordenador anfitrión (106), aunque no directamente accesible para el cliente (104), que comprende las etapas siguientes:
    seleccionar un archivo en el cliente (104); establecer un enlace de comunicaciones entre el cliente (104) y el dispositivo integrado (106); enviar una parte del archivo desde el cliente al dispositivo integrado de un tamaño que encaje dentro de las
    limitaciones de recursos del dispositivo integrado, el cual, a continuación, devuelve la parte al cliente; añadir la parte devuelta a cualesquiera partes previas recibidas en el cliente (104); y repetir las etapas previas de envío y adición hasta que el archivo se haya reconstruido completamente en el cliente
    (104); en donde el cliente (104) accede al archivo reconstruido como un proxy para el dispositivo integrado.
  2. 2.
    Método según la reivindicación 1, en el que los protocolos de enlace de comunicaciones se seleccionan del grupo consistente en HTTP, FTP, y cualquier combinación de los mismos.
  3. 3.
    Método según la reivindicación 1, en el que el archivo reconstruido comprende contenido que es por lo menos uno de procesado, transformado, manipulado, y acumulado en el cliente.
  4. 4.
    Método según la reivindicación 1, que comprende además la etapa de usar una pluralidad de enlaces de comunicación para acceder simultáneamente a contenido de múltiples archivos.
  5. 5.
    Método según la reivindicación 1, en el que el enlace de comunicaciones comprende una primera conexión que envía la parte del archivo y una segunda conexión que devuelve la parte.
  6. 6.
    Método según la reivindicación 5, que comprende además la etapa de usar una ventana de TCP para proporcionar un control de flujo automático entre la primera conexión y la segunda conexión.
  7. 7.
    Método según la reivindicación 1, en el que el método se utiliza para aplicaciones de gestión de rendimientos de fabricación.
  8. 8.
    Método para permitir que un dispositivo integrado (102) funcione conjuntamente con un cliente (104) en un ordenador anfitrión (106), en donde el cliente tiene acceso limitado a sistemas de archivos accesibles para el ordenador anfitrión, con el fin de generar un archivo en el cliente (104) a almacenar o abrir a través del ordenador anfitrión (106), que comprende las etapas siguientes:
    generar contenido de un archivo en una memoria del cliente (104);
    establecer un enlace de comunicaciones entre el cliente (104) y el dispositivo integrado (102);
    determinar una de las siguientes opciones en el cliente (104): dónde se almacenará el archivo en el sistema de archivos accesible para el ordenador anfitrión y si se abrirá el archivo;
    enviar una parte del archivo desde el cliente al dispositivo integrado de un tamaño que encaje dentro de las limitaciones de recursos del dispositivo integrado (102), el cual devuelve la parte de nuevo al cliente (104),
    añadir la parte devuelta a cualesquiera partes previas recibidas en el ordenador anfitrión, y repetir las etapas previas de envío y adición hasta que el archivo completo se haya enviado y devuelto completamente; y,
    o bien almacenar o bien abrir el archivo completo en concordancia con la etapa de determinación.
  9. 9.
    Método según la reivindicación 8, en el que los protocolos de enlace de comunicaciones se seleccionan del grupo consistente en HTTP, FTP, y cualquier combinación de los mismos.
  10. 10.
    Método según la reivindicación 8, en el que la etapa de generar contenido comprende generar contenido en tiempo real a partir de datos a medida que esos datos son proporcionados por el dispositivo integrado (102).
  11. 11.
    Método según la reivindicación 8, en el que la etapa de generar contenido comprende procesar información recibida por el cliente (104) desde el dispositivo integrado (102) de una de las siguientes maneras: transformación, manipulación, acumulación, y cualquier combinación de las mismas.
    5 12. Método según la reivindicación 8, que comprende además la etapa de usar una pluralidad de enlaces de comunicación para enviar y devolver simultáneamente múltiples archivos.
  12. 13. Método según la reivindicación 8, en el que el enlace de comunicaciones comprende una primera conexión que
    envía la parte del archivo y una segunda conexión que devuelve la parte. 10
  13. 14. Método según la reivindicación 13, que comprende además la etapa de usar una ventana de TCP para proporcionar un control de flujo automático entre la primera conexión y la segunda conexión.
  14. 15. Método según la reivindicación 8, en el que el método se utiliza para aplicaciones de gestión de rendimientos de 15 fabricación.
ES08767554T 2007-05-07 2008-05-05 Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red. Active ES2368366T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US92797807P 2007-05-07 2007-05-07
US927978P 2007-05-07

Publications (1)

Publication Number Publication Date
ES2368366T3 true ES2368366T3 (es) 2011-11-16

Family

ID=39944171

Family Applications (2)

Application Number Title Priority Date Filing Date
ES11174944.6T Active ES2524311T3 (es) 2007-05-07 2008-05-05 Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red
ES08767554T Active ES2368366T3 (es) 2007-05-07 2008-05-05 Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES11174944.6T Active ES2524311T3 (es) 2007-05-07 2008-05-05 Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red

Country Status (7)

Country Link
US (2) US9100248B2 (es)
EP (2) EP2145452B1 (es)
AT (1) ATE519320T1 (es)
CA (2) CA2686313C (es)
ES (2) ES2524311T3 (es)
PL (1) PL2381649T3 (es)
WO (1) WO2008137117A2 (es)

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8307180B2 (en) 2008-02-28 2012-11-06 Nokia Corporation Extended utilization area for a memory device
CN101662460B (zh) 2008-08-25 2015-07-15 阿里巴巴集团控股有限公司 一种跨域通讯的方法、系统和装置
US8516361B2 (en) * 2008-12-14 2013-08-20 International Business Machines Corporation Offloading filling of template parameters to client from server
US8219598B1 (en) * 2009-05-11 2012-07-10 Google Inc. Cross-domain communicating using data files
US8607189B2 (en) * 2009-05-18 2013-12-10 National Instruments Corporation Dynamic analysis of a graphical program in a browser
US8874824B2 (en) 2009-06-04 2014-10-28 Memory Technologies, LLC Apparatus and method to share host system RAM with mass storage memory RAM
US9058429B2 (en) * 2009-11-06 2015-06-16 Toby Biddle Usability testing tool
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
KR101083311B1 (ko) * 2010-03-29 2011-11-15 한국전자통신연구원 악성 스크립트 분석 시스템 및 그를 이용한 악성 스크립트 분석 방법
US9503375B1 (en) 2010-06-30 2016-11-22 F5 Networks, Inc. Methods for managing traffic in a multi-service environment and devices thereof
US9420049B1 (en) 2010-06-30 2016-08-16 F5 Networks, Inc. Client side human user indicator
US8516364B2 (en) * 2010-08-30 2013-08-20 Sap Ag View model aspects of component objects
US20120151321A1 (en) * 2010-12-09 2012-06-14 Schneider Electric USA, Inc. System for Generating Websites for Products with an Embedded Processor
US9037963B1 (en) 2011-04-22 2015-05-19 Amazon Technologies, Inc. Secure cross-domain web browser communications
WO2012158854A1 (en) 2011-05-16 2012-11-22 F5 Networks, Inc. A method for load balancing of requests' processing of diameter servers
US8595752B1 (en) * 2011-06-13 2013-11-26 Google Inc. Hybrid application message passing
US8954492B1 (en) * 2011-11-30 2015-02-10 F5 Networks, Inc. Methods for inlining content externally referenced in a web page prior to providing the web page to a requestor and devices thereof
US9386114B2 (en) * 2011-12-28 2016-07-05 Google Inc. Systems and methods for accessing an update server
US8977704B2 (en) * 2011-12-29 2015-03-10 Nokia Corporation Method and apparatus for flexible caching of delivered media
US9417998B2 (en) 2012-01-26 2016-08-16 Memory Technologies Llc Apparatus and method to provide cache move with non-volatile mass memory system
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9020912B1 (en) 2012-02-20 2015-04-28 F5 Networks, Inc. Methods for accessing data in a compressed file system and devices thereof
US9311226B2 (en) 2012-04-20 2016-04-12 Memory Technologies Llc Managing operational state data of a memory module using host memory in association with state change
EP2853074B1 (en) 2012-04-27 2021-03-24 F5 Networks, Inc Methods for optimizing service of content requests and devices thereof
US9164804B2 (en) 2012-06-20 2015-10-20 Memory Technologies Llc Virtual memory module
US9116820B2 (en) 2012-08-28 2015-08-25 Memory Technologies Llc Dynamic central cache memory
US10033837B1 (en) 2012-09-29 2018-07-24 F5 Networks, Inc. System and method for utilizing a data reducing module for dictionary compression of encoded data
US9578090B1 (en) 2012-11-07 2017-02-21 F5 Networks, Inc. Methods for provisioning application delivery service and devices thereof
US9053085B2 (en) * 2012-12-10 2015-06-09 International Business Machines Corporation Electronic document source ingestion for natural language processing systems
US9497614B1 (en) 2013-02-28 2016-11-15 F5 Networks, Inc. National traffic steering device for a better control of a specific wireless/LTE network
WO2014209255A1 (en) * 2013-06-24 2014-12-31 Empire Technology Development Llc User interface delegation to a delegated device
US9602576B2 (en) 2013-10-16 2017-03-21 Empire Technology Development Llc Control redistribution among multiple devices
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US9851951B1 (en) 2013-12-20 2017-12-26 Emc Corporation Composable action flows
US9170786B1 (en) 2013-12-20 2015-10-27 Emc Corporation Composable context menus
US9529572B1 (en) 2013-12-20 2016-12-27 Emc Corporation Composable application session parameters
US10466872B1 (en) 2013-12-20 2019-11-05 Open Text Corporation Composable events for dynamic user interface composition
US9756147B1 (en) * 2013-12-20 2017-09-05 Open Text Corporation Dynamic discovery and management of page fragments
US9407697B2 (en) * 2014-06-11 2016-08-02 Wipro Limited System and method for automating identification and download of web assets or web artifacts
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US10313468B2 (en) 2015-06-16 2019-06-04 Comcast Cable Communications, Llc Caching of metadata objects
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US10635160B2 (en) * 2016-05-16 2020-04-28 Tibco Software Inc. Stepback mechanism to develop and diagnose process applications
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
GB2558876A (en) * 2016-12-02 2018-07-25 Eseye Ltd Provision and retrieval of device status information
US10725799B2 (en) * 2017-02-22 2020-07-28 Microsoft Technology Licensing, Llc Big data pipeline management within spreadsheet applications
US11157690B2 (en) * 2017-02-22 2021-10-26 Microsoft Technology Licensing, Llc Techniques for asynchronous execution of computationally expensive local spreadsheet tasks
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US11720541B2 (en) * 2021-01-05 2023-08-08 Morgan Stanley Services Group Inc. Document content extraction and regression testing
US20230185954A1 (en) * 2021-12-15 2023-06-15 Bank Of America Corporation Transmission of Sensitive Data in a Communication Network
CN114385957A (zh) * 2022-03-24 2022-04-22 北京搜狐新媒体信息技术有限公司 一种落地页的创建方法及建站平台
CN115221453B (zh) * 2022-09-20 2023-03-10 太平金融科技服务(上海)有限公司深圳分公司 媒体资源管理方法、装置、服务器、介质

Family Cites Families (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6363164B1 (en) * 1996-05-13 2002-03-26 Cummins-Allison Corp. Automated document processing system using full image scanning
US20030093522A1 (en) * 1995-06-05 2003-05-15 Tetsuro Motoyama Method and system for diagnosis or control of machines
US6092018A (en) * 1996-02-05 2000-07-18 Ford Global Technologies, Inc. Trained neural network engine idle speed control system
US5796633A (en) * 1996-07-12 1998-08-18 Electronic Data Systems Corporation Method and system for performance monitoring in computer networks
JP4046804B2 (ja) 1997-06-26 2008-02-13 富士通株式会社 サーバの情報提供装置、サーバの情報提供プログラムを記録したコンピュータ読み取り可能な記録媒体およびサーバの情報提供方法
US20030009563A1 (en) * 1997-07-31 2003-01-09 At&T Corp. Method for client-side inclusion of data elements
US6067558A (en) 1997-09-18 2000-05-23 Wendt; James Gordon Method and apparatus for providing increased content from a resource constrained device
US6370141B1 (en) 1998-04-29 2002-04-09 Cisco Technology, Inc. Method and apparatus for configuring an internet appliance
US6363422B1 (en) 1998-06-24 2002-03-26 Robert R. Hunter Multi-capability facilities monitoring and control intranet for facilities management system
JP2000020122A (ja) 1998-07-06 2000-01-21 Toshiba Corp プラント監視制御装置および計算機が読み取り可能な記憶媒体
US6292801B1 (en) 1998-10-02 2001-09-18 Rene L. Campbell System and method for managing computer and phone network resources
US6446192B1 (en) * 1999-06-04 2002-09-03 Embrace Networks, Inc. Remote monitoring and control of equipment over computer networks using a single web interfacing chip
US6453259B1 (en) * 1999-06-18 2002-09-17 Rockwell Collins, Inc. Vehicle entertainment system having built-in test environment server
US6606665B2 (en) * 1999-09-27 2003-08-12 Rockwell Automation Technologies, Inc. Multiple connection architecture for communication with a computer numerical control resident in a workstation and other networked computer numerical controls
US6871112B1 (en) 2000-01-07 2005-03-22 Advanced Micro Devices, Inc. Method for requesting trace data reports from FDC semiconductor fabrication processes
AU2001239936B2 (en) * 2000-02-29 2004-09-09 Pcc Specialty Products, Inc. Smart machine tool system
US7065574B1 (en) * 2000-05-09 2006-06-20 Sun Microsystems, Inc. Messaging system using pairs of message gates in a distributed computing environment
US6918084B1 (en) * 2000-05-09 2005-07-12 Sun Microsystems, Inc. Spawning new repository spaces using information provided in advertisement schema messages
US7210099B2 (en) * 2000-06-12 2007-04-24 Softview Llc Resolution independent vector display of internet content
US20020099829A1 (en) * 2000-11-27 2002-07-25 Richards Kenneth W. Filter proxy system and method
US7139814B2 (en) * 2000-12-01 2006-11-21 Intel Corporation Dynamic content delivery to static page in non-application capable environment
US20020083172A1 (en) * 2000-12-21 2002-06-27 Knowles Gregory T. Systems, methods and computer program products for responding to client requests directed to networked embedded devices via proxy services
MY138476A (en) * 2001-02-01 2009-06-30 Honda Motor Co Ltd Apparatus for and method of controlling plant
US20020169871A1 (en) * 2001-05-11 2002-11-14 Cravo De Almeida Marcio Remote monitoring
DE10152765B4 (de) * 2001-07-13 2015-11-12 Siemens Aktiengesellschaft Verfahren zur elektronischen Bereitstellung von Diensten für Maschinen über eine Datenkommunikationsverbindung
ES2250278T3 (es) * 2001-09-05 2006-04-16 Mikron Comp-Tec Ag Un metodo y un sistema de soporte del operario destinados a ayudar a un operario a ajustar parametros de maquina.
US7054847B2 (en) 2001-09-05 2006-05-30 Pavilion Technologies, Inc. System and method for on-line training of a support vector machine
JP3839295B2 (ja) * 2001-10-09 2006-11-01 株式会社ジェイテクト 設備モニタ装置
US7219140B2 (en) 2001-12-05 2007-05-15 Dennis Craig Marl Configuration and management systems for mobile and embedded devices
US7089549B2 (en) * 2002-04-01 2006-08-08 International Business Machines Corp. Updating flash memory
US8074201B2 (en) * 2002-07-10 2011-12-06 National Instruments Corporation Deployment and execution of a program on an embedded device
US7092771B2 (en) * 2002-11-14 2006-08-15 Rockwell Automation Technologies, Inc. Industrial control and monitoring method and system
JP4007452B2 (ja) * 2003-10-10 2007-11-14 株式会社Ａｃｃｅｓｓ ブラウザを利用して機器情報を表示するシステム、およびプログラム
US7110918B2 (en) * 2003-11-05 2006-09-19 Shoplogix Inc. Self-contained system and method for remotely monitoring machines
CA2445790C (en) 2003-11-05 2004-11-23 Shoplogix Inc. Self-contained system and method for remotely monitoring machines
EP1695272A4 (en) 2003-11-05 2009-05-06 Shoplogix Inc AUTONOMOUS SYSTEM AND METHOD OF TESTING MACHINES
US8291309B2 (en) * 2003-11-14 2012-10-16 Rockwell Automation Technologies, Inc. Systems and methods that utilize scalable vector graphics to provide web-based visualization of a device
US7590726B2 (en) * 2003-11-25 2009-09-15 Microsoft Corporation Systems and methods for unifying and/or utilizing state information for managing networked systems
WO2005072405A2 (en) * 2004-01-27 2005-08-11 Transpose, Llc Enabling recommendations and community by massively-distributed nearest-neighbor searching
US7860582B2 (en) * 2004-06-23 2010-12-28 National Instruments Corporation Compact modular embedded device
JP4355639B2 (ja) * 2004-09-15 2009-11-04 キヤノン株式会社 画像処理装置およびその制御方法
US20070028227A1 (en) * 2005-07-26 2007-02-01 Lebowitz Kenneth J Code development system and method
TWI263901B (en) * 2005-07-28 2006-10-11 Lite On Technology Corp Program initiation methods and embedded systems utilizing the same
JP4661574B2 (ja) * 2005-12-14 2011-03-30 セイコーエプソン株式会社 組込機器、電子機器、組込機器の制御方法、制御プログラムおよび記録媒体
US8281386B2 (en) * 2005-12-21 2012-10-02 Panasonic Corporation Systems and methods for automatic secret generation and distribution for secure systems
US20070300150A1 (en) * 2006-06-22 2007-12-27 Lantronix, Inc. Building rich web site applications with an embedded device
US20080002760A1 (en) * 2006-06-28 2008-01-03 John Wallace Nasielski Method and apparatus for automatic distribution of device drivers
US8014308B2 (en) * 2006-09-28 2011-09-06 Microsoft Corporation Hardware architecture for cloud services
US20080104699A1 (en) * 2006-09-28 2008-05-01 Microsoft Corporation Secure service computation
US7853669B2 (en) * 2007-05-04 2010-12-14 Microsoft Corporation Mesh-managing data across a distributed set of devices

Also Published As

Publication number Publication date
WO2008137117A2 (en) 2008-11-13
PL2381649T3 (pl) 2015-02-27
EP2145452A2 (en) 2010-01-20
CA2686313A1 (en) 2008-11-13
EP2381649B1 (en) 2014-08-20
CA2786004C (en) 2015-06-30
EP2381649A1 (en) 2011-10-26
US9633135B2 (en) 2017-04-25
ES2524311T3 (es) 2014-12-05
CA2786004A1 (en) 2008-11-13
US20080281944A1 (en) 2008-11-13
US20150269273A1 (en) 2015-09-24
ATE519320T1 (de) 2011-08-15
WO2008137117A3 (en) 2009-07-09
EP2145452B1 (en) 2011-08-03
CA2686313C (en) 2012-10-02
US9100248B2 (en) 2015-08-04

Similar Documents

Publication Publication Date Title
ES2368366T3 (es) Método y sistema para ampliar las capacidades de dispositivos integrados a través de clientes de red.
Souders High-performance web sites
US8639743B1 (en) System and method for on-the-fly rewriting of JavaScript
US8285813B1 (en) System and method for emulating different user agents on a server
US8260845B1 (en) System and method for auto-generating JavaScript proxies and meta-proxies
US9122650B1 (en) Web server based on the same paradigms as web clients
US8954989B1 (en) Flexible, event-driven JavaScript server architecture
US8914774B1 (en) System and method for tagging code to determine where the code runs
Gray Comparison of Web Services, Java-RMI, and CORBA service implementations
CA2506064A1 (en) A system and method for client side rendering of a web page
US8819539B1 (en) On-the-fly rewriting of uniform resource locators in a web-page
US20070083533A1 (en) System and method for designing web sites that perform like conventional software applications
CN110647699A (zh) Web页面的渲染方法、装置、计算机设备和存储介质
US8566807B1 (en) System and method for accessibility of document object model and JavaScript by other platforms
US8938491B1 (en) System and method for secure binding of client calls and server functions
Crane et al. Ajax in Practice
Jackson Building Microservices with Go
US10244020B1 (en) System and method for auto-generating meta-proxies
Franke et al. VCoRE: a web resource oriented architecture for efficient data exchange
JP2012128516A (ja) 情報処理装置、データ更新方法、及びプログラム
Buchanan Developing an Extendable Web-Based Architecture for Honey Bee Data Visualization
Guillaume et al. Declarative metadata processing with XML and java
Puglisi RESTful Rails Development: Building Open Applications and Services
Srinivasan Web Technology
Keinänen Creation of a web service using the MERN stack