ES2454548T3 - Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo - Google Patents

Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo Download PDF

Info

Publication number
ES2454548T3
ES2454548T3 ES11305280.7T ES11305280T ES2454548T3 ES 2454548 T3 ES2454548 T3 ES 2454548T3 ES 11305280 T ES11305280 T ES 11305280T ES 2454548 T3 ES2454548 T3 ES 2454548T3
Authority
ES
Spain
Prior art keywords
session
external device
conversation
request
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES11305280.7T
Other languages
English (en)
Inventor
Christophe Defayet
Simon Martin
Stéphane Monbel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amadeus SAS filed Critical Amadeus SAS
Application granted granted Critical
Publication of ES2454548T3 publication Critical patent/ES2454548T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/148—Migration or transfer of sessions

Abstract

Procedimiento de proporcionar un dispositivo externo (200, 300, 300') con una sesión en un entorno de ordenadores distribuidos, en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo externo (200, 300, 300') y servidores de aplicaciones (A1, ..., C4) de un sistema (100), el dispositivo externo (200, 300, 300') y el sistema (100) funcionando en un modo de cliente/servidor, el sistema (100) funcionando en un modo entre el modo de cliente y el modo de servidor, el dispositivo externo (200, 300, 300') funcionando en el otro modo entre el modo de cliente y el modo de servidor, en el que cada servidor de aplicaciones procesa por lo menos una aplicación de software (A, B, C, D), por lo menos algunos de los servidores de aplicaciones (A1, ..., C4) estando dispuestos para almacenar localmente en medios de almacenaje de datos por lo menos una parte de un contexto de la sesión, permitiendo de ese modo distribuir el contexto por diversos servidores de aplicaciones (A1, ..., C4); en el que por lo menos un medio de encaminamiento (10, 15) comprendido en el sistema (100) realiza una etapa de establecimiento, para una sesión determinada, de una conversación entre el dispositivo externo (200, 300, 300') y por lo menos uno de los servidores de aplicaciones (A1, ..., C4); en el que el establecimiento de la conversación comprende las siguientes etapas realizadas en el medio de encaminamiento (10, 15) con por lo menos un procesador de datos: - recepción de una solicitud desde uno entre el servidor de aplicaciones y el dispositivo externo para llegar al otro entre el servidor de aplicaciones y el dispositivo externo; - determinación de si la solicitud comprende un identificador de sesión (ID), - si la solicitud no comprende un identificador de sesión ID, entonces abertura de una sesión para dicha conversación, creando un identificador de sesión ID que unívocamente identifica dicha sesión, añadiendo el identificador de sesión ID a la solicitud, almacenando el identificador de sesión ID y encaminando la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300'), estableciendo de ese modo la conversación; - si la solicitud ya comprende un identificador de sesión ID, entonces encaminamiento de la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300') estableciendo de ese modo la conversación y permitiendo que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID a través de permitir que la conversación comparta el contexto de dicha sesión ya abierta; caracterizado porque el sistema (100) comprende una pluralidad de medios de encaminamiento (10, 11, 12, 13, 15) en el que para una sesión determinada un medio de encaminamiento entre la pluralidad de medios de encaminamiento es un medio de encaminamiento principal (10, 15) a cargo de transacciones de encaminamiento entre el dispositivo externo (200, 300, 300') y el sistema (100); la etapa de permitir que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID comprendiendo las siguientes etapas realizadas en el medio de encaminamiento que recibe la solicitud: elección de los otros medios de encaminamiento para identificar cuál de entre la pluralidad de medios de encaminamiento es el medio de encaminamiento principal para dicha sesión ya abierta y enviar entonces la solicitud al medio de encaminamiento principal.

