ES2252837T3 - Sistema y procedimiento para dirigir la conexion entre un servidor y un nodo cliente. - Google Patents
Sistema y procedimiento para dirigir la conexion entre un servidor y un nodo cliente.Info
- Publication number
- ES2252837T3 ES2252837T3 ES98923426T ES98923426T ES2252837T3 ES 2252837 T3 ES2252837 T3 ES 2252837T3 ES 98923426 T ES98923426 T ES 98923426T ES 98923426 T ES98923426 T ES 98923426T ES 2252837 T3 ES2252837 T3 ES 2252837T3
- Authority
- ES
- Spain
- Prior art keywords
- application
- window
- server
- client
- html page
- 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.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/549—Remote execution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Communication Control (AREA)
Abstract
Se presenta un administrador de conexiones que suministra control de comunicación en un servidor de un sistema de cliente servidor, que permite que un nodo de cliente establezca comunicaciones rudimentarias con un puerto de servidor designado y entonces desplaza la conexión hacia un puerto de comunicación específico para la aplicación que se ejecuta en el servidor. El puerto de comunicación específico se configura entonces mediante el administrador de comunicaciones con los controladores de protocolo que se necesitan en el nodo del cliente. Una aplicación puede visualizarse en una página HTML. En una realización, los mismos datos pueden transmitirse básicamente de forma simultánea desde una aplicación que se ejecuta sobre un nodo de servidor al menos dos nodos de cliente. El nodo de servidor en el sistema cliente-servidor puede descargar y ejecutar aplicaciones escritas en lenguajes interpretativos en nombre de los nodos de cliente asociados.
Description
Sistema y procedimiento para dirigir la conexión
entre un servidor y un nodo cliente.
La presente invención se refiere a la ejecución
de aplicaciones en un entorno cliente-servidor
distribuido y en especial, a la ejecución remota de aplicaciones
escritas en lenguajes interpretativos en un entorno
cliente-servidor.
Las redes informáticas cliente/servidor
normalmente requieren que el cliente y el servidor establezcan
comunicaciones de acuerdo con algún conjunto de normas
preestablecidas. Estas normas son denominadas protocolos de
comunicación. Dichos protocolos pueden estar predefinidos, de forma
que cada nodo cliente utilice el mismo protocolo de comunicaciones
que el nodo servidor. Otra posibilidad es que el servidor puede
guardar un registro del protocolo de comunicaciones usado para cada
cliente y utilizar ese protocolo para establecer comunicación con
el cliente cuando éste envíe una solicitud de comunicación con la
aplicación en el servidor.
Un problema asociado con tales procedimientos de
comunicación es que o bien el protocolo puede estar predefinido de
forma demasiado rígida para aplicaciones que no necesitan toda la
funcionalidad que se requiere, o bien el protocolo de cliente debe
ser conocido por el servidor antes de que el cliente pueda
comunicarse con aquel. La presente invención busca evitar tanto la
rigidez de un protocolo predefinido como la necesidad de un
conocimiento previo de contacto por parte del servidor.
El shadowing o duplicación (transmitir
datos destinados a un nodo cliente básicamente de modo simultáneo a
un segundo nodo cliente) y la difusión (trasmitir los mismos datos
básicamente de modo simultáneo a más de un nodo cliente) se han
efectuado normalmente por medio de una aplicación de transmisión
especializada en un nodo servidor y aplicaciones de receptor
especializadas en cada uno de los nodos de cliente. La duplicación
es útil para monitorizar el tráfico de datos y para crear una copia
redundante de información que se transmite a efectos de integridad
de los datos y seguridad del sistema. La difusión es útil para
proporcionar la misma información a muchos usuarios, cuando dicha
información es "en tiempo real" o cuando la información no
tiene en sí un comienzo o un final. Por ejemplo, un programa de
cotización de precios de acciones simplemente transmite los precios
actuales de diversas mercancías en una bolsa determinada y la lista
se repite con los últimos precios una vez que la lista de
mercancías está agotada. Por tanto es irrelevante para un usuario
el que éste no especifique al programa de cotización dónde comienza
la
lista.
lista.
Tales programas normalmente están escritos con un
programa de difusión en mente y requieren programas de receptor
especializados para recibir los datos transmitidos. Si una
aplicación no se ha escrito como programa de difusión, los datos
transmitidos por dicha aplicación normalmente no pueden difundirse
a múltiples nodos de cliente.
La presente invención intenta superar este
problema permitiendo que los programas no escritos para una
funcionalidad de difusión se usen para emitir datos por una
red.
Una red cliente/servidor especializada es la red
mundial de ordenadores normalmente conocida como "Internet",
que ha conocido un crecimiento explosivo en los últimos años. Gran
parte de este crecimiento se ha debido al incremento en popularidad
de la World Wide Web (WWW). La WWW es una recopilación de archivos
escritos por medio del HyperText Markup Language (Lenguaje de
Marcado de Hipertexto) (HTML), comúnmente denominado "páginas
Web". Puede accederse a los archivos y estos pueden mostrarse
por medio de aplicaciones especializadas conocidas como
"navegadores", que permiten al usuario acceder a los archivos
HTML utilizando una simple interfaz gráfica de usuario (IGU).
Los servidores que alojan archivos HTML pueden
comunicarse por medio del Protocolo de Transferencia de Hipertexto
(HTTP). El HTTP es un protocolo de aplicación que proporciona a los
usuarios acceso a los archivos (que pueden estar en diferentes
formatos como puede ser texto, gráficos, imágenes, sonido, vídeo,
etc.) usando el lenguaje de descripción de páginas HTML. El HTML
proporciona un formato de documento básico y permite al
desarrollador especificar "enlaces" de comunicación a otros
servidores y archivos. El uso de un navegador de cliente conforme
con el HTML supone la especificación de un enlace por medio de un
Localizador de Recursos Uniforme o "URL". Con dicha
especificación, el cliente efectúa una solicitud TCP/IP al servidor
identificado en el enlace y recibe una "página Web" a cambio.
Además, las organizaciones pueden suministrar archivos HTML que
sean accesibles desde dentro de la organización pero no desde la
WWW. Estas redes internas y colecciones de archivos en HTML son
denominadas comúnmente "Intranets".
Un archivo escrito por medio de HTML incluye
"etiquetas", que indican al navegador que muestra el archivo
cuándo deben efectuarse acciones especiales. Por ejemplo, una
etiqueta puede indicar al navegador: (1) que un archivo gráfico
debe mostrarse en un punto concreto del documento; (2) que
determinado texto debe centrarse, ponerse en negrita o formatearse
de otro modo; (3) que el fondo de un documento debe sombrease o
debe tener un diseño particular; o (4) que debe cargarse un archivo
HTML diferente en lugar del archivo HTML que el navegador está
mostrando en ese momento.
La popularidad de la World Wide Web y otras
aplicaciones HTML ha atraído los esfuerzos de marketing de un
amplio abanico de empresas que representan a una gran diversidad de
industrias. Puesto que diferenciarse de otras empresas se hace cada
vez más difícil, muchas de ellas han intentado superar la
naturaleza estática inherente al HTML. Asimismo, las organizaciones
que utilizan archivos en HTML como procedimiento de compartir
información han reconocido que una Intranet es un procedimiento útil
para proporcionar a diversos usuarios acceso a algo más que
simplemente información.
Un gran inconveniente de los archivos HTML, no
obstante, es que son intrínsecamente estáticos. Es decir, el HTML
es un lenguaje "sólo de lectura", lo que no permite fácilmente
la ejecución de aplicaciones dentro de una página en HTML. Las
empresas que buscan impulsar la popularidad y ubicuidad de la WWW
buscan cada vez más formas de integrar aplicaciones dentro de un
archivo HTML.
Los objetos ActiveX™ son un intento de
proporcionar archivos en HTML con la capacidad de mostrar
aplicaciones de ejecución. Un objeto ActiveX™ es un objeto de datos
que puede usarse con navegadores que tengan una interfaz ActiveX™.
Un inconveniente obvio de estos objetos es que si el navegador de
un usuario no tiene una interfaz ActiveX™ no puede mostrar la
aplicación de ejecución. Esto limita la utilidad de los objetos
ActiveX™, ya que un objetivo fundamental de la mayoría de las
páginas en HTML es ser vistas por el máximo de usuarios
posible.
Un lenguaje de programación llamado JAVA™ ha sido
propuesto también como una forma de permitir añadir código
ejecutable a un archivo en HTML. Puesto que JAVA™ es un lenguaje,
no requiere una interfaz de navegador específica y tiene una
audiencia potencialmente mayor. No obstante, un programa en JAVA™,
habitualmente denominado un applet, se descarga al cliente antes de
la ejecución. Esto puede ser problemático para los clientes que
carezcan de suficiente memoria para descargar el applet, e incluso
si el cliente tiene suficiente memoria, requiere que este espere
hasta que se haya descargado el applet. Además, puesto que JAVA™ es
en sí mismo un lenguaje de programación, las aplicaciones
existentes deben reescribirse en JAVA™ antes de poderse insertar en
una página Web.
Un primer aspecto de la presente invención es que
proporciona un procedimiento para mostrar salidas, producidas por
una aplicación que se ejecute en un servidor, en una página en
HTML. El procedimiento comprende los siguientes pasos:
(a) transmisión de un archivo a un cliente,
representando dicho archivo una primera página que incluye un
parámetro asociado a la definición de la ventana dentro de la
página cuando una aplicación de navegador muestra la página en el
cliente;
(b) recepción de información de la página
mostrada en el cliente para señalar la ejecución de una aplicación
en un servidor;
(c) creación de un canal de comunicaciones que
sea independiente de la aplicación del navegador entre la ventana
dentro de la página mostrada en el cliente y el programa de
aplicación que se ejecuta en el servidor, usando el parámetro de
ventana; y
(d) transmisión de salidas producidas por la
aplicación que se ejecuta en el servidor a través del canal de
comunicaciones al cliente para mostrarlas sin intervención de la
aplicación de navegador, en la ventana situada dentro de la página
mostrada.
Así pues, la presente invención proporciona un
procedimiento para mostrar una aplicación en ejecución en un
archivo en HTML que esté visualizándose sin que se requiera
reescribir la aplicación en un lenguaje especial y sin que el
navegador del usuario deba soportar una interfaz especializada. La
aplicación se ejecuta en el servidor, mitigando el tiempo de
descarga y las restricciones de memoria en el cliente. Además, un
cliente puede invocar la ejecución de múltiples aplicaciones para
múltiples páginas y viajar entre los documentos en HTML sin cerrar
ninguna de las aplicaciones.
En una realización preferente, un procedimiento
para mostrar una aplicación en ejecución en una página en HTML
comienza por la recepción de una información por parte del usuario
que señala que éste desea iniciar la ejecución de un programa de
aplicación. Los parámetros de la ventana en la que se ejecutará la
aplicación se determinan y se crea un canal de comunicación con la
ventana de aplicaciones en la página en HTML.
Las salidas del programa de aplicación, que se
ejecuta en un servidor, se muestran en la ventana de aplicaciones a
través del canal de comunicaciones.
Un aspecto adicional de la presente invención es
que proporciona un aparato para mostrar salidas, producidas por una
aplicación que se ejecuta en un servidor, en una página en HTML.
Este aparato comprende:
una pantalla de visualización de páginas para
mostrar una página con una ventana de ejecución de aplicación
definida en la misma;
un manejador de parámetros organizado para
recibir del visualizador de páginas parámetros asociados con la
ventana de ejecución de aplicación dentro de la página; y
un ejecutivo de red organizado para recibir
parámetros de dicho manejador de parámetros, hacer que se inicie la
aplicación de una ejecución en un servidor, establecer un canal de
comunicación que sea independiente de una aplicación de navegador
entre la ventana de ejecución de aplicación y la aplicación que se
ejecuta en el servidor, usar los parámetros recibidos, recibir las
salidas producidas por la aplicación a través del canal de
comunicación y mostrar las salidas en la ventana de ejecución de
aplicación sin la intervención de la aplicación de navegador.
Un aspecto adicional más de la presente invención
es que proporciona un producto manufacturado dotado de medios de
código legibles por ordenador para mostrar salidas, producidas por
una aplicación que se ejecuta en un servidor, en una página en HTML
insertada en la misma. Este producto comprende:
medios de lectura por ordenador para transmitir
un archivo a un cliente. El archivo representa una página e incluye
un parámetro asociado con la definición de una ventana dentro de la
página cuando una aplicación de navegador muestra la página en el
cliente;
medios de código legibles por ordenador para
recibir entradas desde la página mostrada en el cliente para
señalar la ejecución de una aplicación en una página en HTML;
medios de código legibles por ordenador para
crear un canal de comunicaciones que sea independiente de la
aplicación de navegador entre la ventana situada dentro de la página
mostrada en el cliente y el programa de aplicación que se ejecuta
en el servidor, usando el parámetro de ventana; y
medios de código legibles por ordenador para
transmitir salidas producidas por la aplicación que se ejecuta en
el servidor por medio del canal de comunicaciones al cliente para
su visualización, sin intervención de la aplicación de navegador, en
la ventana situada dentro de la página mostrada.
Otro aspecto adicional de la presente invención
es que proporciona un sistema para mostrar salidas, producidas por
un programa de aplicación que se ejecuta en un servidor, en un
archivo en HTML que comprende:
un servidor dispuesto para almacenar y ejecutar
un programa de aplicación;
un ejecutivo de red organizado para enviar
comandos a dicho servidor para iniciar la ejecución del programa de
aplicación, que está organizado para recibir, sin intervención de
una aplicación de navegador, salidas desde el programa de
aplicación que se ejecuta en dicho servidor, y que está organizado
además para transmitir, sin intervención de la aplicación de
navegador, las salidas del programa de aplicación;
un manejador de parámetros organizado para
recibir parámetros y pasar los parámetros recibidos a dicho
ejecutivo de red; y
un archivo que incluye una ventana de aplicación
y parámetros de ventana, estando organizado dicho archivo para
proporcionar los parámetros de ventana a dicho manejador de
parámetros,
en el que el ejecutivo de red está organizado
para establecer un canal de comunicación que sea independiente de la
aplicación de navegador entre el programa de aplicación que se
ejecuta en el servidor y la ventana de aplicación que utiliza los
parámetros de ventana, estando organizado el canal de comunicación
para pasar las salidas de la aplicación desde la aplicación que se
ejecuta en el servidor hasta la ventana de la aplicación sin
intervención de la aplicación de navegador.
Se describirán ahora las realizaciones
preferentes de la invención, a modo de ejemplo únicamente y con
referencia a los dibujos que se acompañan, en los cuales:
la Fig. 1 es un diagrama muy esquemático de una
realización de un sistema de comunicación que utiliza la
invención;
la Fig. 2 es un diagrama de bloques de una
realización de la invención que muestra las conexiones entre
diversos componentes del servidor de la Fig. 1 que se producen
durante la comunicación entre los clientes y el servidor;
la Fig. 3 es un diagrama de bloques de una
realización de la invención que mantiene y gestiona múltiples
conexiones de nodo cliente;
la Fig. 4 es un diagrama de bloques de una
realización del sistema para insertar aplicaciones en una página en
HTML;
la Fig. 5 es una representación esquemática de un
nodo cliente;
la Fig. 6 es un diagrama de bloques de una
realización de la invención que representa el uso de un multiplexor
para trasmitir los mismos datos desde una aplicación a más de un
cliente; y
la Fig. 7 es un diagrama de bloques de la
realización de la invención en el que las capacidades de difusión
están incrementadas gracias a un factor de salida.
Refiriéndose ahora a la Fig. 1, en una breve
descripción general, una red típica 20 incluye al menos un nodo
cliente 24, al menos un nodo servidor 34, 34', y un nodo de
información de red maestro 40 interconectado por un enlace de
comunicaciones 44. La realización mostrada en la Fig. 1 representa
el enlace de comunicaciones 44 como una red de área local en anillo
o LAN en anillo, pero puede usarse cualquier topología de
comunicación. A efectos de explicación se supone que el nodo
servidor 34 tiene la aplicación 30 requerida por el nodo cliente
24. Asimismo, a efectos de explicación, se supone que el nodo de
información maestro de la red 40 es un nodo servidor aparte, pero en
realidad el nodo de información maestro de la red 40 puede ser un
nodo servidor 34 de ejecución de la aplicación. Debe observarse que
en una LAN determinada varios nodos pueden ser capaces de actuar
como un nodo de información de la red, pero en cada momento sólo
uno de dichos nodos es designado el nodo de información maestro de
la red 40 para el sistema 20 y es a este nodo al que se dirigen las
solicitudes de información del cliente al servidor.
El nodo de información maestro de la red 40
mantiene una tabla de direcciones para los nodos de servidor dé
ejecución de la aplicación 34, 34'. Además, el nodo de información
maestro de la red 40 recibe mensajes de cada nodo servidor de
ejecución de la aplicación 34, 34' que indican su nivel de
actividad. El nivel de actividad de los nodos de servidor de
ejecución de la aplicación 34, 34' se mantienen en una tabla junto
con la dirección de cada uno de los nodos de servidor de ejecución
de la aplicación 34 y el sistema de comunicaciones 44 lo usa para
nivelación de la carga.
Cuando el cliente 24 desea ejecutar una
aplicación en un nodo servidor de ejecución de la aplicación 34, el
nodo cliente 24 envía una solicitud al puerto de comunicaciones
general previamente definido por el protocolo de comunicaciones o
al puerto de comunicaciones "conocido" en el nodo de
información maestro de la red 40. En una realización la comunicación
tiene lugar a modo de un servicio de datagrama. El nodo de
información maestro de la red 40 accede a la tabla de direcciones
del servidor y devuelve un mensaje que contiene la dirección del
servidor de ejecución de la aplicación o del servidor de
aplicaciones 34 que tiene la aplicación solicitada y que también
tiene la menor carga. Las posteriores comunicaciones son dirigidas
automáticamente por el cliente también a un puerto de comunicaciones
general "conocido" o predefinido en el nodo servidor 34. En
una realización, el tipo de protocolo con el que se efectuó la
pregunta inicial al nodo de información maestro de la red 40
determina el protocolo de la información devuelta por el nodo de
información maestro de la red 40 al nodo cliente 24. Así, si la
solicitud se hizo usando un datagrama TCP/IP, el nodo de
información maestro de la red 40 devolvería la dirección TCP/IP del
servidor 34 al nodo cliente 24 y éste posteriormente establecería
contacto con el nodo servidor 34 usando ese protocolo. En otra
realización, el datagrama por el que un cliente 24 solicita una
dirección de aplicación incluye una solicitud de un tipo de
protocolo distinto al usado para enviar la solicitud al nodo de
información maestro de red 40. Por ejemplo, el cliente 24 puede
hacer una solicitud al nodo de información maestro de la red 40
usando el protocolo IPX y solicitar la dirección del servidor de
aplicaciones como dirección de protocolo TCP/IP.
Cuando un nodo cliente 24 (de hecho un proceso
cliente 56 en un nodo cliente 24) desea establecer comunicación con
una aplicación en un nodo servidor 34, 34' el nodo cliente 24
comienza por emitir una solicitud de red para determinar la
ubicación del servidor 34 que tiene la aplicación deseada. Esta
solicitud es recibida por el nodo de información maestro de la red
(denominado también navegador de red 40) que reside en alguna parte
de la red. En esta Fig. 1, el navegador de red 40 se muestra, para
simplificar, residiendo en un servidor 40 diferente del servidor
que tiene la aplicación, pero éste puede que no sea generalmente el
caso.
El nodo de información maestro de la red 40
devuelve la dirección de red del nodo servidor 34 que tiene la
aplicación deseada 30 al nodo cliente 24. El nodo cliente 24 usa
entonces la información recibida del nodo de información maestro de
la red 40 para solicitar conexión a la aplicación que se ejecuta en
el servidor especificado 34. Tal como se ha descrito antes, dicha
conexión se establece en primer lugar con un puerto de
comunicaciones "conocido" y luego se transfiere a un puerto de
comunicaciones específico controlado por un gestor de conexión. El
puerto de comunicaciones específico está asociado con la aplicación
que se ejecuta en el nodo servidor 34 que luego se comunica con el
nodo cliente 24 a través del puerto de comunicaciones
específico.
De manera más detallada, y refiriéndose a la Fig.
2, el proceso cliente 56 en nodo cliente 24 efectúa una solicitud
54 al nodo de información maestro de la red 40 para obtener la
dirección de un nodo servidor 34 que incluya la aplicación deseada
62. El nodo de información maestro de la red 40 devuelve al nodo
cliente 24 un mensaje 58 que contiene la dirección del nodo servidor
34 que incluye la aplicación del servidor 62. En una realización,
el protocolo usado en este punto de la conexión es un servicio de
datagrama.
El nodo cliente 24 usa la dirección devuelta para
establecer un canal de comunicación 68 con el servidor 34. El
número de puerto usado por el cliente 24 corresponde al "puerto
conocido" en el servidor 34 que ha sido definido por el
protocolo de red como el puerto por el que el servidor 34 establece
conexiones de comunicación con los clientes 24. El puerto conocido
72 tiene una pila de protocolos 76 rudimentaria que incluye
fundamentalmente una estructura de datos terminales 78.
La estructura de datos terminales 78 señala la
pila de protocolos de comunicación 76 y la conexión de cliente,
estableciendo de ese modo una representación única o
"manejados" para el cliente 24. La estructura de datos
terminales 78 permite mover a voluntad la conexión entre el servidor
34 y el cliente 24 entre el gestor de conexión 80 y las diversas
aplicaciones 62 en el servidor 34. La estructura de datos
terminales 78, en una realización, no sólo contiene el manejador
para el cliente 24 sino que también puede contener otra información
relativa a la conexión de cliente. En la realización mostrada, el
servidor de aplicaciones 34 monitoriza la actividad en un sistema de
comunicaciones específico (p. ej. LAN o WAN) y ha inicializado esta
pila de protocolos mínimo 76 con sólo los módulos de protocolo
necesarios para dar soporte a un modo de comunicación "TTY".
El modo de comunicación "TTY" es una simple transmisión de
datos ASCII sin supuestos de protocolo por encima de la capa de
transporte. Es decir, no hay capas de protocolo para compresión,
encriptación, fiabilidad, tramado o presentación de los datos
transmitidos. Así pues, un nodo cliente 24 que busca una aplicación
62 que funcione en el servidor 34 establece una conexión al puerto
de comunicaciones conocido 72 con el mínimo conjunto de protocolos
necesario para dar soporte a un modo de comunicación TTY.
Un gestor de conexión 80 que se ejecuta en el
nodo servidor 34 está "escuchando" el puerto de comunicaciones
conocido 72 a la espera de una solicitud de conexión 68. Cuando se
recibe una solicitud de conexión 68 desde el nodo cliente 24, se
notifica 84 al gestor de conexión 80. El gestor de conexión 80
conoce qué protocolo se está usando basándose en la notificación
84.
Con esta información el gestor de conexión 80
crea una nueva pila de comunicaciones de protocolos mínimos 104,
inicia el entorno de ejecución 96 y liga la nueva pila de
protocolos mínimos 104 al entorno de ejecución 96. En una
realización, el servidor 34 incluye una serie de entornos de
ejecución 96 que han sido iniciados previamente, pero que no se han
asociado a un puerto de comunicaciones. En esta realización, el
inicio de conexión previa de los entornos de ejecución permite un
tiempo de respuesta más rápido que si cada entorno de ejecución 96
se iniciase al recibir del cliente 24 la solicitud de conexión.
Cuando se inicia el entorno de ejecución 96, la aplicación de
servidor 62 solicitada por el cliente 24 se inicia también. En otra
realización, si el cliente 24 no especifica una aplicación, o bien
se inicia una aplicación por defecto o simplemente el entorno de
ejecución 96 sin aplicación.
El gestor de conexión 80 mueve entonces la
conexión de cliente, incluyendo el identificador de cliente único o
manejador, desde el puerto conocido 76 hasta la nueva pila de
protocolos mínimos 104. El gestor de conexión 80, usando la pila de
protocolos mínimos envía un tren de datos TTY que indica que el
servicio está disponible. Así, este procedimiento para detectar una
conexión de cliente es independiente del puerto con el que se
establezca en primer lugar la conexión. Si el nodo cliente 24 no
responde en un intervalo de tiempo prescrito (p. ej. 5 segundos) al
mensaje de servicio disponible, el servidor 34 efectúa un reenvío
del mensaje "servicio disponible".
Si el cliente 24 recibe el mensaje, envía una
cadena TTY indicando que se ha detectado el mensaje "servicio
disponible". El cliente 24 espera que el servidor 34 responda y
si la respuesta no se produce en un intervalo de tiempo prescrito
(p. ej. 5 segundos), reenvía el mensaje. El gestor de conexión 80
solicita 90 entonces al cliente 24 los parámetros de comunicación
por defecto de éste. Esta solicitud 90 adopta la forma de un
mensaje que se vuelve a enviar al cliente 24 y que indica que el
cliente 24 debería responder con detalles relativos a qué
protocolos querría usar en la conexión.
En respuesta a ello, el cliente 24 envía un
conjunto de paquetes de protocolos 92; cada paquete de este
conjunto se usa para especificar un módulo de protocolos requerido
u opcional que el servidor 34 está requiriendo. En una realización,
el número de paquetes en el conjunto es variable, enviándose un
paquete por cada protocolo solicitado. En otra realización, el
número de paquetes que se está enviando se incluye en el
encabezamiento del primer paquete. En una tercera realización, el
número restante de paquetes que se está enviando se incluye en el
encabezamiento de cada paquete y se reduce con cada paquete
sucesivo que se envía. Así, el cliente 24 puede responder a la
solicitud 90 indicando que, por ejemplo, se usará encriptación y
compresión de datos. En tal caso, se enviará dos paquetes de
protocolos desde el cliente 24 al servidor 34 y, en una
realización, el encabezamiento del primer paquete indicará que el
número de paquetes es dos.
Cuando las respuestas a la solicitud 90 se han
recibido, el gestor de conexión 80 elabora una pila de protocolos
usando controladores de protocolos 120, 120', 120'' que
corresponden a los protocolos solicitados por el nodo cliente 24.
En una realización, el gestor de conexión 80 coloca cada uno de los
controladores de protocolos 120, 120', 120'' requeridos
correspondientes a los protocolos de cliente solicitados (p. ej. un
controlador de encriptación si el cliente desea encriptación) en el
"contenedor" de pilas de protocolos y las enlaza entre sí.
Este proceso dinámico permite que un nodo cliente 24 especifique
los contenidos de una pila de protocolos dinámicamente sin requerir
que el servidor 34 tenga una descripción previa de la pila de
protocolos para un nodo cliente 24 particular. Utilizando este
procedimiento, puede servirse a múltiples clientes 24 desde un
único servidor, aunque cada uno de los clientes 24 tenga
necesidades muy diferentes para el canal de comunicaciones
asociado. En la realización mostrada, cada cliente 24, 24', 24'' se
asocia a una pila de protocolos de comunicaciones respectiva 104,
104' y 104''. Tales pilas de protocolos extensibles dinámicamente
se describen con más detalle más adelante en la Patente de
Aplicación Estadounidense número de serie 08/540.891, presentada el
11 de octubre de 1995 y concedida como US 5.826.027.
En la realización que se acaba de exponer, el
"contenedor" 112 es un controlador de dispositivos a nivel de
usuario o a nivel de núcleo, como por ejemplo un controlador de
dispositivos NT™. Este controlador contenedor proporciona soporte
auxiliar para los módulos de protocolo internos o
"controladores" (generalmente 120) que corresponden a los
requisitos de protocolo del nodo cliente 24. Este soporte auxiliar
adopta la forma de rutinas auxiliares que, por ejemplo, ayudan a un
controlador de protocolos a transferir datos al siguiente
controlador. Otra realización posible es que cada controlador de
protocolos es en sí un controlador completo a nivel de usuario o a
nivel de núcleo.
Refiriéndose ahora a la realización representada
en la Fig. 3, el gestor de comunicaciones 60 incluye dos
principales módulos de software: ICASRV.EXE 90 e ICAAPI.DLL 94. En
la realización mostrada, ICASRV.EXE 90 es el servidor en una
interfaz cliente/servidor. ICASRV.EXE 90 gestiona todos los estados
de comunicaciones y, en una realización, se ejecuta como un
servicio de WINDOWS NT™. Una segunda parte del gestor de conexión 60
es ICAAPI.DLL 94. ICAAPI.DLL 94 establece la conexión con el
cliente, establece los protocolos que se van a usar y notifica a
ICASRV.EXE 90 la conclusión de la pila de protocolos. En una
realización, un tercer módulo CDMODEM.DLL 96 está ligado a
ICAAPI.DLL 94'. CDMODEM.DLL 96 es un módulo que ICAAPI.DLL 94'
utiliza para comunicarse con los dispositivos de módem.
La metodología de conexión descrita anteriormente
puede usarse para un cliente 24 que esté ejecutando un programa de
navegación. A efectos de esta especificación, el usuario que
ejecuta el programa de navegación se denominará el "usuario
espectador". Los términos "servidor" o "nodo servidor"
se usarán para referirse a las máquinas que alojan archivos en HTML
o aplicaciones que pueden ejecutarse. Por ejemplo, un usuario
espectador ejecuta un navegador en un nodo cliente y efectúa
solicitudes de archivos a servidores a través del protocolo HTTP.
Los servidores responden transmitiendo los datos de los archivos al
cliente a través del protocolo HTTP. El navegador ejecutado en el
cliente recibe los datos transmitidos y los muestra como una pág.
HTML al usuario espectador.
En una breve descripción general y refiriéndose a
la Fig. 4, un archivo HTML 64 situado en un servidor 34' incluye
una etiqueta de ventana genérica incorporada. La etiqueta de ventana
genérica incorporada 66 es cualquier conjunto de datos que indica a
un navegador 60 que muestra el archivo HTML 64 que debe mostrarse
una ventana genérica incorporada 66' en una ubicación concreta en
la página HTML 64' descrita por el archivo HTML. La etiqueta de
ventana genérica incorporada 66 puede incluir información adicional,
como puede ser la altura de la ventana, el ancho de la ventana, el
estilo del borde de la ventana, el color del fondo y el diseño de
la ventana, qué aplicaciones pueden mostrarse en la ventana, con
qué frecuencia deben actualizarse los datos mostrados, o cualquier
otra información adicional que sea útil para mejorar la
visualización de las salidas de la aplicación.
A continuación se muestra algunos ejemplos de
etiquetas de ventana genérica incorporada que pueden insertarse en
cualquier archivo HTML: etiqueta ActiveX™
<object
classid=''clsid:238f6f83-b8b4-11cf-8771-00a024541ee3''
data=''/ica/direct.ica''CODEBASE=''/cab/wfica.cab''
\hskip0.8cmwidth=436 height=295>
\hskip0.8cm<param name=''Start'' value=''Auto''>
\hskip0.8cm<param name=''Borden'' value=''On''>
</object>
etiqueta
Plugin™
<embed
src=http://www.citrix.com/ica/direct.ica
pluginspage=http://www.citrix.com/pluain.html
height=295 width=436 Start=Auto Borden=On>
<embed>
etiqueta
JAVA™
<applet
\hskip0.2cmcode= ''JICA.class
\hskip0.2cmwidth=436
\hskip0.2cmheight=295>
<param name=Address
value=''128.4.1.64''>
<param name=lnitialProgram
value= Microsoft Word
7.0>
<param name=Start
value=Auto>
<param name=Border
value=On>
</applet>
En cada caso referido, la etiqueta indica que una
ventana que tiene una altura de 295 píxeles y una anchura de 436
píxeles debe arrastrarse para recibir salidas de la aplicación.
Cada etiqueta especifica también que la aplicación debe iniciar su
ejecución automáticamente y que la ventana en la que se muestran
las salidas de la aplicación debe arrastrarse con un borde. Las
etiquetas ActiveX™ y Netscape Plugin™ tienen los parámetros de
aplicación remota especificados en el archivo "direct.ica"
situado en el directorio "/ica". La etiqueta JAVA™ especifica
los parámetros de aplicación remota directamente. En el ejemplo
referido anteriormente, la dirección del servidor que aloja la
aplicación está especificada así como el nombre de la aplicación
que debe ejecutarse.
La aplicación de navegador 60 accede al archivo
HTML 64 emitiendo una solicitud a una dirección de localizador
uniforme de recursos (URL) específica. El servidor 34' que aloja el
archivo HTML 64 trasmite los datos del archivo HTML 64 a la
aplicación de navegador 60, que muestra texto y traduce cualquier
etiqueta que esté incluida en el archivo HTML 64. La aplicación de
navegador 60 muestra los datos del archivo HTML 64 como una página
HTML 64'. Si una etiqueta de ventana incorporada genérica 66 está
presente en el archivo HTML 64, como alguna de las etiquetas
descritas anteriormente, el navegador 60 lanza una ventana en
blanco 66' en la página HTML 64'
mostrada.
mostrada.
La ejecución de la aplicación deseada 62' puede
comenzar en el momento inmediato de mostrar la página HTML 64' o
puede esperar a alguna señal, p. ej. una entrada especificada por
el usuario que indique que debe comenzar la ejecución de la
aplicación 62'. Una vez que ha comenzado la ejecución de la
aplicación 62', la aplicación de navegador 60 instancia un gesto de
parámetros 40 asociado con la ventana de aplicación 66'. La
instancia del manejador de parámetros 40 puede generarse como un
proceso de nodo sucesor de la aplicación de navegador 60, como un
proceso de entidad par de la aplicación de navegador 60, o como una
biblioteca enlazada dinámicamente ("DLL") asociada a la
aplicación de navegador 60.
La aplicación de navegador 60 pasa todo parámetro
específico asociado a la ventana de aplicación 66' proporcionado
por la etiqueta de ventana incorporada genérica 66 a la instancia
del manejador de parámetros 40. Además, la aplicación de navegador
60 puede pasar el manejador para la ventana de aplicación 66' a la
instancia del manejador de parámetros 40 o la instancia del
manejador de parámetros puede preguntar a la aplicación de
navegador 60 para recuperar el manejador para la ventana de
aplicación 66'. La instancia del manejador de parámetros 40 genera
también un ejecutivo de red 50. El ejecutivo de red 50 puede
generarse como un proceso de nodo sucesor de la instancia del
manejador de parámetros 40 o como un proceso de entidades pares de
la instancia del manejador de parámetros 40.
La instancia de manejadores de parámetros 40
envía cualquier parámetro de ventana de aplicación 66' especificado
al ejecutivo de red 50. Los parámetros que no están especificados
por la instancia de manejadores de parámetros 40 o la etiqueta de
ventana genérica incorporada 66 pueden establecerse en valores por
defecto. El ejecutivo de red 50 puede tener determinados parámetros
por defecto en codificación dura o bien puede acceder a un archivo
que contenga parámetros por defecto.
El ejecutivo de red 50 crea su propia ventana de
salidas de aplicación 66''. El ejecutivo de red 50 crea su ventana
de salidas de aplicación 66'' como una hija de la ventana de
aplicación 66' mostrada y muestra su ventana de salidas de
aplicación 66'' directamente sobre la ventana padre 66' sacada por
la aplicación de navegador 60. Puesto que la ventana de salidas de
aplicación 66'' sacada por el ejecutivo de red 50 es una hija de la
ventana de aplicación 66' sacada por la aplicación de navegador 60,
la ventana de salidas de aplicación 66'' hereda diversas
propiedades de su padre incluyendo información de posición. En
consecuencia, la ventana de salidas de aplicación 66'' seguirá la
ventana de aplicación 66' a medida que el usuario espectador se
desplace por la pantalla de la aplicación de navegador 60 o realice
otras acciones que varíen la posición de la ventana de aplicación
66'.
El ejecutivo de red 50 establece también un canal
de comunicaciones con el servidor 60 e invoca la ejecución de la
aplicación deseada 62' por parte del servidor 34'' usando la
metodología de conexión descrita anteriormente. El ejecutivo de red
50, que actúa como el cliente en la descripción anterior, pasa todo
parámetro recibido de la instanciación del manejador de parámetros
40 al servidor, junto con cualquier valor por defecto necesario. Si
un parámetro no se pasa al servidor, éste puede solicitar el
parámetro si se trata de un parámetro necesario que no tiene un
valor por defecto, p. ej. "identificador de usuario", o puede
proporcionar un valor por defecto para el parámetro, p. ej.
prioridad de ejecución. El servidor 34'' comienza la ejecución del
programa de aplicación deseado 62' y dirige la información de
salida al ejecutivo de red 50. El ejecutivo de red 50 recibe los
datos del programa de aplicación 62' y muestra las salidas en su
ventana de salidas de aplicación 66''. Puesto que la ventana de
salidas de aplicación 66'' se muestra en la parte superior de la
ventana de aplicación 66' sacada por la aplicación de navegador 60,
las salidas de aplicación se muestran en la página HTML 64'. Como
se ha señalado anteriormente, la ventana de salidas de aplicación
66'' sacada por el ejecutivo de red 50 es una hija de la ventana de
aplicación 66' sacada por la aplicación de navegador 60. Esto
permite
poder desplazar la ventana de salidas de aplicación 66'' a medida que uno se desplaza por la página HTML 64'.
poder desplazar la ventana de salidas de aplicación 66'' a medida que uno se desplaza por la página HTML 64'.
La ventana de salidas de aplicación 66'' recibe
también datos del usuario espectador. El ejecutivo de red 50 recibe
datos brutos, p. ej. el clic de un ratón, en la ventana de salidas
de aplicación 66''. El ejecutivo de red 50 envía las entradas
brutas a la aplicación 62' que se ejecuta en el servidor 34''. De
esta manera, el usuario espectador puede interactuar con la
aplicación 62' a través de la página HTML 64'.
Refiriéndose ahora a la Fig. 5, el usuario
espectador usa un llamado programa "navegador" para visualizar
una página HTML 64' que tiene una ventana de aplicación 66' en la
pantalla 18 del ordenador del usuario 14. El usuario espectador
puede invocar la ejecución de un programa de aplicación 62'. Esto
lo hace normalmente el usuario utilizando una interfaz de "puntero
y clic", es decir, el usuario espectador emplea un ratón 16 para
manipular un cursor 12 que se muestra también en la pantalla 18 del
ordenador del usuario espectador 14. Una vez que el cursor 12 está
sobre una parte concreta de la página HTML 64', el usuario
espectador señala "haciendo clic" en un botón 15 situado en el
ratón 16. Otra opción para el usuario espectador es señalar
presionando una tecla en un teclado asociado 17, como por ejemplo la
tecla de "retorno". En otras formas de realización, el usuario
espectador puede no usar un ratón 16 en absoluto, utilizando en su
lugar una alfombrilla táctil, una bola de guía, un tablero y lápiz
sensibles a la presión o algún otro mecanismo de introducción de
datos para manipular el cursor 12.
En otra realización, la ventana de aplicación
66', u otra parte de la página HTML 64', pueden definir una "zona
crítica". Cuando el usuario espectador mueve el cursor 12 a la
"zona crítica", se inicia la ejecución de la aplicación 62' en
el servidor 34''.
Una vez que el usuario espectador ha indicado que
la ejecución de la aplicación 62' debe comenzar, la aplicación de
navegador 60 instancia un manejador de parámetros 40 y pasa los
parámetros de instanciación asociados a la ventana de aplicaciones
66' por medio de la etiqueta de ventana incorporada genérica 66. La
instancia de manejador de parámetros 40 genera un ejecutivo de red
50 y le pasa los parámetros de la ventana de aplicación 66'. El
ejecutivo de red 50 determina qué aplicación 62' debe invocarse y en
qué servidor 34'' reside dicha aplicación. Por lo general esta
información se la pasa la instancia de manejador de parámetros 40,
que la obtiene de la aplicación de navegador 60 en forma de la
etiqueta de ventana incorporada genérica 66, pero el ejecutivo de
red 50 puede necesitar preguntar a un nodo de información de red
maestro 40 o a otros diversos servidores, a fin de determinar qué
servidores, en caso de que los haya, alojan la aplicación deseada
62'. El ejecutivo de red 50 comienza entonces la ejecución de la
aplicación y muestra las salidas del programa de aplicación en la
ventana de aplicaciones tal como se ha descrito en detalle
anteriormente.
El ejecutivo de red 50 continúa mostrando
directamente las salidas de aplicación en la ventana de salida de
las aplicaciones 66'' hasta que el usuario espectador indica que la
ejecución de la aplicación 62' debe detenerse, p. ej. cerrando la
ventana de aplicación 66', o hasta que el usuario espectador hace
clic en una etiqueta que indica que debe mostrarse otra página HTML
diferente. Cuando esto sucede, la ejecución de la aplicación 62'
puede terminarse. Es preferible, no obstante, "cachear" la
conexión. En efecto, la primera instancia de manejador de parámetros
40 no se termina inmediatamente. Sin embargo, la aplicación 62'
continúa ejecutándose con un nivel de prioridad reducida, es decir,
en modo "segundo plano", ya que los primeros manejadores de
parámetros 40 pierden el "foco".
En general, es deseable llevar a cabo el cacheo
de conexión proporcionando al código fuente del manejador de
parámetros 40 una estructura de datos globalmente accesible para
registrar instancias. Por ejemplo, el manejador de parámetros 40
puede dotarse de una estructura de datos de lista enlazada
globalmente accesible, matriz de datos, tabla de datos u otra
estructura de datos. Debido a que la estructura de datos está
globalmente disponible, cada instancia del manejador de parámetros
40 puede leer y escribir la estructura de datos. Esto permite a
cada instancia del manejador de parámetros 40 "inscribirse" en
cada una de las demás instancias escribiendo a la estructura de
datos para señalar su existencia.
Para realizaciones en las que no se almacena
ninguna otra información de conexión, puede fijarse un límite
predeterminado en el número de conexiones que pueden cachearse en
cada momento dado. En estas realizaciones si el registro de una
instancia tendría como resultado un número excesivo de conexiones
cacheadas, una de las conexiones "cacheadas" se elimina, es
decir, se notifica a la instanciación de manejadores de parámetros
40 asociada a esa conexión que debe terminar. Antes de la
terminación, el manejador de parámetros 40 notifica a su ejecutivo
de red asociado 50 que debe terminar. A su vez, el ejecutivo de red
50 cierra su sesión con el servidor que aloja el programa de
aplicación y luego termina.
En las realizaciones en las que se almacena otra
información, la información adicional puede usarse para gestionar
con más eficacia las conexiones cacheadas. Por ejemplo, si un
usuario no ha visualizado activamente una página HTML 64' en un
número de minutos predeterminado, p. ej. diez minutos, se ordena a
la instanciación del manejador de parámetros 40 que termine, la
sesión con el servidor se termina y la instancia del manejador de
parámetros 40 elimina su entrada en el registro.
La información de conexión deseada puede
gestionarse usando cualquier esquema de gestión de memoria caché
conocido. Las entradas deconexión pueden descartarse según el
principio "primero en entrar, primero en salir", es decir, la
entrada más antigua se descarta cada vez que deba añadirse una
nueva entrada. Otra opción es que pueden descartarse las entradas
de información de conexión cacheada según el principio de "uso
menos reciente", que descarta la información relativa a las
conexiones que se han usado menos por parte del usuario. Otras
técnicas de gestión de memoria caché, tales como la sustitución
aleatoria, pueden usarse también.
Si el usuario espectador vuelve a una página HTML
64' anterior que tiene una conexión cacheada, el ejecutivo de red
50 asociado a una página HTML vuelve al primer plano, es decir,
recupera el "foco", y el procesamiento de la aplicación
asociada se retorna a un nivel de prioridad normal. Si es
necesario, el ejecutivo de red 50 restablecerá la conexión con la
aplicación 62'. Aunque el ejecutivo de red 50 no almacena ningún
dato de salida para las conexiones cacheadas, tan pronto como se
restablece una conexión a una ventana de aplicaciones 66' la
conexión a la aplicación 62' se restablece y la aplicación 10
escribe de nuevo directamente a la ventana de aplicaciones 66'.
De modo similar, la metodología de conexión
descrita anteriormente puede usarse para proporcionar una ejecución
remota de una aplicación escrita en un lenguaje interpretativo.
Refiriéndose de nuevo a la Fig. 2, un nodo cliente 24 se conecta a
un nodo servidor 34 que ejecuta una aplicación 62 en nombre del
nodo cliente 24. En este ejemplo, la aplicación servidor 62 es
cualquier aplicación que permite al nodo cliente 24 solicitar una
aplicación escrita en un lenguaje interpretativo. Por ejemplo, la
aplicación 62 puede ser un navegador que permita al nodo cliente 24
descargar aplicaciones JAVA™ usando direcciones URL. Como se acaba
de describir, el nodo desde el que se descarga la aplicación y el
nodo servidor 34 son máquinas separadas interconectadas por una red
de ordenadores. No obstante, en algunas realizaciones dichas
máquinas pueden ser una sola.
A fin de evitar requerir al nodo cliente 24 que
almacene y ejecute la aplicación descargada, que puede ser
prohibitivo tanto por lo que se refiere a la memoria del cliente
como al uso del procesador, el entorno de ejecución 96 en el nodo
servidor 34 al que está asociado el nodo cliente 24 proporciona un
entorno de ejecución para la aplicación creada. El entorno de
ejecución interpreta el tren de bytes de la aplicación descargada
para producir una serie de comandos que representan la aplicación.
Si la aplicación está escrita en el lenguaje interpretativo JAVA™,
el entorno de ejecución se denomina a veces "máquina virtual
JAVA™".
En algunas realizaciones el entorno ejecutivo
incluye un compilador. Estos compiladores convierten el tren de
bytes de la aplicación en código "nativo". Por ejemplo, un
compilador puede convertir el tren de bytes de una aplicación
escrita en el lenguaje de aplicación JAVA™ en código máquina 80486.
La conversión del tren de bytes de lenguaje interpretativo en código
nativo permite a la aplicación ejecutarse más rápido que si cada
byte debiera interpretarse y ejecutarse en tiempo de ejecución.
Algunos compiladores, no obstante, pueden compilar el tren de bytes
mientras la aplicación se está ejecutando. Estos compiladores se
denominan a veces compiladores "justo a tiempo", y suelen
mirar a un número predeterminado de bytes por delante de la
instrucción que se esté ejecutando en ese momento a fin de producir
un tren constante de código compilado.
La aplicación descargada es interpretada y
ejecutada por el nodo servidor 24 y las salidas de la aplicación se
trasmiten al nodo cliente tal como se describe en relación con la
Fig. 2. El nodo servidor 34 también acepta entradas del nodo
cliente 24. Esto permite al nodo cliente 24 controlar la aplicación
descargada o proporcionar datos a la aplicación. El nodo servidor 34
puede establecer un entorno de ejecución aparte para interpretar y
ejecutar la aplicación descargada. En estas realizaciones, el
entorno de ejecución asociado a la aplicación descargada dirigiría
también sus salidas a subcapa de multiplexado 121.
Refiriéndose a la Fig. 6, debe observarse que
cualquier cliente 24, 24', 24'', o de hecho, todos los clientes
(generalmente 24) unidos a servidor 34 con la aplicación 63 pueden
ser otro servidor 34', 34''. De esta manera, los datos transmitidos
por la aplicación 63 se envían a otros servidores antes de ser
enviados a nodos cliente 24. De esta manera, los datos transmitidos
por la aplicación 63 se transmiten a un número cada vez mayor de
nodos cliente a medida que esta red se abre en abanico.
Cuando cada cliente 24 termina su conexión con el
servidor 34, cada pila de protocolos del cliente (generalmente 104)
y su pila mínima asociada (generalmente 107) se destruyen. De modo
similar, la pila de protocolos mínimos (generalmente 106) asociada
a la primera pila de protocolos del cliente 104 se destruye
también. Cuando la última de las pilas de protocolos de cliente 104
mínimas 107 y la segunda (y posterior) se han terminado, la
configuración es como era inicialmente con únicamente una primera
pila de protocolos de comunicaciones del cliente asociada al
entorno de ejecución. Obsérvese que hasta que la totalidad de la
segunda y posterior pilas de protocolos de cliente 104 no están
terminadas, la primera pila de protocolos de cliente 104 puede que
no se destruya, aunque el primer cliente 24 ya no esté
presente.
Tal como se muestra en la Fig. 2, cada entorno de
ejecución 96 se comunica con cada pila de protocolos 104 a través
de un multiplexor 121, 121', 121''. Refiriéndose ahora también a la
Fig. 6, con la presente invención es posible que más de un cliente
reciba datos que se están transmitiendo al primer cliente 24, por
ejemplo, para duplicar o monitorizar la transmisión de datos desde
un servidor 34 o para difundir datos desde una aplicación de
emisión especializada, como puede ser una aplicación de cotización
bursátil, desde la cual se emiten los mismos datos o se transmiten
básicamente de forma simultánea a una serie de clientes
(generalmente 24).
En tal caso, el primer cliente 24 hace que la
aplicación especializada 63 ejecute y transmita sus datos al
cliente 24 tal como se ha expuesto anteriormente. Cuando un segundo
cliente 24' solicita acceso a la aplicación de difusión 63, el
gestor de conexión 80 comienza a elaborar la pila de protocolos
104' para el segundo cliente 24' tal como se ha expuesto
anteriormente en relación con el primer cliente 24. No obstante,
puesto que la aplicación 63 es una aplicación de difusión, el
gestor de conexión 80 reconoce que no necesita iniciar un entorno
de ejecución adicional 96 y en vez de ello adopta los pasos
necesarios para enviar los datos desde la aplicación de difusión 63
hasta el segundo cliente 24' y cualquier cliente adicional 24''.
En primer lugar, el gestor de conexión 80 crea
una primera pila de protocolos de comunicaciones mínimos 106 que
asocia a una pila de protocolos de comunicaciones 104 del primer
cliente 24. El gestor de conexión 80 crea a continuación una
segunda pila de protocolos mínimos 107 y la asocia a la pila de
protocolos de comunicaciones 104' del segundo cliente 24'. Cuando
cada cliente adicional 24'' solicita acceso a la aplicación de
difusión 63, se crea otra pila de protocolos mínimos 106' y se
asocia a la primera pila de protocolos de cliente 104 y se crea
otra pila de protocolos mínimos 107' y pila de protocolos de
cliente 104'' por cada nuevo cliente 24''. La primera pila de
protocolos de cliente 104 y todas las pilas de protocolos mínimos
106, 106' asociadas a la primera pila de protocolos de cliente 104
y cada par de pilas de protocolos de cliente 104', 104'' y pilas de
protocolos mínimos 107, 107' asociadas a cada cliente adicional
24', 24'' están comunicadas por medio de un multiplexor 121.
Cuando el multiplexor 121 está dirigiendo datos o
recibiéndolos de sólo un cliente 24, está actuando como un simple
dispositivo de conexión. Sin embargo, cuando hay más de un cliente
24, 24', 24'' recibiendo o transmitiendo datos a una única
aplicación 63, cada multiplexor (generalmente 121) adopta dos
configuraciones adicionales. En una de ellas, el multiplexor 121'
está configurado para enviar datos de aplicación o recibir datos
tanto desde la primera pila de protocolos de cliente 104 como de
cada una de las pilas de protocolos de comunicaciones mínimos 106,
106' asociadas al mismo. En la segunda configuración el multiplexor
121'' está configurado para enviar datos recibidos por la pila de
protocolos mínimos 107, 107' a la pila de protocolos del cliente
104', 104'', respectivamente, asociada al mismo. En esta
realización, la subcapa de multiplexado 121 puede recibir datos
directamente de cada pila de protocolos de cliente 104, 104',
104''.
El gestor de conexión 80 conecta las pilas de
protocolos mínimos 106, 106' asociadas al primer cliente 24 con las
pilas de protocolos mínimos 107, 107' respectivamente, del segundo
24' y posterior clientes 24'' y ordena al multiplexor 121 que
dirija las salidas de la aplicación 63 a la pila de protocolos de
comunicaciones 104 del primer cliente 24 y sus pilas de protocolos
mínimos asociadas 106, 106'. El multiplexor 121 recibe también la
orden del gestor de conexión 80 de conectar cada segunda y
posterior pilas de protocolos mínimos de cliente 107, 107' a su
pila de protocolos de cliente asociada 104, 104', respectivamente.
Los datos transmitidos al primer cliente 24 por medio de la primera
pila de protocolos de cliente 104 se transmiten por tanto también a
las pilas de protocolos mínimos 106, 106' asociadas al primer
cliente 24 y por consiguiente al segundo 24' y posterior clientes
24'' por medio de sus pilas de protocolos asociadas 104', 104'',
respectivamente, y pilas de protocolos mínimos asociadas 107, 107',
respectivamente. En una realización, el contenedor de la pila de
protocolos incluye una estructura de datos para el seguimiento del
número y tipo de protocolos asociados a una aplicación dada 63.
Refiriéndose a la Fig. 7, tal como se ha expuesto
antes, es posible que los "clientes" de un servidor 34 sean
otros servidores 34' y 34'' (mostrándose sólo dos para
simplificar). Los segundos servidores 34' y 34'' trasmiten entonces
los datos a clientes (generalmente 24), o a servidores adicionales.
En esta realización la salida de la pila del protocolo servidor
(generalmente 104) está conectada a las pilas de protocolo 107' de
los servidores secundarios 34', 34''. Luego, como se ha descrito
antes, los datos se trasmiten entre las pilas de protocolo y a los
clientes (generalmente 24). De esta manera los datos pueden abrirse
en abanico y ser distribuidos a muchos más clientes de los que
razonablemente podría soportar un servidor.
Aunque la invención se ha mostrado
específicamente y se ha descrito con referencia a organizaciones
preferentes específicas, aquellos que son expertos en la materia
deben entender que puede efectuarse diversos cambios de forma y
detalle en la misma sin alejarse del campo de la invención definido
por las reivindicaciones adjuntas.
Claims (16)
1. Un procedimiento para mostrar salidas,
producidas por una aplicación (62,62',63) que se ejecuta en un
servidor (34,34') en una página HTML, comprendiendo el
procedimiento los siguientes pasos:
a) transmisión de un archivo (64) a un cliente
(24,24',24''), representando el archivo una primera página HTML
(64') e incluyendo un parámetro asociado a la definición de una
ventana (66') dentro de la página HTML cuando una aplicación de
navegador muestra la página HTML en el cliente;
b) recepción de entradas de la página HTML
mostrada en el cliente para señalar la ejecución de una aplicación
en un servidor;
c) creación de un canal de comunicaciones (44,68)
que sea independiente de la aplicación de navegador (60) entre la
ventana dentro de la página HTML mostrada en el cliente y el
programa de aplicación que se ejecuta en el servidor, usando el
parámetro de ventana; y
d) transmisión de salidas producidas por la
aplicación que se ejecuta en el servidor a través del canal de
comunicaciones al cliente para mostrarlas sin intervención de la
aplicación de navegador, en la ventana situada dentro de la página
HTML mostrada.
2. Un procedimiento según la reivindicación 1, en
el que el paso (b) comprende:
b-a) mostrar la página HTML en el
cliente (24), incluyendo dicha página al menos una etiqueta (66)
para señalar la ejecución de la aplicación; y
b-b) invocar la ejecución de la
aplicación en el servidor en respuesta a la selección de al menos
una etiqueta por parte de un usuario.
3. Un procedimiento según la reivindicación 1 ó
2, que comprende además el paso de acceder al archivo para
determinar el parámetro de la ventana en la que se mostrará la
aplicación en ejecución.
4. Un procedimiento según la reivindicación 1, 2
ó 3, que comprende además el paso de acceder al archivo (64) a fin
de determinar un parámetro asociado a la ejecución de la aplicación
(62).
5. Un procedimiento según cualquiera de las
reivindicaciones precedentes, en el que el paso c) comprende crear
un tubo de datos que sea independiente de la aplicación de
navegador (60) entre la aplicación en ejecución (62) y la ventana
de aplicación (66') en la página HTML.
6. Un procedimiento según cualquiera de las
reivindicaciones precedentes, que comprende además el paso de
recibir datos para la aplicación (62) que se ejecuta en el servidor
(34,34') por el canal de comunicación (44), correspondiendo los
datos recibidos a datos suministrados a la ventana situada dentro
de la página HTML mostrada por un usuario del cliente (24).
7. Un procedimiento según cualquiera de las
reivindicaciones precedentes, en el que la ventana es una primera
ventana y el paso c) comprende además los siguientes pasos:
definir una segunda ventana para recibir los
datos producidos por el programa de aplicación (62) que se ejecuta
en el servidor (34,34'); y asociar la segunda ventana a la primera
ventana de forma que los datos recibidos por la segunda ventana
aparezcan en la primera ventana dentro de la página HTML mostrada
sin intervención de la aplicación de navegador (60).
8. Un procedimiento según la reivindicación 7, en
el que el paso de asociar la segunda ventana a la primera ventana
comprende usar propiedades de ventana que definen la primera
ventana para definir la segunda ventana.
9. Un procedimiento según la reivindicación 1,
comprendiendo dicho procedimiento los siguientes pasos
adicionales:
e) determinar parámetros de una ventana dentro de
la primera página en la que se mostrarán las salidas producidas por
la aplicación en ejecución (62);
f) recibir datos del cliente (24) para señalar la
visualización de una segunda página HTML; y
g) almacenar los parámetros que se hayan
determinado asociados a la primera página HTML.
10. Un procedimiento según la reivindicación 9,
que comprende además los siguientes pasos:
h) recibir datos de un usuario para volver a
mostrar la primera página HTML;
i) recuperar los parámetros almacenados asociados
a la primera página HTML; y
j) volver a mostrar, respondiendo a los
parámetros asociados recuperados, la primera página HTML que
incluye la ventana que muestra la ejecución en aplicación (62).
11. Un aparato para mostrar salidas, producidas
por una aplicación (62) que se ejecuta en un servidor (34,34'), en
una página HTML, comprendiendo dicho aparato:
un visualizador de páginas para mostrar, en
respuesta a una aplicación de navegador (60) que se está ejecutando
en un cliente (24), una página HTML que tiene una ventana de
ejecución de aplicación definida en la misma de acuerdo con un
archivo que representa la página HTML; un manejador de parámetros
(40) organizado para recibir desde el visualizador de páginas
parámetros asociados a la ventana de ejecución de aplicación dentro
de la página HTML; y
un ejecutivo de red (50) organizado para recibir
parámetros de dicho manejador de parámetros, hacer que se inicie la
ejecución de una aplicación (62) en un servidor (34,34'),
establecer un canal de comunicación (44) que sea independiente de
la aplicación de navegador entre la ventana de ejecución de
aplicación y la aplicación que se ejecuta en el servidor, usar los
parámetros recibidos, recibir datos producidos por la aplicación a
través del canal de comunicación y mostrar las salidas en la
ventana de ejecución de aplicación dentro de la página HTML sin
intervención de la aplicación de navegador.
12. Un aparato según la reivindicación 11, en el
que el manejador de parámetros (40) está organizado para acceder a
un archivo que almacena la página HTML para determinar los
parámetros asociados a la ventana de ejecución de aplicación dentro
de la página.
13. Un aparato según la reivindicación 11 ó 12,
en el que el ejecutivo de red (50) está organizado para recibir
otro parámetro desde el manejador de parámetros (40) que es una
identificación del servidor (34,34') que aloja la aplicación
(62).
14. Un producto manufacturado dotado de medios de
código legibles por ordenador para mostrar salidas, producidos por
una aplicación (62) que se ejecuta en un servidor, en una página en
HTML insertada en la misma, comprendiendo dicho producto:
medios legibles por ordenador para trasmitir un
archivo (64) a un cliente (24), representando dicho archivo una
página HTML e incluyendo un parámetro asociado a la definición de
la ventana dentro de la página HTML cuando una aplicación de
navegador (60) muestra la página HTML en el cliente;
medios legibles por ordenador para recibir datos
desde la página HTML mostrada en el cliente para señalar la
ejecución de una aplicación en una página HTML;
medios de código legibles por ordenador para
crear un canal de comunicaciones (44) que sea independiente de la
aplicación de navegador entre la ventana situada dentro de la
página HTML mostrada en el cliente y el programa de aplicación que
se ejecuta en el servidor, usando el parámetro de ventana; y
medios de código legibles por ordenador para
transmitir datos producidos por la aplicación que se ejecuta en el
servidor a través del canal de comunicaciones al cliente para su
visualización, sin intervención de la aplicación de navegador, en
la ventana situada dentro de la página HTML mostrada.
15. Un sistema para mostrar salidas, producidas
por un programa de aplicación (62) que se ejecuta en un servidor
(34,34'), en una página HTML que comprende:
un servidor organizado para almacenar y ejecutar
un programa de aplicación;
un cliente (24) organizado para ejecutar una
aplicación de navegador (60) para mostrar una página HTML;
un ejecutivo de red (50) organizado para enviar
comandos a dicho servidor para iniciar la ejecución del programa de
aplicación, el cual está organizado para recibir, sin intervención
de la aplicación de navegador (60), salidas del programa de
aplicación que se ejecuta en dicho servidor, y que además está
organizado para transmitir, sin intervención de la aplicación de
navegador, las salidas del programa de aplicación;
un manejador de parámetros (40) organizado para
recibir parámetros y pasar los parámetros recibidos a dicho
ejecutivo de red; y
medios para crear un archivo que representa una
página HTML que incluye una ventana de aplicación y parámetros de
ventana, estando organizado el archivo para proporcionar los
parámetros de ventana a dicho manejador de parámetros,
en el que el ejecutivo de red (50) está
organizado para establecer un canal de comunicación (44) que sea
independiente de la aplicación de navegador entre el programa de
aplicación que se ejecuta en el servidor y la ventana de aplicación
que utiliza los parámetros de ventana, estando organizado el canal
de comunicación para pasar las salidas de la aplicación desde la
aplicación que se ejecuta en el servidor hasta el cliente para su
visualización en la ventana de aplicación dentro de la página HTML
sin intervención de la aplicación de navegador.
16. Un sistema según la reivindicación 15 que
comprende además una etiqueta (66) que está incorporada a dicho
archivo, que hace que la ventana de aplicación se muestre y que
pasa los parámetros de ventana a dicho manejador de parámetros
(40).
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/855,902 US5961586A (en) | 1997-05-14 | 1997-05-14 | System and method for remotely executing an interpretive language application |
| US855902 | 1997-05-14 | ||
| US855977 | 1997-05-14 | ||
| US855965 | 1997-05-14 | ||
| US08/856,051 US5941949A (en) | 1997-05-14 | 1997-05-14 | System and method for transmitting data from a server application to more than one client node |
| US08/855,977 US6370552B1 (en) | 1997-05-14 | 1997-05-14 | Apparatus and method for displaying application output in an HTML document |
| US08/855,965 US6157944A (en) | 1997-05-14 | 1997-05-14 | System and method for replicating a client/server data exchange to additional client notes connecting to the server |
| US856051 | 1997-05-14 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2252837T3 true ES2252837T3 (es) | 2006-05-16 |
Family
ID=27505922
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES98923426T Expired - Lifetime ES2252837T3 (es) | 1997-05-14 | 1998-05-14 | Sistema y procedimiento para dirigir la conexion entre un servidor y un nodo cliente. |
| ES00200775T Expired - Lifetime ES2284448T3 (es) | 1997-05-14 | 1998-05-14 | Sistema y procedimiento para transmitir datos desde una aplicacion de servidor a nodos cliente. |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00200775T Expired - Lifetime ES2284448T3 (es) | 1997-05-14 | 1998-05-14 | Sistema y procedimiento para transmitir datos desde una aplicacion de servidor a nodos cliente. |
Country Status (10)
| Country | Link |
|---|---|
| EP (3) | EP1011236A3 (es) |
| JP (3) | JP2002502521A (es) |
| KR (2) | KR100481064B1 (es) |
| AU (1) | AU744486B2 (es) |
| CA (1) | CA2290433C (es) |
| DE (2) | DE69837550T2 (es) |
| ES (2) | ES2252837T3 (es) |
| GB (1) | GB2341065B (es) |
| IL (3) | IL132875A0 (es) |
| WO (1) | WO1998052320A2 (es) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7555529B2 (en) | 1995-11-13 | 2009-06-30 | Citrix Systems, Inc. | Interacting with software applications displayed in a web page |
| US6370552B1 (en) | 1997-05-14 | 2002-04-09 | Citrix Systems, Inc. | Apparatus and method for displaying application output in an HTML document |
| US6950991B2 (en) | 1995-11-13 | 2005-09-27 | Citrix Systems, Inc. | Interacting with software applications displayed in a web page |
| US6088515A (en) | 1995-11-13 | 2000-07-11 | Citrix Systems Inc | Method and apparatus for making a hypermedium interactive |
| US6157944A (en) * | 1997-05-14 | 2000-12-05 | Citrix Systems, Inc. | System and method for replicating a client/server data exchange to additional client notes connecting to the server |
| US5941949A (en) * | 1997-05-14 | 1999-08-24 | Citrix Systems, Inc. | System and method for transmitting data from a server application to more than one client node |
| ATE320039T1 (de) * | 1999-12-15 | 2006-03-15 | Galilei Software Gmbh | Verfahren zum vermitteln von prozessdaten sowie verfahren zum erstellen von anwenderspezifischen daten und mit diesem verfahren erstellte daten |
| US6922724B1 (en) | 2000-05-08 | 2005-07-26 | Citrix Systems, Inc. | Method and apparatus for managing server load |
| US6789112B1 (en) | 2000-05-08 | 2004-09-07 | Citrix Systems, Inc. | Method and apparatus for administering a server having a subsystem in communication with an event channel |
| FR2808949B1 (fr) * | 2000-05-11 | 2002-10-25 | Sagem | Reseau comportant une plate-forme multigestionnaire |
| US6799209B1 (en) | 2000-05-25 | 2004-09-28 | Citrix Systems, Inc. | Activity monitor and resource manager in a network environment |
| US7376695B2 (en) | 2002-03-14 | 2008-05-20 | Citrix Systems, Inc. | Method and system for generating a graphical display for a remote terminal session |
| US8671213B2 (en) | 2002-03-14 | 2014-03-11 | Citrix Systems, Inc. | Methods and apparatus for generating graphical and media displays at a client |
| US8135843B2 (en) | 2002-03-22 | 2012-03-13 | Citrix Systems, Inc. | Methods and systems for providing access to an application |
| KR20030078316A (ko) * | 2002-03-29 | 2003-10-08 | 정보통신연구진흥원 | 웹 세션 관리기술을 포함한 네트워크 시스템 및 그 동작방법 |
| AU2002334254A1 (en) * | 2002-09-05 | 2004-03-29 | Nokia Corporation | Application dispatcher |
| EP1420560A1 (en) * | 2002-11-13 | 2004-05-19 | Thomson Multimedia Broadband Belgium | Software upgrade over a USB connection |
| CA2594082A1 (en) | 2005-01-06 | 2006-07-13 | Tervela, Inc. | A caching engine in a messaging system |
| EP1849093A2 (en) * | 2005-01-06 | 2007-10-31 | Tervela Inc. | Hardware-based messaging appliance |
| EP1869834A1 (en) * | 2005-04-02 | 2007-12-26 | Socket Communications, Inc. | Dynamic management of communication ports, devices, and logical connections |
| US8738703B2 (en) | 2006-10-17 | 2014-05-27 | Citrix Systems, Inc. | Systems and methods for providing online collaborative support |
| US9264483B2 (en) | 2007-07-18 | 2016-02-16 | Hammond Development International, Inc. | Method and system for enabling a communication device to remotely execute an application |
| KR100927232B1 (ko) | 2007-12-18 | 2009-11-16 | 한국전자통신연구원 | 어플리케이션 시스템의 포트 설정방법 |
| JP5773352B2 (ja) | 2008-10-28 | 2015-09-02 | 塩野義製薬株式会社 | 抗ｍｕｃ１抗体 |
| US8688799B2 (en) | 2011-06-30 | 2014-04-01 | Nokia Corporation | Methods, apparatuses and computer program products for reducing memory copy overhead by indicating a location of requested data for direct access |
| CN111045758B (zh) * | 2018-10-12 | 2025-01-21 | 北京密境和风科技有限公司 | 视图处理方法、装置、电子设备及计算机存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5204947A (en) * | 1990-10-31 | 1993-04-20 | International Business Machines Corporation | Application independent (open) hypermedia enablement services |
| US5548726A (en) * | 1993-12-17 | 1996-08-20 | Taligeni, Inc. | System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node |
| US5499343A (en) * | 1993-12-17 | 1996-03-12 | Taligent, Inc. | Object-oriented networking system with dynamically configurable communication links |
| US5857102A (en) * | 1995-03-14 | 1999-01-05 | Sun Microsystems, Inc. | System and method for determining and manipulating configuration information of servers in a distributed object environment |
-
1998
- 1998-05-14 ES ES98923426T patent/ES2252837T3/es not_active Expired - Lifetime
- 1998-05-14 DE DE69837550T patent/DE69837550T2/de not_active Expired - Lifetime
- 1998-05-14 EP EP00200776A patent/EP1011236A3/en not_active Withdrawn
- 1998-05-14 EP EP98923426A patent/EP0981884B1/en not_active Expired - Lifetime
- 1998-05-14 IL IL13287598A patent/IL132875A0/xx unknown
- 1998-05-14 KR KR10-2003-7006568A patent/KR100481064B1/ko not_active Expired - Fee Related
- 1998-05-14 JP JP54955398A patent/JP2002502521A/ja not_active Withdrawn
- 1998-05-14 EP EP00200775A patent/EP1017202B1/en not_active Expired - Lifetime
- 1998-05-14 ES ES00200775T patent/ES2284448T3/es not_active Expired - Lifetime
- 1998-05-14 WO PCT/US1998/009879 patent/WO1998052320A2/en not_active Ceased
- 1998-05-14 DE DE69832168T patent/DE69832168T2/de not_active Expired - Lifetime
- 1998-05-14 GB GB9926972A patent/GB2341065B/en not_active Expired - Lifetime
- 1998-05-14 IL IL13287398A patent/IL132873A/xx not_active IP Right Cessation
- 1998-05-14 IL IL13287498A patent/IL132874A/xx not_active IP Right Cessation
- 1998-05-14 CA CA002290433A patent/CA2290433C/en not_active Expired - Lifetime
- 1998-05-14 KR KR1019997010508A patent/KR100569469B1/ko not_active Expired - Lifetime
- 1998-05-14 AU AU75724/98A patent/AU744486B2/en not_active Expired
-
2005
- 2005-05-16 JP JP2005143236A patent/JP2005339536A/ja not_active Withdrawn
-
2006
- 2006-07-10 JP JP2006189774A patent/JP2006318499A/ja active Pending
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2252837T3 (es) | Sistema y procedimiento para dirigir la conexion entre un servidor y un nodo cliente. | |
| US6370552B1 (en) | Apparatus and method for displaying application output in an HTML document | |
| US6212564B1 (en) | Distributed application launcher for optimizing desktops based on client characteristics information | |
| Ihlenfeldt et al. | The PubChem chemical structure sketcher | |
| US5961586A (en) | System and method for remotely executing an interpretive language application | |
| US6363398B1 (en) | Database access using active server pages | |
| EP1923798B1 (en) | Clickable placeholder images for simulating web page code unsupported on mobile devices | |
| US7013351B2 (en) | Template architecture and rendering engine for web browser access to databases | |
| ES2280283T3 (es) | Objetos de control del lado del servidor para el procesamiento de elementos de la interfaz de usuario del lado del cliente. | |
| US7222152B1 (en) | Generic communications framework | |
| EP0986788B1 (en) | Web server mechanism for processing function calls for dynamic data queries in a web page | |
| JP4818253B2 (ja) | ウェブ・ページの適時更新 | |
| JPH10116236A (ja) | 遅延コード化データ伝送 | |
| US7401288B2 (en) | Method and apparatus for transmitting accessibility requirements to a server | |
| US6934734B2 (en) | Method and apparatus for managing and presenting changes to an object in a data processing system | |
| US6751647B1 (en) | Method and apparatus for automated data exchange between a user computer and a provider computer using improved object-oriented programming components | |
| US7685258B2 (en) | Disconnectible applications | |
| KR100502114B1 (ko) | 웹브라우저 화면의 실시간 갱신 방법 및 그 기록매체 | |
| AU726488B2 (en) | System and method for remotely executing an interpretive language application | |
| US20080052671A1 (en) | System, method and program product for providing content based designations for programming objects | |
| CA2495413C (en) | System and method for managing the connection between a server and a client node | |
| AU726335B2 (en) | System and method for transmitting data from a server application to more than one client node | |
| HK1025700B (en) | System and method for managing the connection between a server and a client node | |
| HK1028688A (en) | System and method for remotely executing an interpretive language application | |
| KR20020004924A (ko) | 원격 데이타 서비스와 윈도우 도큐멘트 뷰를엑티브엑스（ＡｃｔｉｖｅＸ）도큐멘트 뷰로 전환하는방법 |