i AQUITECTURA DE APLICACION WEB
ANTECEDENTES DE LA INVENCION
CAMPO DE LA INVENCION
La presente invención está dirigida a proporcionar aplicaciones a base de red, y es particularmente aplicable a proporcionar aplicaciones a base de Internet y de web.
DESCRIPCION DE LA TECNICA RELACIONADA
Mientras las aplicaciones a base de Internet se hacen más poderosas, el mantener una experiencia de usuario uniforme y en respuesta se ha convertido en una característica importante para los desabolladores. Las aplicaciones a base de web generalmente incluyen una o más funciones proporcionadas en un servidor que son accedidas utilizando una aplicación de navegador web que corre en una computadora de cliente. Con el fin de que los clientes (navegadores web) y servidores se comuniquen en una forma de alta velocidad, se requiere un uso eficiente del · protocolo de comunicación, generalmente HTTP, entre ellos. Típicamente, un navegador web presenta una interfase para una aplicación, o componentes funcionales de la aplicación, al recibir páginas y funciones (típicamente en la forma de un lenguaje de marcación, ta! como HTML), del servidor. En algunos casos, el navegador debe presentar una nueva página de datos recibidos con cada respuesta a una solicitud para una página localizada en el servidor. Un formato común para proporcionar tal información es el Protocolo de Transferencia de Hipertexto (HTTP). Típicamente, un navegador solicitará una página web que utiliza un comando de "OBTENE " o "PEGAR" en HTTP, y toda la información requerida para presentar la página será regresada al navegador web. Alguna cuenta de datos, tal como la información necesaria para presentar una página, puede ser repetida varias veces incluso si un usuario solo está actualizando una porción de página. Aunque se han desarrolla técnicas para actualizar datos solo en porciones de una página al actualizar solicitudes de datos simples del navegador web, tales protocolos no han sido completamente flexibles al permitir a los desabolladores acceder completamente a los métodos importantes disponibles en las aplicaciones a base de web. Los ejemplos actuales de los protocolos de servidor de cliente que permiten a los navegadores a hacer remotamente llamadas de métodos en clases y objetos en un servidor remoto incluyen Protocolo de Acceso de Objeto Simple (SOAP) y XML-RPC. Tanto el SOAP como el XML-RPC requieren que los clientes tengan un entendimiento de los tipos de datos de transporte. Especificar una forma estándar para codificar parámetros y regresar valores en XML, y pasarlos en protocolos de red común. En SOAP y XML-RPC son principalmente utilizados para el servidor hacia la comunicación de servidor y el cliente espeso para la comunicación de cliente. Ambos son protocolos verbosos, y no son necesariamente muy eficientes. En particular, el SOAP requiere un mecanismo relativamente sofisticado en cliente con el fin de entender los datos recibidos del servidor y hacerlos disponibles para el cliente. Esto puede ser difícil de realizar en el lenguaje macro simple tal como JavaScript. Una ventaja de utilizar JavaScript es un navegador web que casi todas las aplicaciones de navegador incluyen una máquina macro que les permite ejecutar el macro. Utilizando la máquina de macro de navegador web requiere menos adaptación en el lado de cliente de la arquitectura. De ahí, sería ventajoso un método para mejorar la comunicación entre un navegador web y un cliente para iniciar aplicaciones a base de web.
COMPENDIO DE LA INVENCION
Se describe un método y protocolo para la comunicación entre una primera computadora y una segunda computadora, junto con un sistema que proporciona una aplicación en red en un ambiente de cliente-servidor. En un aspecto de la invención, aproximadamente descrito, incluye un sistema para proporcionar una aplicación en red en un ambiente de cliente-servidor. En una modalidad, el sistema incluye un grupo de funciones de aplicación en el servidor, las funciones de aplicación incluyendo una definición de tipo de datos, y un grupo de funciones de cliente definido en un ambiente macro. En un aspecto único, las funciones de cliente son definidas para incluir tipos que coinciden con cada una de las funciones de aplicación en un grupo de funciones de aplicación. En otra modalidad, la invención es un método para proporcionar aplicaciones web en Internet. El método puede incluir los pasos de: proporcionar un ambiente de servidor incluyendo funciones y objetos en un servidor, los objetos y funciones teniendo tipos definidos; que generan un ambiente de cliente incluyendo funciones y objetos en un ambiente macro, las funciones y objetos en el ambiente macro teniendo tipos de delineado para funciones correspondientes y objetos en el ambiente de servidor; y proporcionando el ambiente de cliente al servidor. Incluso en otra modalidad, la invención es un sistema para iniciar e instalar componentes de servidor y cliente para proporcionar una aplicación a base de web. El sistema incluye un grupo de aplicaciones de servidor que tienen objetos y métodos que tienen atributos. Un generador de código proporciona una biblioteca de lado de cliente de JavaScript y una biblioteca de la web de servidor para cada dicho objeto y método. Un servicio de lado de servidor incluye un despachador y un ordenador que enlutan datos del cliente a objetos y funciones correspondiente en el servidor. En otra modalidad, la invención es un sistema que implementa aplicaciones de Internet. El sistema incluye un servidor que incluye un grupo de objetos y métodos de aplicación cada uno teniendo un tipo definido. También se proporciona una máquina de generación que crea un grupo de cliente de macros que llaman dichos objetos y métodos, cada macro teniendo una definición de tipo que coincide con al menos un objeto o método de dicho grupo de objetos y métodos de aplicación. Una máquina de respuesta es proporcionada para recibir solicitudes de uno o más macros de cliente en un dispositivo de procesamiento de cliente y enrutando dichas solicitudes a una o más dichos objetos y métodos de aplicación. En otro aspecto, la invención, ampliamente descrita, comprende un protocolo de comunicación y método que operan asimétricamente entre las computadoras que operan en una red. Las comunicaciones de un cliente a un servidor son optimizadas para eficiencia de datos, e interpretación por el servidor. Las comunicaciones del servidor al cliente son optimizadas para la interpretación a través del cliente que utiliza recursos de aplicación de cliente existentes. En una modalidad, la invención es un método de comunicación entre un procedimiento de cliente y un procedimiento servidor en un sistema de procesamiento distribuido. El método puede comprenden los pasos de: emisión, a través del procedimiento de cliente, una solicitud de función al servidor, la solicitud de función incluyendo una fila de datos que tiene un formato definido por un tipo de una función de servidor solicitada; recibir, a través del procedimiento de servidor, el llamado de función y realizar la función solicitada a una fina; y emitir, a través del procedimiento de servidor, una respuesta a la solicitud de función, la respuesta siendo un formato de procesamiento de lado de cliente definido por el objeto de servidor.
En otra modalidad, la invención puede comprender un protocolo para comunicación entre una primera computadora y una segunda computadora. El protocolo incluye una solicitud de la primera computadora a la segunda computadora incluyendo un identificador de función para una función en la segunda computadora y un argumento para la función. El orden puede ser definido por un tipo para una función llamada por el identificador de función. El protocolo también incluye una respuesta de la segunda computadora a la primera computadora incluyendo los resultados de la función, con la respuesta definida como una entrada macro. En una modalidad alternativa, la invención es un método para comunicación entre un cliente y un servidor. En esta modalidad, el método puede incluir los pasos de: formatear datos en una solicitud, la solicitud incluyendo una fila de parámetro ordenada de acuerdo con un tipo de datos en el servidor; enviar los datos en la solicitud en una red; y crear una respuesta a los datos al formatear los datos de respuesta en un formato de respuesta de entrada macro.
BREVE DESCRIPCION DE LOS DIBUJOS
La Figura 1 ilustra un diagrama de bloque de hardware de computadora adecuado para implementar la invención. La Figura 2 es un cuadro de flujo que representa un método general de la presente invención para crear poderes del lado de cliente del ambiente de desarrollo de servidor de acuerdo con un aspecto de la presente invención. La Figura 3 es un método de lado cliente para obtener el ambiente de poder generado en la Figura 2. La Figura 4 es un diagrama de bloque de una modalidad y un sistema adecuado para implementar la arquitectura de la presente invención. La Figura 5 es un cuadro de flujo que representa una modalidad del cliente e interacción de servidor para una aplicación a base de web que opera utilizando la arquitectura importante de la presente invención. La Figura 6 es una comparación entre una definición de objeto del lado del servidor y una definición de objeto de poder del lado de cliente. La Figura 7 es un primer ejemplo de una interfase de servidor y bosquejo de JavaScript asociado con el método. La Figura 8 es un ejemplo de una solicitud de cliente para el servidor y una respuesta del servidor utilizando el protocolo para implementar el método de la presente invención. La Figura 9 es un segundo ejemplo de una interfase del lado de servidor y un bosquejo de JavaScript correspondiente. La Figura 10 es un tercer ejemplo de una interfase del lado del servidor en el bosquejo de JavaScript correspondiente. La Figura 11 es un cuarto ejemplo de una interfase del lado de servidor y un bosquejo de JavaScript correspondiente. La Figura 12 es un segundo ejemplo de un lugar en el protocolo de respuesta de acuerdo con la presente invención. La Figura 13 es un cuadro flujo que ilustra un método para que el cliente rija llamados de poder sincrónicos y asincrónicos a través del cliente de acuerdo con la presente invención.
DESCRIPCION DETALLADA
Se proporciona una arquitectura única para implementar aplicaciones a base de web en un ambiente en red. La arquitectura proporciona tanto un cliente como el servidor con un grupo completo de interfase de programación, funciones y objetos disponibles en el servidor, y minimiza las comunicaciones de datos en un método de comunicación único, denominado como el "protocolo", entre el cliente y el servidor. El método de comunicación es optimizado para incluir datos para implementar funciones de la aplicación proporcionada. La invención será descrita aquí en términos de su aplicabilidad a aplicaciones de base de web proporcionadas en el Internet. Se reconocerá que la aplicabilidad de la arquitectura no está limitada a Internet, en ambiente operativo particular aquí descrito, ni los lenguajes de cómputo aquí descritos. La invención será ilustrada en el contexto de proporcionar un servicio de correo electrónico a base de web, y una función de revisión de ortografía para utilizarse dentro del servicio de correo electrónico a base de web como una modalidad de una implementación de la invención. Se reconocerá que la ilustración particular de la arquitectura con las aplicaciones ilustrativas y las funciones no limita el alcance de aplicaciones y funciones que puede ser implementada utilizando la arquitectura y protocolo de la presente invención. La arquitectura utiliza un lugar único y protocolo de respuesta que es asimétrico: el protocolo de lugar proporcionada datos sin tipo al servidor, mientras el protocolo de respuesta incluye datos en un formato con tipo y macro. Automáticamente se proporcionan bibliotecas del lado de cliente generadas que corresponde a cada objeto y método que existe en el servidor. En otro aspecto único, un protocolo más ligero mueve datos entre el cliente y el servidor. Los ejemplos de protocolo son mostrados en las Figuras 8 y 11. En un aspecto único, el cliente escribe datos enviados al servidor, y el servidor trata con el procesamiento requerido por la fecha. El servidor envía la respuesta de regreso en macro, que es "con tipo" en las estructuras de datos conocidas. En general, el procedimiento para iniciar e instalar los componentes del lado de servidor y lado de cliente toma aflicciones desarrolladas en el servidor, que tiene clases y métodos que tienen atributos y crean un ambiente de cliente y ambiente de servidor. Un generador de código (denominado aquí como una máquina o procedimiento de "CodeGen") crea objetos de biblioteca del lado de cliente de JavaScript y componentes de bosquejo, frecuentemente denominados aquí como poderes del lado de cliente, así como "poderes" de código del lado del servidor para cada objeto y componente en la aplicación desarrollada. Una vez que los ambientes son creados, y el ambiente de cliente instalado, un servicio del lado de servidor que incluye un despachador y un ordenador enruta los. datos de las funciones en el cliente a objetos correspondientes y funciones en el servidor. Se entenderá que mientras la invención será descrita aquí con respecto a su aplicación utilizando JavaScript, la arquitectura puede incorporar otros sistemas. De acuerdo con la invención, un desarrollador crea una aplicación en el servidor que resulta en número de clases y métodos. Cuando se recopila la aplicación, por ejemplo, bibliotecas de enlace dinámico (DLLs) u objetos de macro ejecutables (archivos.exe) son creados. Siguiendo la recopilación de la aplicación, para objetos y métodos marcadas por el desarrollador para exportar, un procedimiento de CodeGen crea objetos en JavaScript para clases marcadas y bosquejos en JavaScript para métodos marcados. Los Macros de Java son empacados en uno o más archivos de JavaScript que pueden ser consumidos por un navegador web, y transmitidos a clientes que se conectan al servidor para implementar aplicaciones a base de web. El procedimiento de CodeGen también crea elementos de poder del lado de servidor. En una modalidad, el procedimiento de CodeGen crea códigos C# que corre en el servidor, con un delineado directo de objetos y funciones en el servidor para objetos y bosquejos en el cliente. El procedimiento de CodeGen también crea un ordenador, despachador y poderes que permiten a las invocaciones a clientes activar los componentes del lado de servidor. Este grupo de código de aplicación de servidor después es recopilado para uso del servidor. Se debe notar que el uso de C# también es ilustrativo. Se puede utilizar cualquier lenguaje de programación orientado a objeto de acuerdo con la presente invención . Una vez que se completa el procedimiento de CodeGen, se ha creado una biblioteca de cliente que corresponde a la biblioteca del lado de servicio. Los desabolladores de cliente que buscan invocar servicios localizados en el servidor ahora tienen la capacidad de utilizar los componentes del lado de cliente de la misma forma en el que lo haría el desarrollador de lado de servicio. En este aspecto, todos los objetos, protocolos, interfases, y APIs disponibles en el servidor están disponibles en el cliente. El código de cliente y servidor auto-generado contiene el mismo protocolo. Cuando un cliente invoca un método en la biblioteca de cliente local, se ejecuta el bosquejo de JavaScript local generado. Como un "poder", su interacción con los elementos de servidor es transparente para el tiempo de funcionamiento. Cuando el bosquejo ejecuta, cualquiera de los datos requerido por la aplicación desde el servidor en la función causará que se enrute una solicitud al servidor. Los datos en la solicitud enviados al servidor son ordenados, reunidos y convirtiendo los datos en un formato que es preescrito para una función u objeto particular. En este caso son ordenados en un formato de transporte definido por el tipo de objeto o método solicitado que es entendió por un ordenador (o "desordenador" en este caso) en el servidor. El ordenador y despachador en el servidor toma la solicitud, desordena los datos en la solicitud, y despacha la solicitud al objeto o método del lado de servidor real. El código del lado de servicio después crea una respuesta basándose en la solicitud y la función que reside en el componente, y pasa los datos resultantes de regreso al cliente en un formato de respuesta que puede ser interpretado por la biblioteca macro en el cliente, por ejemplo un orden o un elemento. En el cliente, la máquina de Macro de Javo de! lado de cliente auto-generado desordena la respuesta y la lleva de regreso al cliente para procesamiento. El protocolo que es utilizado entre el cliente y el servidor está basado en el protocolo de HTTP, y maneja utilizando un objeto del lado de cliente, tal como XMLHTTP. El XMLHTTP (Protocolo de Transferencia de Hipertexto del Lenguaje de Marcación Extensible) es un grupo de APIs que permite al CML, HTML o datos binarios ser transmitidos a y desde servidores web en el Internet utilizando HTTP. Una ventaja del XMLHTTP es que cuando los archivos que son programas de ASPs o CGI son consultados desde el cliente, el XMLHTTP puede ser utilizado para que el cliente transparentemente recupere la última información sin que el usuario tenga que renovar repetidamente el navegador. Se pueden utilizar otros tipos de objetos para proporcionar este servicio. Un cliente invoca un método en el servidor al emitir una solicitud de HTTP contra el URL que está codificado con información con respecto al método para invocar. El URL es de codificado en el lado de servidor para asegurar que el servicio solicitado se enganche en la solicitud y se llame al URL requerido por método. El propio URL codifica el esquema de solicitud. Los datos necesarios para completar la respuesta son codificados en el cuerpo de la solicitud de HTTP. La arquitectura y métodos aquí descritos pueden ser realizados en una variedad de sistemas de procesamiento. Se ilustra un ejemplo de un sistema de procesamiento adecuado para implementar la presente invención en la Figura 1. La Figura 1 ilustra un ejemplo de un ambiente de sistema de cómputo general adecuado 100 en el que se puede implementar la invención. El ambiente de sistema de cómputo 100 solo es un ejemplo de un ambiente de cómputo adecuado y no pretende sugerir ninguna limitación al alcance de uso o funcionalidad de la Invención. El ambiente de cómputo 100 tampoco debe ser interpretado como teniendo ninguna dependencia o requerimiento que se relaciona a cualquiera o combinación de los componentes ¡lustrados en el ambiente operativo ilustrativo 100. La invención opera con numerosos otros ambientes o configuraciones de sistema de cómputo de propósito general o de propósito especial. Ejemplos de sistemas de cómputo, ambiente y/o configuraciones bien conocidos que pueden ser adecuados para utilizarse con la invención incluyen, pero no se limitan a, computadoras personales, computadoras de servidor, dispositivos portátiles o manuales, sistemas de multiprocesador, sistemas a base de microprocesador, cajas de TV por cable, electrónica de consumidor programable, PCs de red, minicomputadoras, macrocomputadoras, ambiente de cómputo distribuidos, que incluyen cualquiera de los sistemas o dispositivos anteriores, y similares. La invención puede ser descrita en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, que se ejecutan a través de una computadora. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. La invención también puede ser practicada en ambientes de cómputo distribuido, en donde se realizan tareas a través de dispositivos de procesamiento remotos que están enlazados a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden ser localizados en medios de almacenamiento de computadora tanto local como remota, incluyendo dispositivos de almacenamiento de memoria. Con referencia a la Figura 1, un sistema ilustrativo para ¡mplementar la invención incluye un dispositivo de cómputo de propósito general en la forma de una computadora 110. Los componentes de la computadora 110 pueden incluir, pero no se limitan a, una unidad de procesamiento 120, una memoria de sistema 130, y un conductor común de sistema 121 que acopla varios componentes del sistema, incluyendo la memoria de sistema a la unidad de procesamiento 120. El conductor común de sistema 121 puede ser cualquiera de los varios tipos de estructuras de conductor común incluyendo un conductor común de memoria o controlador de memoria, un conductor común periférico, y un conductor común local utilizando cualquiera de una variedad de arquitecturas de conductor común. A manera de ejemplo, y no de limitación, dichas arquitecturas incluyen el conductor común de Arquitectura Estándar de la Industria (ISA), conductor común de Arquitectura de Microcanal (MCA), conductor común de ISA mejorado (EISA), conductor común local de Asociación de Estándares de Video Electrónica (VESA), y conductor común de interconexión de componente periférico (PCI) también conocido como conductor común de mézanme. La computadora 110 típicamente incluye una variedad de medios legibles por computadora. Los medios legibles por computadora pueden ser cualesquiera medios disponibles que puedan ser accesados por la computadora 110 e incluyen medios tanto volátiles como no volátiles, medios removibles como no removibles. A manera de ejemplo, y no de limitación, los medios legibles por computadora pueden comprenden medios de almacenamiento de computadora y medios de comunicación. Los medios de almacenamiento de computadora incluyen medios tanto volátiles como no volátiles, removibles como no removibles, implementados en cualquier método o tecnología para almacenar información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento de computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria instantánea u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda ser utilizado para almacenar la información deseada y que pueda ser accesado por la computadora 110. Los medios de comunicación típicamente representan instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluyen cualquiera medio de suministro de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características fijadas o cambiadas de tal manera que codifica la información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación incluyen medios mediante cables, tales como una red con cables o una conexión de cable directo, y medios inalámbricos tales como medios acústicos, RF, infrarrojos y otros medios inalámbricos. También se deben incluir dentro del alcance de medios legibles por computadora, combinaciones de cualquiera de los anteriores. La memoria de sistema 130 incluye medios de almacenamiento de computadora en la forma de memoria volátil y/o no volátil tal como memoria de solo lectura (ROM) 131 y memoria de acceso aleatorio (RAM) 132. Un sistema de entrada/salida básico 133 (BIOS), conteniendo las rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora 110, tal como durante el arranque, típicamente está almacenado en la ROM 131. La RAM 132 típicamente contiene datos y/o módulos de programa que son inmediatamente accesibles a y/o en realidad son operados a través de la unidad de procesamiento 120. A manera de ejemplo, y no de limitación, la Figura 1 ¡lustra un sistema operativo 134, programas de aplicación 135, otros módulos de programa 136 y datos de programa 137. La computadora 110 también puede incluir otros medios de almacenamiento de computadora removibles/no removibles, volátiles/no volátiles. A manera de ejemplo solamente, la Figura 1 ilustra una unidad de disco duro 140 que lee o escribe a medios magnéticos no removibles, no volátiles, una unidad de disco magnético 151 que lee de o escribe a un disco magnético removible, no volátil 152, y una unidad de disco óptico 155 que lee de o escribe a un disco óptico removible, no volátil 156, tal como un CD-ROM u otros medios ópticos. Otros medios de almacenamiento por computadora removibles/no removibles, volátiles/no volátiles que pueden ser utilizados en el ambiente operativo ilustrativo incluyen, pero no se limitan a, casetes de cinta magnética, tarjetas de memoria instantánea, discos versátiles digitales, vídeo cinta digital, RAM de estado sólido, ROM de estado sólido, y similares. La unidad de disco duro 141 típicamente está conectada al conductor común de sistema 121 a través de una ¡nterfase de memoria no removible, tal como la interfase 140, y la unidad de disco magnético 151 y la unidad de disco óptico 155 típicamente están conectadas al conductor común de sistema 121 a través de una interfase de memoria removible, tal como la interfase 150. Las unidades y sus medios de almacenamiento de computadora asociados discutidos anteriormente e ilustrados en la Figura 1, proporcionan almacenamiento de instrucciones legibles por computadora, estructuras de datos, módulos de programa, y otros datos para la computadora 110. En la Figura 1, por ejemplo, la unidad de disco duro 141 se ilustra almacenando el sistema operativo 144, programas de aplicación 145, otros módulos de programa 146, y datos de programa 147. Observar que estos componentes pueden ser ya sea iguales a o diferentes del sistema operativo 134, programas de aplicación 135, otros módulos de programa 136, y datos de programa 137. El sistema operativo 144, los programas de aplicación 145, otros módulos de programa 146, y los datos de programa 147 se les proporcionan diferentes números aquí para ilustrar que, a un mínimo, son copias diferentes. Un usuario puede introducir comandos e información a la computadora 20 a través de dispositivos de entrada, tales como un teclado 162 y un dispositivo de señalamiento 161, comúnmente denominado como un ratón, seguibola, o almohadilla sensible al tacto. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, una palanca de mandos, almohadilla de juegos, antena parabólica, escáner, o similares. Estos y otros dispositivos de entrada por lo regular están conectados a la unidad de procesamiento 120 a través de una ¡nterfase de entrada de usuario 160 que está acoplada al conductor común de sistema, pero pueden ser conectados a través de otra interfase y estructuras de conductor común, tal como un puerto paralelo, puerto de juegos, o un conductor común en serie universal (USB). Un monitor 191 u otro tipo de dispositivo de presentación también está conectado ai conductor común de sistema 121 a través de una interfase, tal como una interfase de vídeo 190. Además del monitor, las computadoras también pueden incluir otros dispositivos de salida periféricos tales como bocinas 197 e impresoras 196, los cuales pueden ser conectados a través de una interfase periférica de salida 190. La computadora 110 puede operar en un ambiente en red utilizando conexiones lógicas a una o más computadoras remotas, tal como una computadora remota 180. La computadora remota 180 puede ser una computadora personal, un servidor, un enrutador, una PC de red, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos anteriormente con relación a la computadora 110, aunque solo sea ilustrado a un dispositivo de almacenamiento de memoria 181 en la Figura 1. Las conexiones lógicas ilustradas en la Figura 1 incluyen - una red de área local (LAN) 171 y una red de área amplia (WAN) 173, pero también puede incluir otras redes. Dichos ambientes en red son lugares comunes en oficinas, redes de computadora entre empresas, intranets e Internet. Cuando se utiliza en un ambiente en red de LAN, la computadora 110 está conectada a la LAN 171 a través de una interfase de red o adaptador 170. Cuando se utiliza en un ambiente en red de WAN, la computadora 110 típicamente incluye un módem 172 u otros medios para establecer comunicaciones a través de la WAN 173, tal como el Internet. El módem 172, el cual puede ser interno o externo, puede ser conectado al conductor común de sistema 121 a través de la interfase de entrada de usuario 160, u otro mecanismo apropiado. En un ambiente en red, los módulos de programa ¡lustrados con relación a la computadora 110, o sus porciones, pueden ser almacenados en el dispositivo de almacenamiento de memoria remoto. A manera de ejemplo, y no de limitación, la Figura 1 ¡lustra programas de aplicación remotos 185 que residen en el dispositivo de memoria 181. Se apreciará que las conexiones de red mostradas son ilustrativas y se pueden utilizar otros medios para establecer un enlace de comunicaciones entre las computadoras. Con el fin de implementar aplicaciones que utilizan la arquitectura de la presente invención, los componentes de lado de cliente y servidor de la arquitectura deben ser instalados. La Figura 2A muestra un primer método para crear un ambiente del lado de cliente de acuerdo con la presente invención. La Figura 2B muestra una perspectiva lógica de la arquitectura. En la Figura 2A, en el paso 202, un desarrollador de una aplicación web creada a una aplicación a base de web que utiliza herramientas en el servidor. La aplicación creada incluirá funciones y características que utilizan métodos y clases que tienen atributos. En una modalidad, el desarrollador puede tomar lugar en cualquier número de lenguajes de programación de aplicación. En el presente ejemplo, el desarrollo toma lugar en el lenguaje de programación de C#, que es un lenguaje de programación orientado a objetos de Microsoft que está diseñado para trabajar con la plataforma de .NET. La plataforma de .NET es una plataforma de software para servicios web y aplicaciones web implementadas en el ambiente de cómputo distribuido. Una vez que desarrollen las aplicaciones y características en el paso 202, los métodos y clases existen en el servidor. En el paso 204, un desarrollador puede marcar como exportables aquellos objetos y métodos que el desarrollador busca hacer disponibles para el desarrollar de aplicación del lado de cliente. En una modalidad, todos los métodos que están disponibles en el lado de servidor pueden ser marcados para exportación. En el paso 206, las aplicaciones son recopiladas, resultando en bibliotecas de enlace dinámica y archivos ejecutables. Después de que las aplicaciones son recopiladas, en el paso 208, un procedimiento de generación de código (CodeGen) examina las bibliotecas de enlaces dinámicos y archivos ejecutables que han sido creados, y crea objetos macro para aquellas clases marcadas en el paso 204, así como código de servidor equivalente para correr en el servidor que delinea exactamente a los bosquejos de macro y objetos. En una modalidad, los objetos de cliente son creados en JavaScript, aunque se pueden utilizar otros lenguajes macro. Un aspecto único de la presente invención es la creación de tales objetos en un ambiente macro tal como JavaScript para el dispositivo de cliente. El uso de los objetos macro permite al usuario de máquinas macro-nativas en el software de navegación web en el cliente para implementar la arquitectura aquí descrita. En el paso 210, las clases de macro después son empacadas en uno o más archivos y después transmitirlos al cliente en el paso 210. Las nuevas funciones que son desarrolladas para las aplicaciones pueden crear nuevos métodos o nuevas clases. Como un resultado, el procedimiento puede girar de regreso al paso 202 para que cuando se desarrollen nuevas características, los pasos 204 al 210 sean repetidos para que las nuevas características ¡mplementadas en el servidor sean pasadas al ambiente del cliente.
La Figura 2B ¡lustra una vista lógica de la arquitectura de la presente invención. Para un usuario particular en un dispositivo de cliente, un ambiente es relativamente transparente. En un dispositivo de cliente, el usuario estará expuesto a características de usuario final en la forma de la aplicación a base de web. En un ejemplo, esto puede ser un servicio de correo electrónico a base de web tal como Hotmail de Microsoft, que incluye servicios de envió de mensaje de correo electrónico, funciones de calendario y funciones de contacto 212. La presentación del lado de cliente 214 es proporcionada por los bosquejos de contenido y macro 218 que utilizan datos proporcionados por el servidor. Un controlador de HTTP 220 tanto en el lado de cliente como el lado de servidor controla comunicaciones entre los dispositivos de cliente y servidor. Un ordenador 222 y un despachador 224 coordinan proporcionar solicitudes del controlador de HTTP al código de modelo de objeto 226 creado por el procedimiento de CodeGen. Por ejemplo, cuando un cliente llama a una función de revisión de. ortografía en el servidor, la interfase de cliente es realmente una función de JavaScript que toma un orden de macro. El procedimiento de orden en el cliente, implementado por el modelo de objeto 216 construido en hospedaje 214, toma cada orden (o elemento o combinación de órdenes o elementos) y lo construye para el formato de transporte. Generalmente, un orden toma la forma de una fila de elementos separada por una coma, en donde cada elemento sería un orden, la fila de elemento o alguna otra estructura. El procedimiento de orden en el servidor es recursivo, evaluando elementos dentro del orden. Tanto el modelo de objeto 226 como el modelo de objeto de JavaScript 216 son fuertemente asignados con tipo, así un orden enviado para un objeto dado tiene un número bien definido de elementos en el orden, con tipos exactos, y para tipos de compuesto, el formato exacto de tipo de compuesto. El modelo de objeto interactúa con los datos reales 232 a través de una capa de datos 230 y administrador de almacenamiento 228. Debido a que se crean los bosquejos basándose en el modelo de objeto de servidor 226, los bosquejos tienen un delineado directo de tipos y atributos para la capa de datos 230. Con el fin de proporcionar al ambiente de lado de cliente en un sistema de usuario, como se notó anteriormente, uno o más archivos macro necesitan ser enviados al dispositivo de cómputo de cliente y almacenados en el dispositivo. Con aplicaciones a base de web, típicamente tales aplicaciones son proporcionadas por un proveedor de servicio. Un proveedor de servicio que proporciona aplicaciones utilizando la arquitectura importante de la presente invención puede requerir que un usuario cree un registro o cuenta para acceder un servicio, y el paso de creación de registro o cuenta puede ser utilizado para instalar el ambiente de cliente. En este caso, un proveer de servicio puede ser considerado un procedimiento implementado por humano o computadora que rige la provisión del servicio o aplicación a base de web. En la Figura 3, un usuario creará una cuenta o registro en el paso 300. Una vez que el usuario inicia un registro, la primera experiencia del usuario será descargada a los archivos de JavaScript de aplicación que son descargados en el paso 302 a la computadora del usuario. En el paso 304, cuando el usuario comienza la interacción con el servicio web proporcionado por el servidor de aplicación, una máquina macro utiliza los objetos en una computadora de usuario para comunicar el protocolo de la presente invención con las clases y métodos de aplicación del lado de servidor. Se entenderá que un procedimiento correspondiente que.
corre en el servidor, que recibe la solicitud para un servicio particular o aplicación del usuario o inicia el procedimiento de descarga del ambiente de cliente para la aplicación. La Figura 4 es un diagrama de bloque de un sistema adecuado para implementar la arquitectura y protocolo de la presente invención. La Figura 4 muestra un dispositivo de cliente 460 que puede ser un dispositivo de cómputo 100 mostrado en la Figura 1, y el servidor de aplicación 420. Como se utiliza aquí "servidor" o "servidor de red" incluye cualquier máquina o combinación de máquinas que tienen datos y aplicaciones mantenidas en ellos o como se muestra en la Figura 4 como un bloque etiquetado 480. El software de navegación 300 que se ejecuta en una máquina de cliente se comunica a través de la interfase de red 402 con el servidor de aplicación 480. La comunicación entre el dispositivo de cliente 460 y el servidor 480 puede ocurrir a través de una o más solicitudes 402 y respuestas 404 en una red, o una combinación de redes públicas y privadas, tal como Internet. La comunicación entre el dispositivo de cliente 460 y el servidor 480 típicamente utilizan el protocolo de HTTP, pero la invención no está limitada al uso de HTTP como el protocolo de transporte. El dispositivo de cliente 480 incluye un componente de transporte 410 que controla algunos de los procesamientos de la respuesta 404. Cuando los datos de contenido son regresados, los datos son pasados del componente de transporte 410 y a través de otras capas de código 420 para una máquina macro 426 y un analizador/interprete 422. El analizador después analiza e interpreta el contenido para presentar al usuario a través de la interfase de usuario 424. El analizador 422 puede invocar una máquina macro 426 cuando sea necesario para interpretar cualquier macro fijado en una referencia por el contenido. El contenido también puede ser almacenado en el almacenamiento local 436 que es accedido a través de un administrador de almacenamiento 455 que está incluido en o de otra forma asociado con el componente de transporte 410. El almacenamiento 436 también puede incluir una tabla de memoria caché, una memoria caché de datos, cookies (galletas), y un contenedor de JavaScript incluyendo los archivos de JavaScript mencionados anteriormente. El componente de transporte 410 incluye o de otra forma está asociado con el administrador de almacenamiento 455 que almacena y recupera JavaScript y otra información, tal como cookies en, por ejemplo un contenedor de cookies. Un administrador de macro 450 implementa solicitudes de la máquina macro que ejecuta bosquejos y objetos de los macros del lado de cliente proporcionados por la arquitectura. Como se discute más adelante, el administrador macro 450 controla dos tipos de llamados al servidor 480, llamados sincrónicos y llamados asincrónicos que están dirigidos a funciones y objetos en el servidor 480. Estas solicitudes son descritas más adelante con respecto a la Figura 3. El servidor 480 puede incluir un ambiente operativo adecuado 492 en el cual se puede ¡mplementar la invención. La modalidad operativa 492 solo es un ejemplo de un ambiente operativo adecuado y no pretende sugerir ninguna limitación al alcance de una funcionalidad de usuario de la invención. Un ejemplo de un ambiente operativo con los sistemas operativos de la familia de Windows disponibles de Microsoft. El ambiente puede incluir una estructura de trabajo de aplicación 460 que es una plataforma que incluye el diseño y objetos de tiempo de funcionamiento, y controles que permiten a las aplicaciones correr en el servidor web. Aunque la estructura de trabajo no es requerida, ciertos servicios aquí descritos pueden estar incluidos como componentes de la estructura de trabajo, o de otra forma pueden ser incorporados en el sistema operativo o proporcionados como aplicaciones independientes que corren el sistema operativo. La estructura de trabajo de aplicación puede ser esa que es descrita anteriormente como la estructura de trabajo de aplicación de .NET disponible de Microsoft Corporation. La estructura de trabajo de aplicación puede incluir clases de recurso que implementan funciones tal como codificación críptica, compresión y autentificación que pueden ser utilizados en conjunto con la presente invención. Proporcionado dentro de la estructura de trabajo de aplicación está el contenido de aplicación desarrollado 482, objetos 484, y métodos 486. Las aplicaciones 489 pueden estar comprendidas de una o más clases y métodos. Un recopilador 487 crea bibliotecas de enlace dinámico y archivos ejecutables para las aplicaciones 489. Una máquina de CodeGen 495 también es mostrada dentro de la estructura de trabajo de aplicación 460. Como se notó anteriormente, una vez que los objetos y clases son creados para una aplicación particular 489, y recopilados por la computadora 487, la máquina de CodeGen 495 creará tanto los objetos macros del lado de clientes, un ordenador 494, despachador 492 y código de aplicación de servidor 490. La interacción entre métodos y clases en las aplicaciones en el servidor toma lugar con los objetos del lado de servidor. Las respuestas son proporcionadas a los objetos de "poder" del lado de servidor 490 que después proporcionan respuesta al dispositivo de cliente basándose en el llamado del poder del lado de cliente. La máquina de CodeGen 495 opera a través de una técnica llamada "reflexión" para analizar una pieza recopilada de software para producir automáticamente un grupo de analizadores, convertidores, formateadotes, y escritores de texto (colectivamente "bosquejos") que implementan el orden, desorden, y despachado. Un mecanismo de reflexión es proporcionado en la estructura de trabajo de aplicación, y es una técnica para descubrir las definiciones de clase de objeto en el tiempo de funcionamiento. En efecto, la máquina de CodeGen es un recopilador que recopila código recopilado. La máquina de CodeGen toma variables, tal como sus propias condiciones, información contextual en cuenta. Los bosquejos de CodeGen despachan funciones asincrónicamente como parte de su estructura de trabajo generada automáticamente. También es capaz de representar tipos de colección tal como tablas de mezcia; esta característica no está disponible en SOAP. Y finalmente, el CodeGen es capaz de propagar uniformemente excepciones de servidor al cliente. Los bosquejos de JavaScript resultantes incluirán definiciones que coinciden con la definición de atributo de tiempo de funcionamiento de las clases y objetos de la aplicación del servidor. Una vez que se crea el código de aplicación de servidor 490, el código interactúa como un administrador de almacenamiento 455 en el servidor 480 para acceder a los datos 498. Las solicitudes del dispositivo de cliente 460 son recibidas por el ordenador 494 y distribuidas por el despachador 492. Cuando se recibe una solicitud por el servidor 480, el despachador le dice al servidor que funciones están intentando ejecutar el cliente. El llamado de invocación es construido en el URL de solicitud recibido del cliente como parte de la solicitud 404. En un aspecto, el URL incluye una representación y un espacio de nombre de .NET. Todo el código de programación para la aplicación particular aparece en el espacio de nombre "espacio de nombre de aplicación". El despachador 492 cierra esa información. El ordenador 494 separa los componentes del URL, examina cada elemento y cuando coincide, el despachador delega la información en la solicitud a través de esa función en el código de aplicación 490. La Figura 5 es un cuadro de flujo que ilustra el procedimiento general para una aplicación de revisión de ortografía que corre en el cliente para invocar un método que corre en el servidor y recibe respuestas del servidor. Generalmente, cuando un cliente gana a una función de revisión de ortografía en el servidor, la interfase de cliente realmente es una función de macro que toma como entrada un orden macro. El administrador macro incluye un procedimiento de orden que toma cada orden y lo construye para un formato de transporte corriente arriba. En una modalidad, el formato es un orden visto como tensores seguidos por la lista separada por coma de los elementos dentro. En la Figura 5, una función de revisión de ortografía será generalmente iniciada por alguna interacción de usuario en el paso 505. La interacción de usuario puede ser un llamado específico a la función en otro programa de aplicación, tal como una aplicación de correo electrónico o editor de texto, o la función puede ser automáticamente invocada cuando el usuario presiona una instrucción de "enviar" para un mensaje de correo electrónico. En el paso 510, la aplicación de JavaScript "revisar ortografía", de acuerdo con las funciones definidas aquí, permitirá una solicitud que incluye datos o atributos para la función del lado de servidor "revisar ortografía". En el paso 515, los datos son ordenados en el formato con tipo para la función de "revisar ortografía" en el servidor y en el paso 520, se envía una solicitud de XMLHTTP a través del componente de transporte al método del lado de servidor. Los ejemplos de la solicitud son presentados más adelante con respecto a las Figuras 7-10. En el lado de servidor, la solicitud será desordenada y convertida en un objeto con tipo. Los pasos 525, 530, 535 y 540 son realizados en el servidor de aplicación 480. En el paso 525, cuando se recibe la solicitud, será operado por el ordenador 494 y el despachador 492 para despachar el objeto a funciones específicas en el servidor en el paso 525. Un método invocado después operará en los datos de solicitud en el paso 530 y regresará alguna respuesta. La respuesta es convertida a una respuesta de JavaScript en el paso 535, y transmitida al cliente en el formato de corriente abajo a través del código de servidor de aplicación 490. El poder del lado de servidor cambia los resultados de un llamado de función del lado de servidor a JavaScript, y el macro es enviado de regreso al cliente e interpretado por administrador de macro. La máquina de macro analiza la respuesta de JavaScript y la evalúa. De esta manera, un "desordenador" no necesariamente está en el cliente, una función de EVAL cuida el equivalente del desorden. Los pasos 545 y 550 ocurren en el cliente. Con el recibo de la respuesta a través del macro del lado de cliente en el paso 545, se realizará una operación de EVAL en la respuesta, la función de EVAL toma una fila que representa una expresión de JavaScript, declaración o secuencia de declaraciones la expresión puede incluir variables y propiedades de objetos existente. Si el argumento representa una expresión, el EVAL evalúa la expresión. Si el argumento representa una o más declaraciones de JavaScript, el EVAL realiza las declaraciones. La salida de la función de EVAL es enviada al bosquejo solicitante en el paso 550. La Figura 6 ¡lustra la salida del procedimiento de CodeGen para un "encabezado de mensaje" de clase. La clase de encabezado de mensaje puede comprender información proporcionada en un mensaje de correo electrónico. Como se muestra en la Figura 6, un encabezado de mensaje de correo electrónico típico puede incluir un sujeto, de dirección, de nombre, fecha, tamaño, enlace de mensaje y un icono de estado. La definición de objeto de C# 620 es creada en el servidor, mientras la definición de objeto de JavaScript 610 creada para el cliente a través del procedimiento de CodeGen. La definición de objeto de C# incluye una declaración de atributo 622 para los atributos antes mencionados del objeto seguido por un constructor de macro 624 que define las filas "sujeto = strSujeto, deDirección = strDeDireción, deNombre = strDeNombre, fecha = dFecha, tamaño = ¡Tamaño, msgEnlace = strMsgEnlance, ellcono = olcono"). La definición de objeto de JavaScript correspondiente incluye elementos 612 de la definición de objeto de C# así como la definición de función para el espacio de nombre "espacio de nombre de servidor" y función de encabezado de mensaje "mensajehrd" en el servidor que contiene el objeto C#. La Figura 7 ¡lustra un ejemplo de una interfase de C# ilustrativa 710 para la función "obtener mensajes" y está asociada con el bosquejo de JavaScript 720. La función Obtener Mensajes toma como su argumento el objeto de MensajeHdr, definido anteriormente. La interfase de C# del lado de servidor "obtener mensaje" requiere una salida definida de una carpeta de usuario particular para un usuario que tiene un buzón en un servidor 280. El bosquejo de JavaScript del lado de cliente 720 incluye una función que llama al objeto conocido como "gXMLHTTPPoder" que coordina solicitudes de XMLHTTP asincrónicas y sincrónicas para el servidor. Las funciones de gXMLHTTPPoder son discutidas más adelante con respecto a la Figura 13. En el ejemplo de la Figura 7, la función "obtener mensajes" es una solicitud sincrónica. Como se notó anteriormente, al formular solicitudes para el servidor, el administrador de macro 255 puede realizar una solicitud sincrónica o asincrónica. En una solicitud sincrónica, como se detalló más adelante, el cliente reaccionará en una forma muy similar a una función de "PEGAR" en HTTP. Eso es, aunque un cliente solicitará algunos datos del método del lado de servidor, y esperará, manteniendo la aplicación suspendida, hasta que los datos sean recibidos desde el servidor. En una solicitud sincrónica el JavaScript hace un llamado al servidor para recuperar los datos, y espera a que el servidor regrese antes de proporcionar los resultados al JavaScript en el Navegador web. La solicitud sincrónica es esencialmente un llamado de bloqueo, en donde el navegador es congelado hasta que el servidor regresa. Una solicitud asincrónica no hace un llamado a los datos de inmediato. Una solicitud asincrónica es reemplazada en una consulta y la solicitudes son enviadas al servidor en el llamado de no bloqueo a través de un objeto de XMLHTTP. Por ejemplo, si uno solicita que se implemente una función de revisión de ortografía en un navegador, uno puede continuar escribiendo un correo electrónico mientras la función de revisión de ortografía está llevándose a cabo en el servidor. Cuando los datos regresan el JavaScript recoge los llamados e inicia la función de revisión de ortografía de nuevo. La Figura 8 ilustra un ejemplo de una solicitud 810 y una respuesta 820 generada por el macro y función de Obtener Mensajes. La solicitud corriente arriba toma el formato general de un URL en el formato: Servidor + Versión + Espacio de Nombre del Servidor + Id de clase + Id de método. En el ejemplo mostrado en la Figura 8, la operación de PEGAR incluye una solicitud para la función de Obtener Mensajes para una carpeta dada F000000001. La respuesta al PEGAR es un nuevo orden incluyendo elementos definidos en la definición de objeto C# del MensajeHdr que están directamente delineados para la definición de macro 610. El ejemplo de respuesta 820 muestra un orden de objetos de MensajeHDR recuperados del servidor de aplicación. Como tal, el formato de respuesta (que en este caso es un orden pero puede incluir otros formatos) es exactamente conocido para el objeto con macro en el cliente, que después puede analizar los datos recibidos en el orden y proporcionarlos a cualquiera de los macros de presentación en el cliente para presentarse a la interfase de usuario de dispositivo de procesamiento de cliente. Las Figuras 9 y 10 ilustran ejemplos adicionales de los objetos y funciones que son creados por el procedimiento de CodeGen 290 que opera en la estructura de trabajo de aplicación 260. Los ejemplos en las Figuras 9 y 10 son para dos métodos de revisión de ortografía que pueden ser utilizados en una aplicación de revisión de ortografía. La Figura 9 ilustra la función "revisar ortografía de palabra", que toma como entrada una palabra individual, revisa su ortografía, y regresa una indicación si la ortografía es correcta o incorrecta. La función regresa un resultado verdadero/falso. El bosquejo de macro 910 ilustra un llamado sincrónico "invocar sincronización ILUSTRATIVA" para el objeto gXMLHTTP. Como un resultado, el macro 910 esperará e! regreso de la respuesta para el método 920 antes de liberar la aplicación en el cliente. La Figura 10 ilustra la interfase "revisar ortografía" 1010 que toma como entrada un número de palabras y responde con una fila. La función de macro 1020 incluye un filtro adicional, "Filtro dimensional_palabras" que es un macro que puede ordenar el llamado en el formato de protocolo. El macro 1020 es un ejemplo de un llamado de solicitud asincrónico "Invocar Asincrónico ILUSTRATIVO" para el objeto de gXMLHTTP. Como un resultado, el macro 1020 ordenará solicitudes para el procesamiento y espera para resultados sin congelar la máquina de macro del navegador. El macro 1020 también incluye una función de llamado de regreso proporcionado por macro, que permite al poder de gXMLHTTP esperar respuestas del servidor que están corriendo mientras el cliente continúa realizando otras funciones. La Figura 11 ilustra otra relación de interfase/bosquejo. La Figura 12 muestra una solicitud/respuesta ilustrativa para la relación de interfase/bosquejo mostrada en la Figura 11. En la Figura 11, la interfase para la función "revisar ortografía con sugerencias" es mostrada y toma como entrada una oración (o secuencia de oraciones), y responde con una fila de "sugerencias". La invocación del objeto de gXMLHTTP es asincrónica en este ejemplo. Una solicitud de PEGAR ilustrativa para la función de revisar ortografía con sugerencias mostrada en la Figura 11 es mostrada en la Figura 12. La función de PEGAR de nuevo es proporcionada en el formato Servidor + Espacio de Nombre de Servidor + Versión + Id de Clase + Id de Método, y en este ejemplo el protocolo definido incluye la definición de fila accesible para la función de Revisar Ortografía con Sugerencias. La respuesta es proporcionada en nuevo orden que comprende dos órdenes anidados. El orden es un orden de JavaScript estándar que puede ser interpretado a través de la máquina de JavaScript y ambiente con macro en el cliente. Debido a que la función de revisar ortografía de JavaScript 1120 está esperando un orden de fila, el orden puede ser alimentado directamente en el ambiente de macro y operado por la máquina virtual de JavaScript. De ahí, desde el navegar al servidor, el protocolo es altamente optimizado para transporte. Los llamados a los objetos del lado de servidor y métodos son proporcionados en un formato fuertemente con tipo ya que la función del lado de cliente incluye la definición de tipo en el objeto de servidor. Los datos son regresados al cliente en JavaScript, y pueden ser caracterizados con EVAL en el lado de cliente por la función de EVAL estándar en el lenguaje de JavaScript. La función de EVAL puede determinar si el JavaScript es una función, una creación de un orden, o la creación de un objeto, para que después del procedimiento de evaluación, también se convierta en un objeto en el modelo de objeto de JavaScript. La Figura 13 ilustra el objeto de gXMLHTTP que controla solicitudes de XMLHTTP asincrónicas y sincrónicas para el servidor. Inicialmente, en el paso 1310, el procedimiento determina la configuración de navegador exacta y si el navegador es adecuado para utilizarse en la arquitectura de la presente invención. En el paso 1312, las variables de inicialización son pasadas al objeto que incluye identificaciones de versión, servidor y espacio de nombre. El objeto de XMLHTTP incluye un constructor que inicia una función de XMLHTTP sincrónica, una función XMLHTTP asincrónica, un grupo de artículos de trabajo o bloques de solicitud, un bloque de solicitud actual que está en servicio, un cronómetro, y funciones de control de cookie. En el paso 1314, el método intenta iniciar el poder de XMLHTTP para comunicaciones de HTTP utilizando los servicios de HTTP del componente de transporte 410 del navegador. Después, en el paso 1315, el método invoca las funciones sincrónicas o asincrónicas, dependiendo en la definición de macro de llamado. Si el método invoca una solicitud de XMLHTTP sincrónica, el argumento de macro que llama el método de XMLHTTP es suspendido y no regresa los datos hasta que sucede el XMLHTTP o se agota. En el paso 1316 una solicitud de XMLHTTP sincrónica comenzará al generar el llamado de URL para el servidor, los ejemplos que son mencionados anteriormente. Una vez que se genera el URL, en el paso 1318, se abre una conexión sincrónica y el URL colocado para el servidor en el paso 1320. Subsecuentemente, el método espera una respuesta que puede ser un parámetro individual, texto de respuesta. Una vez que recibe la respuesta o se agota, es proporcionada al macro de llamado y el argumento de macro es liberado en el paso 1324. La respuesta después de eso puede ser evaluada de acuerdo con la siguiente descripción utilizando la función de EVAL en el cliente. En el paso 1315, si la solicitud es para una solicitud de XMLHTTP sincrónica, entonces en el paso 1330 de forma similar comienza con la generación de un URL. En este caso, el URL incluye una función de llamado de regreso además de los componentes identificados anteriormente. El llamado de regreso es una función proporcionada por usuario que el poder de XMLHTTP invoca después de que se ha completado el llamado asincrónico. El texto de respuesta de XMLHTTP toma un parámetro. Después de genera el URL, en el paso 1334, el sistema pregunta al llamado asincrónico y establece un cronómetro de tiempo agotado 1336. El paso de consulta 1334 llama a una función de despachador que determina en el paso 1338 si existe un bloque que actualmente se está ejecutando en el servidor. Si es así, la función regresa a dormirse al observar el paso 1336. Mientras el grupo de consulta no ese vacío, existe una solicitud en el procedimiento y esa solicitud cuidará de invocar al despachador una vez que ha terminado. Después de eso, una ventana de tiempo agotado solo es llamada cuando detecta que el grupo ya está vacío. Una vez que el bloque está vacío en el paso 1338, se abre una conexión asincrónica en el URL colocado en el paso 1340. Una vez que un llamado es consultado en el paso 1342, un controlador de llamado de regreso es iniciado en 1344. En controlador de llamado de regreso espera a que la operación de XMLHTTP se complete y se ejecute el llamado de regreso. Cuando la respuesta es recibida en 1344, la solicitud actual es removida de la consulta de despachador 1346, y el despachador es establecido para además no consultar en el paso 1348. La respuesta es pasada al macro de llamado en el paso 1350. La descripción detallada anterior de la invención ha sido presentada para propósitos de ilustración y descripción. No pretende ser exhaustiva o limitar la invención a la forma precisa descrita. Muchas modificaciones y variaciones son posibles en vista de la enseñanza de lo anterior. Como se nota aquí, numerosas variaciones en la arquitectura de la presente invención son posibles sin apartarse del alcance y contenido de la presente invención. En una modalidad, las solicitudes y respuestas pueden ser comprimidas y codificadas crípticamente. Las modalidades descritas fueron elegidas con el fin de explicar mejor los principios de la invención y su aplicación práctica para permitir con ello que otros expertos en la técnica utilicen mejor la invención en varias modalidades y con varias modificaciones que sean adecuadas para el uso particular contemplado. Pretende que el alcance de la invención sea definido por las reivindicaciones anexas a esto.