Description

Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo
5 CAMPO TÉCNICO
La presente invención se refiere globalmente a un sistema y a un procedimiento para proporcionar un dispositivo externo con una sesión en un entorno de ordenadores distribuidos, en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo externo y el sistema que funciona en un modo de cliente/servidor. Más
10 particularmente, la invención se refiere a procedimientos y sistemas en los que posiblemente conversaciones muy heterogéneas tienen que compartir una sesión común.
ANTECEDENTES
15 Muchos sistemas existentes están configurados para proporcionar un dispositivo externo con una sesión que comprende diversas conversaciones entre aplicaciones de software del sistema y el dispositivo externo y en el que el dispositivo externo y el sistema funcionan en un modo de cliente/servidor. El documento US 2008/288644 describe uno de estos sistemas conocidos.
20 Estas soluciones existentes han resultado ser eficaces para entornos homogéneos, esto es entornos en los que las aplicaciones de software implicadas en una sesión utilizan un protocolo común.
Sin embargo, con estos sistemas existentes es particularmente difícil tener conversaciones utilizando protocolos diferentes mientras se comparte un contexto común para la sesión entera. Lo más a menudo, el contexto para una
25 sesión determinada se debe duplicar para cada protocolo utilizado por los servidores de aplicaciones implicados. Las soluciones existentes de este tipo consumen capacidades de procesamiento y de almacenaje de datos. En particular los sistemas existentes no proporcionan soluciones eficaces para migrar gradualmente desde aplicaciones que utilizan protocolos determinados a aplicaciones que utilizan otros protocolos mientras comparten el mismo contexto.
30 Adicionalmente, independientemente de los protocolos utilizados por las conversaciones, cuando el dispositivo externo funciona en un modo de servidor con respecto al sistema que funciona en un modo de cliente y cuando el sistema comprende un número de servidores de aplicaciones es particularmente complejo tener todas las conversaciones compartiendo una sesión común. En las soluciones existentes el sistema está provisto de un servidor de aplicaciones dedicado configurado para fusionar las consultas a partir del sistema dentro de la misma
35 conversación hacia el exterior con el dispositivo externo. Sin embargo, estos servidores de aplicaciones dedicadas soportan una carga importante la cual disminuye la capacidad de procesamiento de estos sistemas existentes o los hacen pobremente fiables o complejos.
Por lo tanto, un objetivo general de la presente invención es resolver o limitar por lo menos uno de los defectos 40 mencionados antes en este documento de las soluciones existentes.
Más particularmente, un objetivo de la presente invención es describir una solución en la que un dispositivo externo está provisto de una visión unificada de una sesión que comprende conversaciones heterogéneas que deben compartir un contexto común.
45 RESUMEN
Los objetivos anteriores y otros se superan y se obtienen otras ventajas, según las formas de realización de esta invención.
50 La presente invención revela un procedimiento según la reivindicación 1 de proporcionar un dispositivo externo con una sesión, en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo externo y servidores de aplicaciones de un sistema.
55 Otro aspecto de la presente invención se refiere a un medio no transitorio legible por ordenador según la reivindicación 19 que contiene instrucciones de programas de software, en el que la ejecución de las instrucciones del programa de software mediante por lo menos un procesador de datos resulta en la realización de operaciones que comprenden la ejecución del procedimiento.
60 Otro aspecto de la presente invención es un sistema según la reivindicación 20 para proporcionar un dispositivo externo con una sesión en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo externo y servidores de aplicaciones comprendidos en el sistema, el sistema estando configurado para funcionar en un modo de cliente/servidor con el dispositivo externo.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Los aspectos anteriores y otros de las formas de realización de esta invención se hacen más evidentes en la siguiente descripción detallada, cuando se lee conjuntamente con las figuras de los dibujos adjuntos, en las cuales:
La figura 1 describe un ejemplo de un sistema según una forma de realización de la invención en el que está provisto un dispositivo externo con una sesión que comprende conversaciones que utilizan diferentes protocolos.
La figura 2 describe otro ejemplo de un sistema según una forma de realización de la invención sistema en el que está provisto un dispositivo externo con una sesión que comprende conversaciones que utilizan diferentes protocolos.
La figura 3 muestra un ejemplo de un sistema según una forma de realización de la invención en el que diversos servidores de aplicaciones del sistema comparten una conversación hacia el exterior común con un dispositivo externo.
La figura 4 describe un ejemplo de un sistema según una forma de realización de la invención en el que un dispositivo externo funciona con el sistema en un modo de cliente y en el que otro servidor de aplicaciones funciona con el sistema en un modo de servidor mientras todas las conversaciones entre los dispositivos externos y el sistema comparten un contexto común.
La figura 5 muestra un ejemplo de un sistema según una forma de realización de la invención en el que un dispositivo externo hereda a partir de configuraciones de seguridad de sesiones anteriores de cara a utilizarlas para una sesión subsiguiente.
DESCRIPCIÓN DETALLADA
Algunas características y etapas ventajosas se describirán más adelante en este documento. Entonces algunas formas de realización ejemplares y casos de utilización se detallarán adicionalmente con relación a los dibujos.
La presente invención revela un procedimiento de proporcionar un dispositivo externo con una sesión en la que la sesión requiere el establecimiento de conversaciones entre el dispositivo externo y servidores de aplicaciones de un sistema. El dispositivo externo y el sistema funcionan en un modo de cliente/servidor, el sistema funcionando en un modo entre el modo de cliente y el modo de servidor, el dispositivo externo funcionando en el otro modo entre el modo de cliente y el modo de servidor.
Cada servidor de aplicaciones procesa por lo menos una aplicación de software, por lo menos algunos de los servidores de aplicaciones estando instalados para almacenar en medios de almacenaje de datos por lo menos una parte de un contexto de la sesión, permitiendo de ese modo distribuir el contexto por diversos servidores de aplicaciones vinculados a la sesión.
El sistema está provisto de por lo menos un medio de encaminamiento configurado para establecer, para una sesión determinada, una conversación entre el dispositivo externo y uno de los servidores de aplicaciones. El establecimiento de la conversación comprende las siguientes etapas realizadas en el medio de encaminamiento con por lo menos un procesador de datos:
-
recepción de una solicitud desde uno entre el servidor de aplicaciones y el dispositivo externo para llegar al otro entre el servidor de aplicaciones y el dispositivo externo;
-
determinación de si la solicitud comprende un identificador de sesión (ID),
-
si la solicitud no comprende un identificador de sesión ID, entonces abertura de una sesión para dicha conversación, creando un identificador de sesión ID que unívocamente identifica dicha sesión, añadiendo el identificador de sesión ID a la solicitud, almacenando el identificador de sesión ID y encaminando la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo, estableciendo de ese modo la conversación;
-
si la solicitud ya comprende un identificador de sesión ID, entonces encaminamiento de la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo y permitiendo que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID, estableciendo de ese modo la conversación y permitiendo que la conversación comparta el contexto de una sesión ya abierta.
De este modo la invención permite que una conversación abra e identifique unívocamente una sesión y tener entonces otra conversación que se pueda sumar a esa sesión. Estas conversaciones de este modo pueden compartir el contexto de esa sesión cualquiera que sea su protocolo. El dispositivo externo por lo tanto puede estar provisto de una visión unificada y compatible de la sesión que comprende las conversaciones sumadas.
Proporcionando al usuario una visión unificada de la sesión significa que el usuario no nota que diversas aplicaciones de software son procesadas por servidores de aplicaciones diversos e independientes. De este modo, el número de aplicaciones de software y los servidores de aplicaciones implicados en la sesión es transparente al usuario. El usuario interactúa con el sistema como si fuera un servidor de aplicaciones y una máquina únicos.
Diversas transacciones y conversaciones pueden compartir la misma sesión de entrada si el sistema funciona en un modo de servidor con el dispositivo externo, o puede compartir la misma conversación hacia el exterior si el sistema funciona en un modo de cliente con el dispositivo externo.
Adicionalmente, aunque el dispositivo externo está provisto de una visión unificada y compatible de la sesión, servidores de aplicaciones adicionales pueden ser añadidos al sistema con poco o nada de impacto en las sesiones pendientes, incrementando de ese modo la capacidad de procesamiento del sistema. Además, aunque el sistema externo esté provisto de una visión unificada y compatible de la sesión, aplicaciones de software adicionales pueden ser integradas al sistema con poco o nada de impacto en las sesiones pendientes, integrando de ese modo nuevos servicios.
De forma ventajosa, el sistema comprende una pluralidad de medios de encaminamiento. Para una sesión determinada un medio de encaminamiento entre la pluralidad de medios de encaminamiento es un medio de encaminamiento principal a cargo de las transacciones de encaminamiento entre el dispositivo externo y el sistema. De forma ventajosa, la etapa de permitir que dicha conversación se sume a una sesión ya abierta que está identificada unívocamente por dicho identificador de sesión ID comprende las siguientes etapas realizadas en el medio de encaminamiento que recibe la solicitud: elección del otro medio de encaminamiento para conocer cuál entre la pluralidad de medios de encaminamiento es el medio de encaminamiento principal para dicha sesión ya abierta y enviando entonces la transacción al medio de encaminamiento principal.
Opcionalmente, el procedimiento según la invención puede comprender cualquiera de las siguientes características y etapas adicionales pero no limitativas:
Preferiblemente, cada servidor de aplicaciones procesa una aplicación de software individual. De este modo cada servidor de aplicaciones está dedicado a una aplicación de software individual.
La conversación que se va a establecer tiene un primer identificador de sesión ID y utiliza un primer protocolo y por lo menos otra conversación tiene el mismo identificador de sesión ID y utiliza un segundo protocolo.
De este modo, según una característica particularmente ventajosa pero no limitativa de la invención, todas las conversaciones cualesquiera que sean las aplicaciones de software que soliciten pueden compartir la misma sesión, cualquiera que sea su protocolo. Por ejemplo, el dispositivo externo puede abrir una sesión con una primera transacción que solicita una primera aplicación de software y utiliza un primer protocolo de comunicación. Entonces el dispositivo externo puede solicitar, a través de la misma sesión, una segunda aplicación de software que utilice un segundo protocolo de comunicación.
Esta característica de la invención es particularmente ventajosa para conducir gradualmente una migración desde algunas aplicaciones de software a otras aplicaciones de software que utilicen otro protocolo. Por supuesto, la invención permite la integración y el procesamiento de nuevas aplicaciones de software mientras comparten el contexto de las aplicaciones de software anteriores. La migración por lo tanto puede ser conducida gradualmente lo cual es mucho más seguro que conducir en una etapa una migración para todas las aplicaciones de software.
Los sistemas existentes no proporcionan soluciones eficaces para conducir una migración gradual a partir de aplicaciones que utilicen protocolos determinados a aplicaciones que utilicen otros protocolos mientras comparten el mismo contexto.
Preferiblemente, el medio de encaminamiento es un bus de servicios de empresas.
Preferiblemente, los medios de encaminamiento son por lo menos un bus de servicios de empresas (ESB). Un bus de servicio de empresas ESB comprende una pluralidad de componentes del bus de servicios de empresas ESB a cargo del encaminamiento de las transacciones. Una solicitud que llega a un componente del bus de servicios de empresas ESB con un requerimiento para sumarse a una sesión es enviada al componente del bus de servicios de empresas ESB a cargo de esa sesión a través de la elección de todos los componentes del bus de servicios de empresas ESB con el identificador de sesión ID de esa sesión.
Según una forma de realización de la invención, el dispositivo externo funciona en un modo de cliente con respecto al sistema que funciona en un modo de servidor.
El dispositivo externo puede estar compuesto de diversos componentes heterogéneos que acceden al sistema con protocolos heterogéneos.
De este modo, para un caso de utilización de este tipo, el dispositivo externo puede proporcionar una visión unificada de la sesión, incluso aunque utilicen diversas conversaciones para acceder al servidor, como si se utilizara únicamente una conversación.
Todos los componentes del dispositivo externo que tienen el mismo identificador de sesión ID enviarán transacciones al servidor de aplicaciones como si fueran un dispositivo individual que utilizara una conversación individual.
Según otra forma de realización de la invención, el dispositivo externo funciona en un modo de servidor con respecto al sistema que funciona en un modo de cliente.
De este modo, para un caso de utilización de este tipo, el dispositivo externo puede estar provisto de una visión unificada de la sesión como si todas las conversaciones y transacciones de esa sesión y que provienen de diversos servidores de aplicaciones provinieran de un servidor de aplicaciones individual. De este modo la invención alivia la necesidad de tener una aplicación de software dedicada a la fusión de consultas a partir del sistema en una conversación hacia el exterior común con un dispositivo externo.
Todos los servidores de aplicaciones que reciben solicitudes que comparten el mismo identificador de sesión ID pueden compartir la misma conversación hacia el exterior con el dispositivo externo. Más precisamente, todas las conversaciones a partir de servidores de aplicaciones que tengan el mismo identificador de sesión ID comparten una parte común de la conversación, la cual es la parte hacia el exterior entre los medios de encaminamiento y el dispositivo externo.
Según otra forma de realización de la invención, el dispositivo externo funciona en un modo de cliente con respecto al sistema que funciona en un modo de servidor y un dispositivo externo adicional funciona en un modo de servidor con respecto al sistema que funciona en un modo de cliente.
Después de la etapa de la recepción de una solicitud en el medio de encaminamiento y antes de la etapa de la determinación de si la solicitud comprende un identificador de sesión (ID), el procedimiento comprende una etapa adicional de la determinación de que la solicitud requiere sumarse a una sesión ya abierta.
La etapa de la determinación de que la solicitud requiere sumarse a una sesión ya abierta comprende la recepción de un requerimiento de sumarse a una sesión ya abierta. El requerimiento de sumarse a una sesión ya abierta es referido como implícito. Preferiblemente, el requerimiento de sumarse a una sesión ya abierta se mantiene en una capa de sesión del protocolo de dicha solicitud. Alternativamente, la etapa de la determinación de que la solicitud requiere sumarse a una sesión ya abierta comprende las siguientes etapas: el medio de encaminamiento determina que la solicitud recibida proviene de o requiere ser encaminada a un servidor de aplicaciones que procese una aplicación de software dedicada a requerimientos de sumarse a una sesión ya abierta, el cual indica al medio de encaminamiento que la solicitud recibida debe sumarse a una sesión ya abierta. El requerimiento de sumarse a una sesión ya abierta es referido como explícito.
El requerimiento explícito de sumarse a una sesión ya abierta puede ser enviado por un dispositivo externo.
Alternativamente, el requerimiento implícito de sumarse a una sesión ya abierta puede ser enviado por el sistema. Diversos servidores de aplicaciones por lo tanto pueden compartir una conversación hacia el exterior común con el dispositivo externo.
Propiedades de la conversación
De forma ventajosa, una conversación determinada de una sesión está provista de una propiedad que controla el cierre de la sesión.
Una propiedad está configurada para cerrar la sesión en el momento del cierre de dicha conversación determinada. Esta propiedad es referida como una "propiedad que pertenece al propietario".
Otra propiedad está configurada para cerrar la sesión en el momento del cierre de dicha conversación determinada y si no está todavía abierta otra conversación para esa sesión y está configurada para mantener la sesión abierta hasta el cierre de dicha conversación determinada y si por lo menos otra conversación está todavía abierta para esa sesión. Esta propiedad es referida como una "propiedad simple compartida".
Otra propiedad está configurada para cerrar la sesión después del final de un periodo de tiempo de inactividad previamente determinado que empieza en el momento del cierre de dicha conversación determinada y si no está todavía abierta otra conversación para esa sesión. Entonces en el momento del cierre de la conversación, cualquier nueva conversación se puede sumar a la sesión, durante un periodo de tiempo previamente determinado. Esta propiedad es referida como una "propiedad de conservar la salida".
5 De forma ventajosa, en el momento del cierre de una sesión el medio de encaminamiento envía a todos los servidores de aplicaciones que comparten una conversación para esa sesión una notificación de cierre de la sesión.
Preferiblemente, un medio de encaminamiento a cargo de la sesión mantiene una referencia de todos los servidores de aplicaciones que funcionan para esa sesión. Gracias a estas referencias, el medio de encaminamiento puede
10 informar a los servidores de aplicaciones que esa sesión está cerrada.
En el momento de la recepción en un servidor de aplicaciones de la notificación de cierre de sesión, entonces dicho servidor de aplicaciones cierra la conversación o las conversaciones que maneja para esa sesión.
15 Si el servidor de aplicaciones está provisto de medios de almacenaje de datos configurados para almacenar una parte del contexto de la sesión, el procedimiento comprende una etapa adicional de borrar dicha parte del contexto de la sesión en el momento de la recepción de la notificación del cierre de la sesión. Por lo tanto la utilización de las capacidades de procesamiento y almacenaje se optimiza.
20 Según una forma de realización preferida, los servidores de aplicaciones forman grupos de servidores de aplicaciones dedicados a una aplicación de software, cada servidor de aplicaciones del mismo grupo procesando independientemente la aplicación de software a la cual está dedicado el grupo, los servidores de aplicaciones almacenando una parte del contexto de una sesión definiendo de ese modo para cada sesión un conjunto de servidores de aplicaciones que tienen cada uno una afinidad con la sesión del usuario, el procedimiento
25 comprendiendo las siguientes etapas:
-
en los medios de encaminamiento, la asignación a la sesión de un registro de correlación (DCX) dispuesto para comprender claves de afinidad, cada clave de afinidad indicando el servidor de aplicaciones que tiene una afinidad con la sesión para una aplicación de software determinada,
-
propagación del registro de correlación con la transacción, permitiendo de ese modo que los medios de encaminamiento se dirijan como objetivo a los servidores de aplicaciones que están vinculados al contexto de esa sesión.
35 Según una forma de realización no limitativa, el identificador de sesión ID está almacenado en el registro de correlación.
Todos los servidores de aplicaciones son independientes unos de los otros. No conocen la existencia o la ubicaciónde cada uno de los otros. Únicamente el registro de correlación que es leído por el medio de encaminamiento
40 permite el establecimiento de una conversación entre las aplicaciones de software.
De este modo, la clave de afinidad es una referencia añadida al registro de correlación que permite a los medios de encaminamiento dirigirse como objetivo al servidor de aplicaciones que utiliza la parte del contexto vinculada a la sesión que es relevante para procesar la transacción.
45 De forma ventajosa, el identificador de sesión ID se almacena junto con el registro de correlación o se almacena en el registro de correlación.
De este modo, el identificador de sesión ID es propagado junto con las claves de afinidad a todos los servidores de
50 aplicaciones implicados en la sesión. El identificador de sesión ID de una sesión determinada puede ser de ese modo implícitamente compartido con todos los servidores de aplicaciones que contienen el contexto de la sesión para esa sesión.
Los identificadores de sesión ID son creados por los medios de encaminamiento. El uno o más medios de
55 encaminamiento conocen cómo llegar a cada uno de los servidores de aplicaciones individuales. De este modo, el uno o más medios de encaminamiento conocen la presencia de cada servidor de aplicaciones y dónde está ubicado ese servidor de aplicaciones. El uno o más medios de encaminamiento también conocen en cuáles de los servidores de aplicaciones se procesa una aplicación de software determinada. Preferiblemente:
60 -el registro de correlación se almacena en medios de almacenaje de datos asociados a un medio de encaminamiento a cargo de la sesión;
-
el medio de encaminamiento principal es el medio de encaminamiento que recibe el requerimiento del
usuario; 65
-
las claves de afinidad son establecidas por el medio de encaminamiento.
Configuraciones de seguridad. Clonaje del contexto de seguridad
Según una forma de realización preferida, el dispositivo externo funciona en un modo de cliente y el sistema funciona en un modo de servidor. El dispositivo externo requiere abrir una nueva sesión mientras hereda las configuraciones de seguridad a partir de una sesión ya abierta.
Las configuraciones de seguridad que se heredan comprenden la duplicación de una parte del contexto de la sesión ya abierta, dicha parte del contexto conteniendo las configuraciones de seguridad de la sesión ya abierta.
El contexto de la nueva sesión es independiente del contexto de la sesión ya abierta excepto por la parte del contexto que contiene las configuraciones de seguridad. El requerimiento de abrir una nueva sesión mientras se hereda las configuraciones de seguridad a partir de una sesión ya abierta, comprende las siguientes etapas realizadas en el medio de encaminamiento:
-
recepción desde el dispositivo externo de un requerimiento de abrir una nueva sesión y de un identificador de sesión ID que identifique la sesión ya abierta,
-
gracias a dicho identificador de sesión ID, recuperación de las configuraciones de seguridad de la sesión ya abierta,
-
propagación de dichas configuraciones de seguridad con la conversación de la nueva sesión.
Por lo tanto, se pueden abrir diversas sesiones, cada una estando provista de un contexto aplicativo dedicado, mientras comparten las mismas configuraciones de seguridad. Únicamente la parte del contexto que se refiere a las configuraciones de seguridad se duplica. El resto del contexto no se duplica.
La independencia de cada sesión se mantiene de este modo mientras se alivia la necesidad de realizar una autentificación para cada sesión.
Por lo tanto un número alto de requerimientos pueden ser enviados al sistema mientras se limita la carga de los servidores de aplicaciones dedicadas a los controles de seguridad y las autentificaciones engorrosas. La invención también evita la necesidad de consultas de procesamiento por grupos de conversaciones.
Preferiblemente, las configuraciones de seguridad generadas por una conversación de una sesión ya abierta son recibidas y almacenadas en el medio de encaminamiento en asociación con el identificador de la sesión ID de esa sesión ya abierta. Entonces, una conversación de una nueva sesión puede proporcionar a los medios de encaminamiento el identificador de sesión ID de la sesión ya abierta para recuperar las configuraciones de seguridad de la última, aliviando de ese modo la necesidad de autentificación en cada nueva sesión.
Según una forma de realización preferida, todas las sesiones que comparten el mismo contexto de seguridad están vinculadas, de modo que el dispositivo externo puede cerrar todas las sesiones en un único requerimiento. De forma similar, un administrador de seguridad remoto puede requerir el cierre de todas las sesiones que compartan el mismo contexto de seguridad en un requerimiento.
El requerimiento para compartir el contexto de seguridad puede ser realizado explícitamente utilizando una solicitud de servicio dedicado. Alternativamente, puede ser realizado implícitamente, a través de un requerimiento contenido en una capa de sesión del protocolo, permitiendo de ese modo el envío de consultas paralelas sin estado al sistema mientras se utiliza la misma autentificación.
En el contexto de la invención, un dispositivo externo es un sistema tal como una unidad de procesamiento, un ordenador personal, un teléfono inteligente, una base de datos equipada con una unidad de procesamiento, almacenaje de datos, etcétera.
Según una forma de realización, el dispositivo externo funciona con el sistema en un modo de cliente con el sistema que funciona en un modo de servidor. De este modo, los dispositivos externos pueden enviar consultas al sistema. Típicamente, este tipo de dispositivo externo reúne el ordenador personal del usuario, servidores que funcionan en sitios de Internet, etcétera. Por ejemplo, un dispositivo externo de este tipo es un sitio de Internet que permite a los usuarios reservar y comprar productos y servicios de viajes y de turismo. Los productos típicos se refieren al vuelo, tren, alquiler de coches u hotel. El dispositivo externo también puede ser un sistema que forme parte de un sistema de reservas y el cual envía consultas relativas a la disponibilidad de viajes (típicamente consultas relacionadas con la disponibilidad de vuelos).
Según otra forma de realización, el dispositivo externo funciona en un modo de servidor, el sistema funcionando en un modo de cliente. Ejemplos típicos de un dispositivo externo de este tipo son unidades de procesamiento o de almacenaje de datos que proporcionan datos al sistema. Por ejemplo un dispositivo externo de este tipo es un almacenaje de datos manejado por una corporación que proporciona productos y servicios de viaje y turismo. El almacenaje de datos puede ser un inventario a cargo de la disponibilidad de vuelos y manejado por una línea aérea
o por un sistema de distribución global (GDS).
Una conversación es una comunicación entre dos componentes, los componentes siendo un dispositivo externo y un servidor de aplicaciones del sistema o siendo dos servidores de aplicaciones del sistema. Únicamente se utiliza un protocolo por conversación.
Una transacción comprende todas las conversaciones y procesamientos que se requieren para completar una consulta. Una solicitud es iniciada por cualquiera de un dispositivo externo o un servidor de aplicaciones para establecer una conversación.
Una sesión generalmente comprende una pluralidad de conversaciones y puede comprender una pluralidad de transacciones. Una sesión está asociada a un contexto. El contexto puede ser generado por los servidores de aplicaciones o puede ser provisto por un dispositivo externo.
En la presente invención, el contexto del usuario también referido como contexto es un contexto relativo a un usuario y relevante para procesar la sesión. Representa todas las informaciones funcionales y técnicas que son utilizadas por el sistema para este usuario específico para realizar las funcionalidades requeridas, por ejemplo en el sistema de reserva de viajes, el contexto de la sesión de la reserva (compra) el cual está vinculado a un final de sesión activo.
Una parte del contexto del usuario pueden ser datos provistos por el usuario tales como referencias personales del usuario, una fecha de salida, un origen o un destino. Una parte del contexto del usuario puede ser requerida por una aplicación de software vinculada al medio de almacenaje. La parte del contexto del usuario también pueden ser datos generados por la aplicación de software. Por ejemplo, la parte del contexto del usuario se puede referir a la disponibilidad de vuelos recuperada por la aplicación de software o a los precios calculados o recuperados por la aplicación de software. La parte del contexto del usuario también se puede referir al registro del nombre del pasajero (PNR) o a una parte del registro del nombre del pasajero PNR.
Como se ilustra en la figura 1, el sistema comprende medios de encaminamiento 10, 11, 12, 13 configurados para encaminar transacciones. Preferiblemente, el medio de encaminamiento es un bus de servicios de empresas. Alternativamente, el medio de encaminamiento también puede ser un encaminador o cualquier otro medio capaz de encaminar una transacción hacia un servidor de aplicaciones apropiado. En lo que sigue a continuación, el medio de encaminamiento será referido como ESB, cualquiera que sea su naturaleza: bus de servicio de empresas, encaminador, etcétera.
Para cada sesión de usuario, un ESB está a cargo de la sesión. Este ESB es referido como el ESB principal. Preferiblemente, el ESB principal es el ESB 10 que recibe el requerimiento a partir del usuario. Cuando el ESB principal comprende varios componentes del ESB, para cada sesión es preferible que un componente esté a cargo de dicha sesión. Dicho componente es referido como el componente del ESB principal.
Preferiblemente, el sistema comprende una pluralidad de máquinas. Cada máquina es un dispositivo de equipo que comprende por lo menos un medio de procesamiento que funciona por lo menos en un servidor de aplicaciones. Por lo menos algunas de las máquinas también comprenden medios de almacenaje de datos. Por lo menos un servidor de aplicaciones funciona en una máquina. El servidor de aplicaciones A1, A2, … C4,… utiliza el medio de procesamiento. Por lo menos algunos de los servidores de aplicaciones también utilizan los medios de almacenaje de datos. De este modo un servidor de aplicaciones está vinculado a medios de procesamiento y eventualmente a medios de almacenaje de datos.
Según una forma de realización particular, una pluralidad de servidores de aplicaciones funcionan en una máquina individual. Cada servidor de aplicaciones puede utilizar sus propios medios de procesamiento y eventualmente sus propios medios de almacenaje de datos. Alternativamente, una pluralidad de servidores de aplicaciones pueden compartir el mismo procesador y eventualmente los mismos medios de almacenaje de datos.
Según otra forma de realización, únicamente un servidor de aplicaciones funciona para una máquina determinada. De este modo, según esta otra forma de realización, el encaminamiento de una transacción a una máquina también significará el encaminamiento de una transacción a un servidor de aplicaciones en la descripción que sigue a continuación.
Cada servidor de aplicaciones procesa una aplicación de software.
De forma ventajosa, la misma aplicación de software es procesada independientemente por una pluralidad de servidores de aplicaciones, estos servidores de aplicaciones funcionando en la misma máquina o en máquinas diferentes.
El sistema también puede ser referido como una plataforma.
Los servidores de aplicaciones están organizados en grupos 20, 30, 40. Los servidores de aplicaciones también son referidos como máquinas.
Cada servidor de aplicaciones del mismo grupo de servidores de aplicaciones procesa la misma aplicación de software.
Entonces una aplicación de software determinada puede ser procesada en paralelo en un número de servidores de aplicaciones. Por ejemplo, cada servidor de aplicaciones A1, A2, … A8 del grupo 20 procesa la aplicación de software A. Cada servidor de aplicaciones B1, B2, … B8 del grupo 30 procesa la aplicación de software B. Cada servidor de aplicaciones C1, C2, C3, C4 del grupo 40 procesa la aplicación de software C.
Para una sesión determinada existe únicamente un servidor de aplicaciones que funciona por aplicación de software. De este modo, entre un grupo de servidores de aplicaciones que procesan la misma aplicación de software, un servidor de aplicaciones está dedicado a esa sesión determinada.
Cada servidor de aplicaciones que necesita almacenar datos está provisto de medios de almacenaje de datos. El servidor de aplicaciones dedicado a una sesión determinada utiliza los medios de almacenaje de datos de la máquina en la cual funciona. Este servidor de aplicaciones dedicado a una sesión determinada de este modo puede almacenar en estos medios de almacenaje la parte del contexto del usuario que es relevante para la aplicación de software procesada por este servidor de aplicaciones.
De este modo, el contexto de usuario es distribuido sobre un posible número muy grande de servidores de aplicaciones, cada parte del contexto del usuario siendo almacenada localmente. Como se describe en la figura 1, el contexto del usuario Ua comprende las partes a0, a1, a2, a3 y está distribuido a través de los servidores de aplicaciones A3, B8, C4. a0 está almacenada en el almacenaje de datos del ESB principal. A0 contiene el identificador de sesión ID que hace referencia a la sesión del usuario y todos los datos relativos a las conversaciones abiertas con el usuario y los servidores de aplicaciones. Eventualmente, a0 también comprende un registro de correlación. El registro de correlación (DCX) será detallado adicionalmente más adelante en este documento.
Por lo tanto, todos los servidores de aplicaciones que están dedicados a una sesión determinada del usuario forman un conjunto de servidores de aplicaciones provistos cada uno de ellos de una afinidad con esa sesión.
Una solución que permite conversaciones heterogéneas para compartir una sesión común será descrita en detalle ahora.
El dispositivo externo 200 envía una solicitud al sistema 100. El ESB 10 recibe la solicitud (etapa 101). No ha sido abierta por el dispositivo externo 200 una conversación anterior para esa sesión. Esta solicitud 101 no comprende ningún identificador de sesión (ID). Entonces el ESB 10 crea un identificador de sesión ID y almacena el identificador de sesión ID. El ESB 10 también encamina la solicitud a un servidor de aplicaciones que procesa la aplicación de software solicitada por el dispositivo externo 200 (etapa 102). Los ESB están configurados para conocer qué grupo de servidores de aplicaciones procesa la aplicación de software requerida por el dispositivo externo 200.
De este modo se establece una conversación entre el dispositivo externo 200 y el servidor de aplicaciones A3 que está dedicado a procesar la aplicación de software. El servidor de aplicaciones A3 procesa la transacción. Una parte a1 del contexto es creada y almacenada en los medios de almacenaje de datos asociados a A3. A3 solicita otra aplicación de software (aplicación de software B). Una solicitud de este tipo es también referida como una solicitud colateral. El ESB 11 está a cargo de encaminar las solicitudes que provienen del grupo de servidores de aplicaciones que están dedicados a procesar la aplicación de software B.
El ESB 11 selecciona, por ejemplo a través de reglas de equilibrio de la carga, el servidor de aplicaciones B8 entre el grupo 30 de servidores de aplicaciones que están dedicados a procesar la aplicación de software B y encamina la transacción hacia B8 generando de ese modo una conversación entre los servidores de aplicaciones A3 y B8 (etapa 103). Una conversación de este tipo es también referida como una conversación colateral. B8 procesa la transacción y crea una parte del contexto para esa sesión. Esta parte a2 del contexto es almacenada en medios de almacenaje de datos provistos con el servidor de aplicaciones B8.
Después del procesamiento, el servidor de aplicaciones B8 solicita la aplicación de software C. El ESB 13 a cargo del encaminamiento de las solicitudes a partir del grupo 30 de servidores de aplicaciones que están dedicados a
procesar la aplicación de software B selecciona el servidor de aplicaciones C4. La transacción es encaminada hacia el servidor de aplicaciones C4 (etapa 104). El servidor de aplicaciones C4 procesa la transacción y crea una parte a3 del contexto para esa sesión.
De este modo la transacción comprende las etapas 101, 102, 103, 104.
Por lo tanto, la sesión que comprende todas las conversaciones mencionadas tiene un contexto que comprende las partes a0, a1, a2, a3. Dicho contexto está distribuido por una pluralidad de servidores de aplicaciones.
El dispositivo externo 200 abre otra conversación (etapa 105). Previamente, el dispositivo externo 200 ha recuperado el identificador de sesión ID creado por el ESB 10.
El dispositivo externo también requiere que esta otra conversación se sume a la sesión abierta con la conversación previa.
Un requerimiento de este tipo de unir la sesión ya abierta puede ser explícito o implícito.
Un requerimiento explícito significa que el dispositivo externo 200 solicita una aplicación de software dedicada a requerimientos para sumarse a la sesión. El ESB 10 identifica la aplicación de software que es solicitada por el dispositivo externo 200 y determina que la nueva conversación de ESB 10 debe compartir la sesión ya abierta.
Un requerimiento implícito significa que la solicitud desde el ESB 10 comprende una cabecera que comprende un requerimiento de sumarse a la sesión. Más precisamente, la capa de la sesión del protocolo de esta nueva conversación contiene un requerimiento para sumarse a la sesión.
Cuando el ESB 10 determina que se espera la nueva conversación se sume a una sesión ya abierta, entonces se verifica el identificador de sesión ID de esa nueva conversación.
Si el ESB 10 contiene un indicador de sesión ID idéntico, entonces esto significa que este ESB 10 es el ESB que gestiona la sesión ya abierta. Entonces, el ESB 10 permite que la solicitud desde el dispositivo externo 200 llegue al servidor de aplicaciones requerido y se sume a la sesión ya abierta.
Si el ESB 10 no contiene un identificador de sesión ID idéntico, entonces elige el otro ESB o bien otros componentes del ESB a fin de identificar cuál de los ESB o de los componentes del ESB está a cargo de la sesión ya abierta que tiene un identificador de sesión ID idéntico. Un ESB de este tipo (o componente del ESB) a cargo de una sesión es referido como el ESB principal (respectivamente componente principal del ESB) para esa sesión.
Cuando el ESB es identificado, el ESB que recibió la solicitud desde el dispositivo externo 200 envía el requerimiento de sumarse a la sesión al ESB principal. En el caso de utilización ilustrado en la figura 1, el ESB principal es también el ESB que recibe la segunda transacción desde el dispositivo externo 200.
Una vez el ESB principal ha recibido el requerimiento de sumarse a la sesión, entonces la nueva conversación comparte la sesión ya abierta y por lo tanto puede compartir el contexto de la sesión ya abierta.
Un caso de utilización particularmente ventajoso de la invención se refiere a una sesión en la que diversas conversaciones utilizan protocolos diferentes. Gracias a la invención, cada conversación cualquiera que sea su protocolo puede compartir el contexto de las otras conversaciones.
Por ejemplo, la transacción 2 que comprende conversaciones ilustradas por las etapas 105, 106 puede compartir el contexto de la transacción 1 que comprende las conversaciones ilustradas por las etapas 101, 102, 103 y 104.
Con referencia a la figura 1, el dispositivo externo 200 requiere abrir una nueva conversación con otro protocolo mientras comparte el contexto de las conversaciones anteriores.
Como se ha mencionado antes en este documento estas características de la invención son particularmente ventajosas para migrar servicios que utilizan un protocolo a otros servicios que utilizan otro protocolo.
La invención no está limitada por el número de conversaciones que se suman a una sesión. Adicionalmente, la invención no está limitada por el número de protocolos diferentes utilizados por las diversas conversaciones que se suman a una sesión.
La figura 2 describe otro caso de utilización en el que la invención resulta ser particularmente ventajosa. En esta forma de realización, los ESB están incluidos en el integrador de servicios (SI). El integrador de servicios SI comprende una pluralidad de multiplexores MUX 1, MUX 2, MUX 3 que están configurados para recibir solicitudes desde dispositivos externos tales como el dispositivo externo 200 y desde diversos servidores de aplicaciones del
sistema 100. El integrador de servicios SI también comprende servidores tales como SRV1 y SRV2 que tienen cada uno una función de medios de encaminamiento.
En esta forma de realización, los servidores de aplicaciones están referidos como motores abiertos (open back ends
-
OBE). Los OBE se reúnen en grupos 20, 30, 40 de OBE. El grupo 20 reúne el OBE A1, OBE A2, OBE A3 que cada uno procesa una aplicación de software A. El grupo 30 comprende el OBE B1 y B2 que cada uno procesa la aplicación de software B. El grupo 40 comprende el OBE C1 que procesa la aplicación de software C.
El dispositivo externo 200 envía una solicitud al integrador de servicios SI que llega al MUX 1 (etapa 201). Esta solicitud utiliza un protocolo referido como el protocolo 1. El MUX 1 encamina la solicitud al servidor SRV2 (etapa 202). Puesto que no está comprendido un identificador de sesión ID en esta solicitud, el servidor SRV2 abre una sesión y crea un identificador de sesión ID. El identificador de sesión ID se almacena en el servidor SRV2. El servidor SRV2 determina que se solicita la aplicación de software A y selecciona el servidor de aplicación OBE A1 entre el grupo 20. El servidor SRV2 crea un registro de correlación (DCX) que indica que el servidor de aplicación OBE A1 es el servidor de aplicación que está vinculado a esa sesión entre los servidores de aplicaciones dedicados a procesar la aplicación de software A. Una indicación de este tipo es referida como una clave de afinidad. Entonces, la clave de afinidad del registro de correlación DCX indica que el OBE A1 tiene una afinidad con esa sesión.
Una descripción general y formas de realización ejemplares del registro de correlación, sus funcionalidades y sus ventajas están disponibles en una solicitud de patente co-pendiente presentada a nombre del solicitante de la presente solicitud de patente, que tiene la misma fecha de prioridad que la presente solicitud de patente y titulada: "Procedimiento y sistema para proporcionar una sesión que implica una pluralidad de aplicaciones de software".
El servidor SRV2 encamina la solicitud al OBE A1 (etapa 203) estableciendo de ese modo una conversación entre el dispositivo externo 200 y el OBE A1 a través del integrador de servicios SI. El OBE A1 procesa la solicitud. Eventualmente almacena una parte del contexto de la sesión en los medios de almacenaje que utiliza.
Preferiblemente, el OBE A1 crea una referencia, referida como la clave de contexto aplicativo, la cual indica cómo recuperar la parte del contexto que tiene almacenada. La clave de contexto aplicativo se almacena en el registro de correlación DCX. Por lo tanto, la próxima vez que el OBE A1 reciba una solicitud para esa sesión, será capaz de recuperar fácilmente la parte del contexto que mantienen para esa sesión.
El registro de correlación DCX enriquecido con la clave de contexto aplicativo es devuelta al servidor SRV2 (etapa 204). El servidor SRV2 almacena el registro de correlación DCX como enriquecido por el OBE A1.
Los resultados del procesamiento junto con el registro de correlación DCX son enviados al dispositivo externo 200 a través del multiplexor MUX 1 (etapas 205, 206). El identificador de sesión ID es también enviado al dispositivo externo 200.
Según una forma de realización específica y no limitativa, el identificador de sesión ID puede ser almacenado en el registro de correlación DCX. De este modo, como el registro de correlación DCX es propagado a cada solicitud y cada solicitud colateral de cada conversación, el identificador de sesión ID también será propagado y en cascada. Cuando el dispositivo externo 200 está provisto de resultados del procesamiento o únicamente del registro de correlación DCX, esta primera conversación termina.
Entonces, el dispositivo externo 200 abre otra conversación utilizando un protocolo 2 (etapa 207).
Esta solicitud contiene el identificador de sesión ID recuperado a partir de la primera conversación y llega al multiplexor MUX 2. El multiplexor MUX 2 está dedicado a las solicitudes que utilizan el protocolo 2.
Esta solicitud contiene un requerimiento de sumarse a una conversación ya abierta. El multiplexor MUX 2 elige todos los medios de encaminamiento (servidores SRV1 y SRV2) con el identificador de sesión ID enviado por el dispositivo externo 200. El servidor SRV2 identifica que ya mantiene un identificador ID de sesión idéntico. El multiplexor MUX 2 envía entonces al servidor SVR2 el requerimiento de sumarse a una sesión (etapa 208).
Entonces el servidor SVR2 permite que esta nueva solicitud comparta la sesión ya abierta. El contexto de la sesión está por lo tanto disponible para la nueva conversación. El servidor SVR2 determina que un servidor de aplicaciones dedicado a la aplicación de software B es solicitado y selecciona uno de estos servidores de aplicaciones ya que todavía no se establece el requerimiento de afinidad para esa aplicación de software. Se selecciona el OBE B2. Se establece una afinidad para ese grupo 30 y el registro de correlación DCX se enriquece con una clave de afinidad que apunta hacia el OBE B2.
El requerimiento de afinidad es parte de la configuración del ESB. Sobre la base de parámetros de transacción, tales como la fuente, el destino y la aplicación de software de la transacción que llega a un ESB, ese ESB, gracias a su configuración es capaz de determinar si la transacción debe ser procesada teniendo en cuenta una afinidad. De este
modo, información estática (la configuración del ESB) se tiene en cuenta a fin de determinar si se requiere una afinidad mientras. El contexto del registro de correlación DCX es información dinámica.
La transacción es entonces encaminada hacia el OBE B2 (etapa 209). El OBE B2 procesa la transacción. Almacena una parte del contexto en los medios de almacenaje de la máquina en la cual funciona y enriquece por consiguiente el registro de correlación DCX con una clave de contexto aplicativo. El registro de correlación DCX es devuelto al servidor SVR2 (etapa 210) en donde es almacenado. Los resultados del procesamiento junto con el registro de correlación DCX enriquecido son encaminados al dispositivo externo 200 (etapa 211).
En la etapa 212, el dispositivo externo 200 requiere abrir otra conversación utilizando otro protocolo (protocolo P3). El multiplexor MUX 3 está a cargo de la gestión de las solicitudes que utilizan el protocolo 3. El identificador de sesión ID de la sesión está incluido en la solicitud y permite al MUX 3 enviar el requerimiento para sumarse a la sesión al servidor SVR2 manteniendo el mismo identificador de sesión ID y gestionando esa sesión (etapa 213).
El servidor SVR2 abre entonces la sesión a esta nueva conversación. La conversación que utiliza el protocolo 3 puede de este modo compartir el contexto creado por las conversaciones que utilizan el protocolo 1 y el protocolo 2.
De este modo, el servidor SVR2 identifica que se solicita la aplicación de software B. Gracias al registro de correlación DCX, el servidor SVR2 determina que se requiere una afinidad para esa aplicación de software y fija como objetivo el servidor de aplicaciones OBE B2. La transacción es entonces encaminada con el registro de correlación DCX hacia el OBE B2 y se abre una conversación entre el dispositivo externo 200 y el OBE B2 (etapa 214). La clave de contexto aplicativo del registro de correlación DCX permite que el OBE B2 recupere la parte del contexto que está contenida. El OBE B2 procesa la transacción. Eventualmente, el OBE B2 actualiza la clave de contexto aplicativo y envía de vuelta la transacción junto con el registro de correlación DCX al servidor SVR2 (etapa 215). El servidor SVR2 almacena el registro de correlación DCX como enriquecido.
Los resultados del procesamiento realizados por el OBE B2 junto con el registro de correlación DCX son enviados al dispositivo externo 200.
Esta forma de realización ejemplar claramente ilustra que la invención permite conversaciones que utilizan diferentes protocolos compartan el mismo contexto a través de compartir la misma sesión.
Esto resulta ser particularmente ventajoso para migrar desde un protocolo a otro mientras se comparte el mismo contexto. De este modo, la migración puede ser conducida gradualmente, por ejemplo servicio por servicio.
Este caso de utilización también ilustra las ventajas de propagar el registro de correlación junto con el identificador de sesión ID mientras se limita el tráfico y los encaminamientos.
La figura 3 ilustra otras ventajas de la invención. En este caso de utilización, el dispositivo externo 300 funciona en un modo de servidor con respecto al sistema 100 que funciona en un modo de cliente. Por ejemplo, el dispositivo externo es un sistema mantenido por un proveedor de datos mientras el sistema comprende servidores de aplicaciones que necesitan recuperar y procesar estos datos.
Aunque el sistema comprende una pluralidad de servidores de aplicaciones, interactúa con el dispositivo externo como si comprendiera un servidor de aplicaciones individual. El ESB 15 recibe una solicitud desde un servidor de aplicaciones A2 del grupo 20 de servidores de aplicaciones que están dedicados a procesar la aplicación de software A (etapa 301). Esta solicitud está pensada para que llegue al dispositivo externo 300. Puesto que esta solicitud no comprende un identificador de sesión ID, el ESB 15 abre una sesión y crea un identificador de sesión ID. Este identificador de sesión ID únicamente identifica la sesión a. El ESB 15 almacena dicho identificador de sesión ID y encamina la solicitud al dispositivo externo 300 (etapa 302). Una conversación se abre de ese modo entre el servidor de aplicaciones A2 y el dispositivo externo 300. Las respuestas desde el dispositivo externo 300 son recibidas en el ESB 15 el cual encamina dichas respuestas hacia el servidor de aplicaciones A2 que ha solicitado el dispositivo externo 300. El identificador de sesión ID es enviado también a este servidor de aplicaciones.
Entonces, otra solicitud llega al ESB 15 (etapa 303). Esta solicitud proviene del servidor de aplicaciones B3. La solicitud contiene un requerimiento de sumarse a una sesión ya abierta y contiene el identificador de sesión ID previamente creado por el ESB 15. Dicho identificador de sesión ID ha sido propagado desde el servidor de aplicaciones A2 a eventualmente otros servidores de aplicaciones o a otro dispositivo externo que funciona en un modo de cliente con el sistema, antes de llegar al servidor de aplicaciones B3.
El ESB 15 abre la sesión previamente abierta de modo que la solicitud desde B3 puede compartir la misma conversación con el dispositivo externo 300.
De forma similar, una solicitud desde el servidor de aplicaciones C2 abre una conversación que comparte la sesión previamente abierta. A2, B3 y C2 comparten entonces con el dispositivo externo 300 la misma conversación hacia el
exterior gracias al identificador de sesión ID. Preferiblemente, el identificador de sesión ID está almacenado en un registro de correlación DCX propagado a todos los servidores de aplicaciones que tienen una afinidad con el contexto de la sesión a. Preferiblemente, el registro de correlación DCX se almacena en el ESB a cargo de la gestión de dicha sesión del usuario.
De forma similar, se abre otra sesión (sesión b). A5, B5, C4 comparten la misma conversación hacia el exterior gracias a otro identificador de sesión ID que unívocamente identifica la sesión b. A5, B5 y C4 respectivamente contienen las partes b1, b2 y b3 del contexto de la sesión del usuario b.
De forma similar, se abre una sesión del usuario c. A4, B7, C3 comparten la misma conversación hacia el exterior hacia el dispositivo externo 300’ gracias a otro identificador de sesión ID, que unívocamente identifica la sesión c. A4, B7, C3 respectivamente almacenan las partes c1, c2, c3 del contexto de la sesión del usuario c. Por lo tanto, el dispositivo externo 300’ interactúa con muchos servidores de aplicaciones como si estos servidores de aplicaciones fueran un servidor de aplicaciones individual.
El requerimiento de compartir una sesión puede ser explícito o implícito. Como se ha detallado anteriormente, una solicitud que llega a un componente del ESB con un requerimiento de sumarse a una sesión es enviada al componente del ESB a cargo de esa sesión a través de la elección de todos los componentes del ESB con el identificador de sesión ID de esa sesión.
El caso de utilización descrito en la figura 3 claramente ilustra que el sistema puede compartir una conversación hacia el exterior común con un dispositivo externo cualesquiera que sean los creadores de las solicitudes desde el sistema 100. Por lo tanto el dispositivo externo interactúa con el sistema 100 como si todos los servidores de aplicaciones fueran un servidor de aplicaciones individual.
El contexto de la sesión por lo tanto puede ser distribuido sin que impacte en los diversos dispositivos externos. Esto es muy ventajoso cuando el sistema es gestionado por una corporación que es diferente de la que gestiona el dispositivo externo.
Adicionalmente, la invención permite añadir un grupo 60 de servidores de aplicaciones a un grupo 20 de servidores de aplicaciones sin impacto en el dispositivo externo. La capacidad de procesamiento por lo tanto se puede incrementar fácilmente. Además, la adición de un grupo 50 de servidores de aplicaciones D1, D2, D3, D4 dedicados a un nuevo servicio D es totalmente transparente al dispositivo externo. Los servidores de aplicaciones del grupo 50 pueden funcionar en la misma máquina o cada uno puede funcionar en una máquina dedicada. De este modo la invención alivia la necesidad de cambiar la configuración del sistema inicial. Servicios mejorados por lo tanto se pueden ofrecer a los usuarios (no ilustrado en la figura 3).
De forma ventajosa, cuando se suma a una sesión, una conversación tiene una propiedad que define hasta qué punto controla el cierre de la sesión. Las tres propiedades indicadas más adelante en este documento permiten gestionar eficazmente la sesión, permitiendo por ejemplo optimizar la utilización de la capacidad de almacenaje para esa sesión.
Cuando se establece la conversación con una primera propiedad, la sesión se cierra en el momento del cierre de la conversación. Esta propiedad es referida como una "propiedad del propietario".
Cuando la conversación se establece con una segunda propiedad, la sesión se cierra en el momento del cierre de la conversación y con tal de que no esté todavía abierta otra conversación para esa sesión. Si por lo menos otra conversación está todavía abierta para esa sesión e incluso si la conversación establecida con la segunda propiedad se cierra, la sesión permanece abierta. Esta propiedad es referida como una "propiedad de compartir simple".
Cuando la conversación se establece con una tercera propiedad, la conversación cierra la sesión después del final de un período de tiempo previamente determinado que empieza en el momento del cierre de la conversación. Entonces en el momento del cierre de la conversación, cualquier otra conversación o cualquier otra nueva conversación se puede sumar a la sesión durante un periodo de tiempo previamente determinado. Esta propiedad es referida como una "propiedad de conservar la salida".
Preferiblemente, en el momento del cierre de una sesión los medios de encaminamiento envían a todos los servidores de aplicaciones que comparten una conversación con esa sesión una notificación de cierre de sesión. Entonces todos los servidores de aplicaciones cierran su conversación abierta para esa sesión.
Preferiblemente, un medio de encaminamiento a cargo de la sesión mantiene una referencia de todos los servidores de aplicaciones que funcionan para esa sesión. Gracias a estas referencias, los medios de encaminamiento pueden informar a los servidores de aplicaciones de que la sesión está cerrada.
La figura 4 describe otro caso de utilización ejemplar de la invención en el que el sistema interactúa con un dispositivo externo 200 que funciona en un modo de cliente con el sistema 100, mientras un dispositivo externo 300 funciona en un modo de servidor con el sistema 100. Un número posiblemente alto de dispositivos externos 200 y un número posiblemente alto de dispositivos externos 300 pueden interactuar con el sistema. Este caso de utilización combina las características y ventajas de los casos de utilización anteriormente descritos de las figuras 1, 2 y 3.
En particular, el dispositivo externo 200 puede abrir una transacción con estado con el dispositivo externo 300 a través de algunos servidores de aplicaciones del sistema 100 (servidor de aplicaciones A3 como se ilustra en la figura 4). La transacción comprende las conversaciones 401, 402, 403.
El dispositivo externo 200 puede abrir una transacción subsiguiente compartiendo el contexto de las transacciones anteriores. La transacción subsiguiente comprende las conversaciones 404, 405, 406, 407.
Las conversaciones 404, 405 son procesadas en servidores de aplicaciones diferentes a los de las conversaciones 401 a 402 de la transacción anterior.
Sin embargo, las transacciones anterior y subsiguiente comparten la misma conversación con estado (403, 407).
De este modo, el dispositivo externo 300 interactúa con todos los servidores de aplicaciones como si fueran un servidor de aplicaciones individual. Las transacciones anteriores y subsiguientes posiblemente pueden utilizar diferentes protocolos. El identificador de sesión ID propagado con cada transacción permite compartir el contexto de la sesión que comprende ambas transacciones.
Otras características ventajosas de la invención se detallarán ahora con referencia a la figura 5. Una conversación puede requerir la creación de una nueva sesión y un nuevo contexto para esa sesión mientras hereda las configuraciones de seguridad a partir de la sesión ya abierta.
La nueva sesión, también referida como la sesión subsiguiente o la sesión clonada, tiene su propio contexto excepto por lo que respecta a las configuraciones de seguridad y por lo tanto puede ser considerada como una sesión que está clonada a partir de la sesión ya abierta.
Esto permite que un dispositivo externo abra varias sesiones clonadas y entonces tenga diversos contextos aplicativos mientras realiza una autentificación para el sistema. De este modo, únicamente una parte del contexto de la sesión ya abierta se duplica para las sesiones clonadas. Esta parte del contexto se refiere a las configuraciones de seguridad.
Preferiblemente, todas las sesiones clonadas están vinculadas a la sesión abierta anteriormente. De este modo, todas las sesiones clonadas pueden ser cerradas con un requerimiento individual. Todas las sesiones clonadas pueden ser cerradas en el momento del cierre de la sesión anterior. Alternativamente, todas las sesiones clonadas pueden ser cerradas a requerimiento de un administrador de seguridad.
Al igual que para sumarse a una sesión, un requerimiento de abrir una sesión clonada puede ser realizado explícitamente a través de la solicitud de una aplicación de software dedicada o implícitamente con una cabecera dedicada embebida en la solicitud.
Utilizando sesiones clonadas implícitas, un dispositivo externo que funciona en un modo de cliente con respecto al sistema que funciona en un modo de servidor puede enviar consultas sin estado paralelas al sistema mientras realiza una autentificación individual.
Con los sistemas existentes, las consultas paralelas que requieren cada una tener un contexto dedicado necesitan cada una realizar una autentificación. Los servidores de aplicaciones dedicados a la autentificación son por lo tanto solicitados masivamente lo cual conduce a una baja fiabilidad o requiere equipos costosos. Otras soluciones existentes se basan en grupos de conversaciones, siendo requerida una autentificación individual para un grupo de conversaciones. Aunque estas soluciones alivian la necesidad de autentificación para cada consulta, requieren importantes cambios en los equipos existentes.
Con referencia a la figura 5, el dispositivo externo 200 solicita el ESB 10 (etapa 501). El ESB abre una sesión y crea un identificador de sesión ID. El ESB encamina la solicitud a un servidor de aplicaciones A2 a cargo de las verificaciones de seguridad (etapa 502). El servidor de aplicaciones A2 procesa la transacción y genera credenciales de seguridad que son enviados de vuelta al dispositivo externo a través del ESB 10 (etapa 504). El ESB 10 almacena el identificador de sesión ID y las configuraciones de seguridad. Eventualmente, el servidor de aplicaciones A2 solicita otro servidor de aplicaciones (C2) creando otra parte del contexto para esa sesión (etapa 503).
El dispositivo externo 200 envía entonces otra solicitud al ESB 10. Típicamente, esta solicitud es otra consulta que debe ser procesada por el sistema 100 (etapa 505).
La solicitud contiene el identificador de sesión ID de la sesión ya abierta. Adicionalmente, la solicitud contiene un requerimiento de clonar la sesión ya abierta. El ESB 10 a cargo de la sesión anteriormente abierta recupera las configuraciones de seguridad teniendo en cuenta el identificador de sesión ID. La parte a0 del contexto de la sesión anterior y que contiene las configuraciones de seguridad se duplica para formar una parte del contexto a0’ para la sesión clonada. Entonces la transacción para esa sesión clonada que contiene las configuraciones de seguridad es encaminada hacia el servidor de aplicaciones pertinente (B3) (etapa 506). Dicho servidor de aplicaciones pertinente no es un servidor de aplicaciones dedicado a la generación de configuraciones de seguridad. Sin embargo esta aplicación pertinente verifica si la transacción recibida comprende las configuraciones de seguridad requeridas.
El servidor de aplicaciones B3 puede por lo tanto procesar la transacción y enriquecer el contexto de la sesión clonada. Los resultados del procesamiento son enviados al ESB y la consulta desde el dispositivo externo 200 se completa (etapa 507).
La sesión clonada por lo tanto comprende su propio contexto excepto a0’ con respecto a las configuraciones de seguridad, esto es el contexto aplicativo de la sesión clonada es independiente del de la sesión ya abierta.
A partir de la descripción anterior, es evidente que la presente invención proporciona un modo de aportar una visión única de una aplicación del cliente completamente distribuida, todas las partes del dispositivo externo posiblemente distribuido utilizando la misma conversación hacia el exterior o hacia el interior con el sistema.
Adicionalmente, la presente invención proporciona un modo de gestionar la misma sesión a partir de protocolos de comunicación heterogéneos. Esto facilita la migración desde un protocolo a otro o la integración de dispositivos externos heterogéneos.
También proporciona un modo de gestionar diversas sesiones de contexto y consultas paralelas sin estado en una sesión de seguridad individual.
La descripción anterior ha proporcionado a título de ejemplos no limitativos y ejemplares una descripción completa e informativa de diversos procedimientos, aparatos y software de programas de ordenador para la implantación de las formas de realización ejemplares de esta invención. Sin embargo, diversas modificaciones y adaptaciones se les pueden poner de manifiesto a aquellos expertos en la técnica pertinente a la vista de la descripción anterior, con la lectura de la misma conjuntamente con los dibujos adjuntos y las reivindicaciones anexas. Como algunos ejemplos, la utilización de otras estructuras de datos similares o equivalentes y flujos lógicos se puede intentar por parte de aquellos expertos en la técnica. Sin embargo, todas las modificaciones de este tipo y similares de las enseñanzas de esta invención todavía quedarán dentro del ámbito de las formas de realización de esta invención.
Adicionalmente, algunas de las características de las formas de realización ejemplares de esta invención pueden ser utilizadas con ventaja sin la utilización correspondiente de las otras características. Como tal, la descripción anterior debe ser considerada como meramente ilustrativa de los principios, enseñanzas y formas de realización de esta invención y no como limitación de la misma.

Claims (19)

  1. REIVINDICACIONES
    1. Procedimiento de proporcionar un dispositivo externo (200, 300, 300’) con una sesión en un entorno de ordenadores distribuidos, en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo 5 externo (200, 300, 300’) y servidores de aplicaciones (A1, …, C4) de un sistema (100), el dispositivo externo (200, 300, 300’) y el sistema (100) funcionando en un modo de cliente/servidor, el sistema (100) funcionando en un modo entre el modo de cliente y el modo de servidor, el dispositivo externo (200, 300, 300’) funcionando en el otro modo entre el modo de cliente y el modo de servidor, en el que cada servidor de aplicaciones procesa por lo menos una aplicación de software (A, B, C, D), por lo menos algunos de los servidores de aplicaciones (A1, …, C4) estando
    10 dispuestos para almacenar localmente en medios de almacenaje de datos por lo menos una parte de un contexto de la sesión, permitiendo de ese modo distribuir el contexto por diversos servidores de aplicaciones (A1, …, C4);
    en el que por lo menos un medio de encaminamiento (10, 15) comprendido en el sistema (100) realiza una etapa de establecimiento, para una sesión determinada, de una conversación entre el dispositivo externo (200, 300, 300’) y
    15 por lo menos uno de los servidores de aplicaciones (A1, …, C4);
    en el que el establecimiento de la conversación comprende las siguientes etapas realizadas en el medio de encaminamiento (10, 15) con por lo menos un procesador de datos:
    20 - recepción de una solicitud desde uno entre el servidor de aplicaciones y el dispositivo externo para llegar al otro entre el servidor de aplicaciones y el dispositivo externo;
    -
    determinación de si la solicitud comprende un identificador de sesión (ID),
    25 -si la solicitud no comprende un identificador de sesión ID, entonces abertura de una sesión para dicha conversación, creando un identificador de sesión ID que unívocamente identifica dicha sesión, añadiendo el identificador de sesión ID a la solicitud, almacenando el identificador de sesión ID y encaminando la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’), estableciendo de ese modo la conversación;
    -
    si la solicitud ya comprende un identificador de sesión ID, entonces encaminamiento de la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’) estableciendo de ese modo la conversación y permitiendo que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID a través de permitir que la conversación
    35 comparta el contexto de dicha sesión ya abierta;
    caracterizado porque el sistema (100) comprende una pluralidad de medios de encaminamiento (10, 11, 12, 13, 15) en el que para una sesión determinada un medio de encaminamiento entre la pluralidad de medios de encaminamiento es un medio de encaminamiento principal (10, 15) a cargo de transacciones de encaminamiento 40 entre el dispositivo externo (200, 300, 300’) y el sistema (100); la etapa de permitir que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID comprendiendo las siguientes etapas realizadas en el medio de encaminamiento que recibe la solicitud: elección de los otros medios de encaminamiento para identificar cuál de entre la pluralidad de medios de encaminamiento es el medio de encaminamiento principal para dicha sesión ya abierta y enviar entonces la solicitud al medio de encaminamiento
    45 principal.
  2. 2. El procedimiento según la reivindicación anterior en el que la conversación establecida tiene un primer identificador de sesión ID y utiliza un primer protocolo y en el que por lo menos otra conversación tiene el mismo identificador de sesión ID y utiliza un segundo protocolo diferente del primer protocolo.
  3. 3.
    El procedimiento según cualquiera de las reivindicaciones anteriores en el que el dispositivo externo (200) funciona en un modo de cliente con respecto al sistema (100) que funciona en un modo de servidor.
  4. 4.
    El procedimiento según la reivindicación anterior en el que todos los servidores de aplicaciones (A1, …, C4)
    55 que reciben solicitudes provistas del mismo identificador de sesión ID comparten la misma sesión hacia el interior con el dispositivo externo (200).
  5. 5. El procedimiento según cualquiera de las reivindicaciones 1 o 2 en el que el dispositivo externo (300, 300’)
    funciona en un modo de servidor con respecto al sistema (100) que funciona en un modo de cliente. 60
  6. 6.
    El procedimiento según la reivindicación anterior en el que todos los servidores de aplicaciones (A1, …, C4) que reciben solicitudes que comparten el mismo identificador de sesión ID comparten la misma conversación hacia el exterior con el dispositivo externo (300, 300’).
  7. 7.
    El procedimiento según cualquiera de las reivindicaciones anteriores en el que el dispositivo externo (200) funciona en un modo de cliente con respecto al sistema (100) que funciona en un modo de servidor y en el que un dispositivo externo adicional (300) funciona en un modo de servidor con respecto al sistema (100) que funciona en un modo de cliente.
  8. 8. El procedimiento según cualquiera de las reivindicaciones anteriores en el que después de la etapa de la recepción de una solicitud en los medios de encaminamiento y antes de la etapa de la determinación de si la solicitud comprende un identificador de sesión (ID), el procedimiento comprende una etapa adicional de la determinación de que la solicitud requiere sumarse a una sesión ya abierta.
  9. 9. El procedimiento según la reivindicación anterior en el que la etapa de la determinación de que la solicitud requiere sumarse a una sesión ya abierta comprende la recepción de un requerimiento de sumarse a una sesión ya abierta y en el que el requerimiento de sumarse a una sesión ya abierta está contenido en una capa de la sesión del protocolo de dicha solicitud y en el que la solicitud comprende una cabecera que comprende un requerimiento de
    15 sumarse a una sesión.
  10. 10. El procedimiento según la reivindicación 8 en el que la etapa de la determinación de que la llamada requiere sumarse a una sesión ya abierta comprende la siguiente etapa: el medio de encaminamiento determina que la solicitud recibida proviene de o requiere ser encaminada a un servidor de aplicaciones que procesa una aplicación
    20 de software dedicada a requerimientos de sumarse a una sesión ya abierta, el cual indica a los medios de encaminamiento que la solicitud recibida debe sumarse a una sesión ya abierta.
  11. 11. El procedimiento según cualquiera de las reivindicaciones anteriores en el que una conversación
    determinada de una sesión está provista de una propiedad que controla el cierre de la sesión. 25
  12. 12.
    El procedimiento según la reivindicación anterior en el que la propiedad está configurada para cerrar la sesión en el momento del cierre de dicha conversación determinada.
  13. 13.
    El procedimiento según la reivindicación 11 en el que la propiedad está configurada para cerrar la sesión en
    30 el momento del cierre de dicha conversación determinada si todavía no está abierta otra conversación para esa sesión y en el que la propiedad está configurada para mantener la sesión abierta en el momento del cierre de dicha conversación determinada y si por lo menos otra conversación está todavía abierta para esa sesión.
  14. 14. El procedimiento según la reivindicación 11 en el que la propiedad está configurada para cerrar la sesión
    35 después del final de un periodo de tiempo de inactividad previamente determinado que empieza en el momento del cierre de dicha conversación determinada.
  15. 15. El procedimiento según cualquiera de las reivindicaciones anteriores en el que en el momento del cierre de
    una sesión el medio de encaminamiento envía a todos los servidores de aplicaciones (A1, …, C4) que comparten 40 una conversación para esa sesión una notificación de cierre de la sesión.
  16. 16. El procedimiento según cualquiera de las reivindicaciones anteriores en el que el sistema comprende servidores de aplicaciones (A1, …, C4) que forman grupos (20, 30, 40) de servidores de aplicaciones (A1, …, C4) dedicados a una aplicación de software, cada servidor de aplicaciones (A1, …, A8) del mismo grupo (20)
    45 procesando independientemente la aplicación de software (A) a la cual está dedicado el grupo, los servidores de aplicaciones almacenando una parte del contexto de una sesión definiendo de ese modo para cada sesión un conjunto de servidores de aplicaciones que tienen cada uno una afinidad con la sesión del usuario, el procedimiento comprendiendo las siguientes etapas en los medios de encaminamiento:
    50 - asignación a la sesión de un registro de correlación (DCX) dispuesto para comprender claves de afinidad, cada clave de afinidad indicando el servidor de aplicaciones que tiene una afinidad con la sesión para una aplicación de software determinada,
    -
    propagación del registro de correlación con la transacción a un servidor de aplicaciones que es pertinente
    55 para procesar la transacción, permitiendo de ese modo que los medios de encaminamiento se dirijan como objetivo a los servidores de aplicaciones que están vinculados al contexto de esa sesión.
  17. 17. El procedimiento según cualquiera de las reivindicaciones anteriores en el que el dispositivo externo funciona en un modo de cliente y el sistema (100) funciona en un modo de servidor, en el que el dispositivo externo
    60 requiere abrir una nueva sesión mientras hereda las configuraciones de seguridad a partir de una sesión ya abierta, en el que las configuraciones de seguridad heredadas comprenden la duplicación de una parte de un contexto de la sesión ya abierta, dicha parte del contexto conteniendo las configuraciones de seguridad de la sesión ya abierta y en el que la nueva sesión tiene un contexto que es independiente del contexto de la sesión ya abierta excepto por una parte de su contexto que contiene las configuraciones de seguridad.
    65 18. El procedimiento según la reivindicación anterior en el que el requerimiento de abrir una nueva sesión mientras se heredan las configuraciones de seguridad a partir de una sesión ya abierta, comprende las siguientes etapas realizadas en los medios de encaminamiento:
    5 - recepción desde el dispositivo externo de un requerimiento de abrir una nueva sesión y de un identificador de sesión ID que identifica la sesión ya abierta,
    -
    recuperación de las configuraciones de seguridad de la sesión ya abierta sobre la base de dicho
    identificador de sesión ID, 10
    -
    propagación de dichas configuraciones de seguridad con una conversación de la nueva sesión.
  18. 19. Un medio legible por ordenador no transitorio que contiene instrucciones de programas de software en el que la ejecución de las instrucciones de los programas de software mediante por lo menos un procesador de datos
    15 resulta en la realización de operaciones que comprenden la ejecución del procedimiento como en cualquiera de las reivindicaciones anteriores.
  19. 20. Sistema para proporcionar un dispositivo externo (200, 300, 300’) con una sesión en un entorno de
    ordenadores distribuidos, en el que la sesión requiere el establecimiento de conversaciones entre el dispositivo 20 externo (200, 300, 300’) y servidores de aplicaciones (A1, …, C4) comprendidos en el sistema (100), el sistema
    (100) estando configurado para funcionar en un modo de cliente/servidor con el dispositivo externo (200, 300, 300’), el sistema (100) funcionando en un modo entre el modo de cliente y el modo de servidor, el dispositivo externo (200, 300, 300’) funcionando en el otro modo entre el modo de cliente y el modo de servidor, el sistema comprendiendo una pluralidad de máquinas que comprende cada una por lo menos un procesador, por lo menos algunas de las
    25 máquinas comprendiendo medios de almacenaje de datos, cada servidor de aplicaciones funcionando en una máquina y estando dispuesto para procesar cada una de las por lo menos una aplicación de software, por lo menos algunos de los servidores de aplicaciones (A1, …, C4) estando dispuestos para almacenar localmente en medios de almacenaje de datos por lo menos una parte de un contexto de la sesión, permitiendo de ese modo distribuir el contexto por diversos servidores de aplicaciones (A1, …, C4);
    30 el sistema (100) comprendiendo medios de encaminamiento (10, 15) que comprenden por lo menos un procesador de datos configurado para establecer una conversación entre el dispositivo externo (200, 300, 300’) y los servidores de aplicaciones (A1, …, C4), el uno o más medios de encaminamiento (10, 15) estando configurado para:
    35 - recibir una solicitud desde uno entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’) para llegar al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’);
    -
    determinación de si la solicitud comprende un identificador de sesión (ID),
    40 -si la solicitud no comprende un identificador de sesión ID, entonces abertura de una sesión para dicha conversación, creando un identificador de sesión ID que unívocamente identifica dicha sesión, añadiendo el identificador de sesión ID a la solicitud, almacenando el identificador de sesión ID y encaminamiento de la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’), estableciendo de ese modo la conversación;
    -
    si la solicitud ya comprende un identificador de sesión ID, entonces encaminamiento de la solicitud al otro entre el servidor de aplicaciones y el dispositivo externo (200, 300, 300’) estableciendo de ese modo la conversación y permitiendo que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID a través de permitir que la conversación
    50 comparta el contexto de dicha sesión ya abierta;
    caracterizado porque el sistema (100) comprende una pluralidad de medios de encaminamiento (10, 11, 12, 13, 15) en el que para una sesión determinada un medio de encaminamiento entre la pluralidad de medios de encaminamiento es un medio de encaminamiento principal (10, 15) a cargo de transacciones de encaminamiento 55 entre el dispositivo externo (200, 300, 300’) y el sistema (100); y porque el sistema está configurado de modo que la etapa de permitir que dicha conversación se sume a una sesión ya abierta que está unívocamente identificada por dicho identificador de sesión ID comprende las siguientes etapas realizadas en el medio de encaminamiento que recibe la solicitud: elección de los otros medios de encaminamiento para identificar cuál de entre la pluralidad de medios de encaminamiento es el medio de encaminamiento principal para dicha sesión ya abierta y enviar entonces
    60 la solicitud al medio de encaminamiento principal.
    Protocolo 1 Protocolo 2 Protocolo 3
    Conversación 1
    Conversación 2
    Sistema
ES11305280.7T 2011-03-15 2011-03-15 Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo Active ES2454548T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP11305280.7A EP2501107B1 (en) 2011-03-15 2011-03-15 Method and system for providing a session in a heterogeneous environment

Publications (1)

Publication Number Publication Date
ES2454548T3 true ES2454548T3 (es) 2014-04-10

Family

ID=44741243

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11305280.7T Active ES2454548T3 (es) 2011-03-15 2011-03-15 Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo

Country Status (13)

Country Link
US (1) US8473626B2 (es)
EP (1) EP2501107B1 (es)
JP (1) JP5898240B2 (es)
KR (1) KR101640296B1 (es)
CN (1) CN103404111B (es)
AU (1) AU2012228220B2 (es)
BR (1) BR112013018589A2 (es)
CA (1) CA2824394C (es)
ES (1) ES2454548T3 (es)
PL (1) PL2501107T3 (es)
SG (1) SG192160A1 (es)
WO (1) WO2012123546A1 (es)
ZA (1) ZA201305951B (es)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2500856A1 (en) 2011-03-15 2012-09-19 Amadeus S.A.S. Method and system for providing a session involving a plurality of software applications
EP2500848A1 (en) 2011-03-15 2012-09-19 Amadeus S.A.S. Method and system for centralized reservation context management on multi-server reservation system
US9235620B2 (en) 2012-08-14 2016-01-12 Amadeus S.A.S. Updating cached database query results
EP2541473A1 (en) 2011-06-27 2013-01-02 Amadeus S.A.S. Method and system for a pre-shopping reservation system with increased search efficiency
CN103580986B (zh) * 2012-07-30 2016-12-21 华为终端有限公司 一种实时通信方法、终端设备、实时通信服务器及系统
GB201305211D0 (en) 2013-03-21 2013-05-01 Ibm Workload placement in a computer system
TWI561035B (en) * 2013-08-12 2016-12-01 Chunghwa Telecom Co Ltd Dynamic dispatching business operations in heterogeneous systems
US9519509B2 (en) * 2014-10-21 2016-12-13 Oracle International Corporation System and method for supporting transaction affinity based request handling in a middleware environment
US20160285957A1 (en) * 2015-03-26 2016-09-29 Avaya Inc. Server cluster profile definition in a distributed processing network
DE102015222956A1 (de) * 2015-11-20 2017-05-24 Robert Bosch Gmbh Verfahren zum Betreiben eines Serversystems und zum Betreiben eines Aufnahmegeräts zum Aufnehmen eines Sprachbefehls, Serversystem, Aufnahmegerät und Sprachdialogsystem
CN109617749B (zh) * 2019-01-31 2021-08-06 郑州物海网络科技有限公司 基于互联网实现柔性配置终端设备和路由规则的方法
FR3103664B1 (fr) 2019-11-27 2023-04-07 Amadeus Sas Système de stockage distribué pour stocker des données contextuelles
US11637819B2 (en) * 2020-11-25 2023-04-25 International Business Machines Corporation Establishing connectivity between user devices
CN115203689B (zh) * 2022-07-25 2023-05-02 广州正则纬创信息科技有限公司 一种数据安全分享方法及系统

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6158044A (en) 1997-05-21 2000-12-05 Epropose, Inc. Proposal based architecture system
US6208955B1 (en) 1998-06-12 2001-03-27 Rockwell Science Center, Llc Distributed maintenance system based on causal networks
US7328166B1 (en) 1999-01-20 2008-02-05 Sabre, Inc. Global reservations transaction management system and method
US6392997B1 (en) 1999-03-16 2002-05-21 Cisco Technology, Inc. Technique for group-based routing update with limited per neighbor/adjacency customization
AU4350700A (en) 1999-04-16 2000-11-02 Cg & G Software Plus Tee time reservation system
US6748420B1 (en) * 1999-11-23 2004-06-08 Cisco Technology, Inc. Methods and apparatus for providing shared access to an application
US7437408B2 (en) 2000-02-14 2008-10-14 Lockheed Martin Corporation Information aggregation, processing and distribution system
US6990513B2 (en) 2000-06-22 2006-01-24 Microsoft Corporation Distributed computing services platform
NO312697B1 (no) 2000-09-01 2002-06-17 Ericsson Telefon Ab L M Fremgangsmåte for å tilveiebringe effektive operasjoner i et serversystem
US6640222B1 (en) 2000-09-29 2003-10-28 Motorola, Inc. Method for selecting an information unit among conflicting information units based on context fields by a user device
US20020078150A1 (en) * 2000-12-18 2002-06-20 Nortel Networks Limited And Bell Canada Method of team member profile selection within a virtual team environment
US7165105B2 (en) 2001-07-16 2007-01-16 Netgenesis Corporation System and method for logical view analysis and visualization of user behavior in a distributed computer network
US7512652B1 (en) * 2001-09-28 2009-03-31 Aol Llc, A Delaware Limited Liability Company Passive personalization of buddy lists
AU2002366060A1 (en) 2001-11-20 2003-06-10 T.I.G.R. Ghaniem Family Trust A method of receiving a booking request from a user, making the booking and generating a travel confirmation document
US8209200B2 (en) 2002-03-13 2012-06-26 Orbitz Llc System and method for synchronizing passenger name record data
CA2381737A1 (en) 2002-04-15 2003-10-15 Ibm Canada Limited-Ibm Canada Limitee Framework for managing data that provides correlation information in a distributed computing system
US20030233473A1 (en) * 2002-05-07 2003-12-18 International Business Machines Corporation Method for configuring logical connections to a router in a data communication system
US7146400B2 (en) * 2002-05-29 2006-12-05 International Business Machines Corporation Web and lotus notes adapter layers
US7454761B1 (en) 2002-12-20 2008-11-18 Cisco Technology, Inc. Method and apparatus for correlating output of distributed processes
US20040128542A1 (en) 2002-12-31 2004-07-01 International Business Machines Corporation Method and system for native authentication protocols in a heterogeneous federated environment
US7430187B2 (en) * 2003-05-15 2008-09-30 At&T Intellectual Property I, Lp Methods, systems, and computer program products for providing different quality of service/bandwidth allocation to different susbscribers for interactive gaming
CA2527668A1 (en) 2003-06-02 2004-12-16 Liquid Machines, Inc. Managing data objects in dynamic, distributed and collaborative contexts
AU2004247251B2 (en) * 2003-06-12 2009-01-22 Camiant, Inc. PCMM application manager
KR100541758B1 (ko) 2003-07-08 2006-01-10 주식회사 팬택앤큐리텔 무선가입자망의 가입자접속장치에서 패킷 형태의 과금갱신 정보 전송 방법
MXPA06001530A (es) 2003-08-13 2006-05-15 Microsoft Corp Sugerencias de enrutamiento.
US7395279B2 (en) 2003-11-17 2008-07-01 International Business Machines Corporation System and method for achieving different levels of data consistency
US20050262100A1 (en) 2004-05-19 2005-11-24 Bea Systems, Inc. System and method for context propagation in application servers and transaction-based systems
US20060155857A1 (en) * 2005-01-06 2006-07-13 Oracle International Corporation Deterministic session state management within a global cache array
US20060212583A1 (en) * 2005-03-17 2006-09-21 Beadle Bruce A Distributing messaging session logs to users entering an already ongoing messaging session
US7412224B2 (en) 2005-11-14 2008-08-12 Nokia Corporation Portable local server with context sensing
ATE547907T1 (de) * 2005-12-12 2012-03-15 Ericsson Telefon Ab L M Verfahren und anordnung zum herstellen einer kommunikationssitzung für multimedia
JP2007219608A (ja) 2006-02-14 2007-08-30 Fujitsu Ltd 負荷分散処理プログラム及び負荷分散装置
US7702145B2 (en) 2006-06-28 2010-04-20 Microsoft Corporation Adapting a neural network for individual style
US7774463B2 (en) 2006-07-25 2010-08-10 Sap Ag Unified meta-model for a service oriented architecture
US8112550B2 (en) 2006-09-19 2012-02-07 Tacoda Llc System and method for preserving consumer choice
US7870267B2 (en) * 2007-05-16 2011-01-11 International Business Machines Corporation Creating global sessions across converged protocol applications
US8108528B2 (en) * 2007-07-11 2012-01-31 International Business Machines Corporation System and method for verifying the identity of a chat partner during an instant messaging session
CN101187946A (zh) 2007-12-14 2008-05-28 无敌科技(西安)有限公司 利用实时信息更新数据系统及其方法
WO2009144862A1 (ja) * 2008-05-28 2009-12-03 パナソニック株式会社 通信端末装置及び通信制御方法並びに通信制御プログラム
US20100312586A1 (en) 2009-06-03 2010-12-09 Drefs Martin J Generation of Travel-Related Offerings
US20120173736A1 (en) * 2009-09-18 2012-07-05 Deutsche Telekom Ag Method for supporting a user equipment lacking globally routable user agent uri - gruu support in an internet protocol multimedia subsystem - ims
CN102036319B (zh) * 2009-09-30 2013-11-06 中兴通讯股份有限公司 一种带有彩铃的振铃状态会话的切换系统及方法
US9515849B2 (en) * 2009-12-22 2016-12-06 At&T Intellectual Property I, L.P. Method and apparatus for managing communication faults
US9535769B2 (en) 2010-02-05 2017-01-03 Oracle International Corporation Orchestrated data exchange and synchronization between data repositories
IN2012CN07527A (es) * 2010-02-12 2015-08-07 Tekelec Inc
US10455275B2 (en) * 2010-02-16 2019-10-22 Comcast Cable Communications, Llc Disposition of video alerts and integration of a mobile device into a local service domain
US8850219B2 (en) * 2010-05-13 2014-09-30 Salesforce.Com, Inc. Secure communications
US9535762B2 (en) * 2010-05-28 2017-01-03 At&T Intellectual Property I, L.P. Methods to improve overload protection for a home subscriber server (HSS)
US8655996B2 (en) * 2010-06-30 2014-02-18 At&T Intellectual Property I, L.P. Customized behavior of a control layer towards an application server in a packet-based network
US8990380B2 (en) * 2010-08-12 2015-03-24 Citrix Systems, Inc. Systems and methods for quality of service of ICA published applications
US9392121B2 (en) * 2010-09-20 2016-07-12 International Business Machines Corporation Seamlessly conferencing a previously-connected telephone call
US9880014B2 (en) * 2010-11-24 2018-01-30 Telenav, Inc. Navigation system with session transfer mechanism and method of operation thereof
US8510435B2 (en) * 2010-12-27 2013-08-13 Avaya Inc. Highly scalable and distributed call/media modeling and control framework

Also Published As

Publication number Publication date
AU2012228220B2 (en) 2015-01-22
US20120239818A1 (en) 2012-09-20
BR112013018589A2 (pt) 2016-09-27
CN103404111B (zh) 2016-06-08
EP2501107A1 (en) 2012-09-19
ZA201305951B (en) 2014-10-29
CA2824394C (en) 2019-02-12
US8473626B2 (en) 2013-06-25
KR101640296B1 (ko) 2016-07-15
CA2824394A1 (en) 2012-09-20
WO2012123546A1 (en) 2012-09-20
KR20140015395A (ko) 2014-02-06
JP2014509803A (ja) 2014-04-21
SG192160A1 (en) 2013-08-30
CN103404111A (zh) 2013-11-20
AU2012228220A1 (en) 2013-05-02
JP5898240B2 (ja) 2016-04-06
EP2501107B1 (en) 2014-01-22
PL2501107T3 (pl) 2014-08-29

Similar Documents

Publication Publication Date Title
ES2454548T3 (es) Procedimiento y sistema para proporcionar una sesión en un entorno heterogéneo
CA3088416C (en) Systems and methods for privacy management using a digital ledger
US9478084B1 (en) System and method for cloud controlled common access entry point locking system
ES2751111T3 (es) Método y aparato para capa de mapa personal compartida segura
CN104426740B (zh) 用于管理隧道化端点的系统和方法
US20080270019A1 (en) Systems and methods for enhancing private transportation
CN103312624B (zh) 一种消息队列服务系统和方法
ES2778773T3 (es) Métodos y sistemas para comunicación entre un vehículo y un servidor de aplicaciones remoto
BR102013012756B1 (pt) Método implementado por computador, dispositivo de computação e meio não transitório legível por computador
TW200839190A (en) Traffic information adaptive to a user's travel
US10616003B2 (en) Methods and systems for service interworking between servers using different user identification systems
JP2017507563A (ja) トラフィックポリシーの実施をサポートするエンティティハンドルレジストリ
US20230396987A1 (en) Mobile Application Configurations To Enable Data Transfers
US11916897B2 (en) Isolating networks and credentials using on-demand port forwarding
US20230171344A1 (en) System and method for enhanced virtual queuing
US20180197153A1 (en) Electronic calendaring and traveling facility
CN104580428B (zh) 一种数据路由方法、数据管理装置和分布式存储系统
US9203741B1 (en) Managing multi-customer network traffic using lower layer protocol attributes
JP6728227B2 (ja) エフェメラルデータに基づいてクエリ応答を提供するためのデバイスおよび／または方法
US20150172860A1 (en) System and method for identifying a geometric footprint of a point of interest
US20230224146A1 (en) Quorum-based authorization
US20150100511A1 (en) System and method for recruitment
US11695765B2 (en) Techniques for selective container access to cloud services based on hosting node
US20240146543A1 (en) Obtaining a domain certificate utilizing a proxy server
US11863707B2 (en) System and method for enhanced virtual queuing with targeted interactions