ES2689112T3 - Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores - Google Patents

Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores Download PDF

Info

Publication number
ES2689112T3
ES2689112T3 ES11305278.1T ES11305278T ES2689112T3 ES 2689112 T3 ES2689112 T3 ES 2689112T3 ES 11305278 T ES11305278 T ES 11305278T ES 2689112 T3 ES2689112 T3 ES 2689112T3
Authority
ES
Spain
Prior art keywords
pnr
context
server
version
servers
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
ES11305278.1T
Other languages
English (en)
Inventor
Vincent Masini
Samuel Burdese
Marc Pavot
Jerome Daniel
Dietmar Fauser
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 ES2689112T3 publication Critical patent/ES2689112T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17325—Synchronisation; Hardware support therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/14—Travel agencies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Mathematical Physics (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)
  • Hardware Redundancy (AREA)

Abstract

Un método de sincronización, en una aplicación de reservas que opera en un sistema de múltiples servidores, intercambiando la aplicación de reservas (101) información relacionada con viajes por medio de una estructura de datos de Registro de Nombres de Pasajeros (PNR), para garantizar que se usa el PNR más actualizado durante una transacción de usuario a través de al menos dos servidores del sistema de múltiples servidores, en el que una versión de contexto local del PNR se mantiene dentro de cada servidor del sistema de múltiples servidores, estando los servidores interconectados a través de un medio de encaminamiento, incluyendo el método las etapas de: - mantenimiento en un área de almacenamiento de contexto compartido (1003), accesible por todos los servidores del sistema de múltiples servidores, de información acerca de la ubicación de la última versión modificada de PNR; - en respuesta a una petición de usuario que provoca que uno de los servidores seleccionado modifique la versión de contexto local de PNR realizando las siguientes acciones: - comprobar en el área de almacenamiento de contexto compartido qué servidor modificó por última vez el PNR; - si el servidor que modificó por última vez el PNR es diferente del servidor seleccionado, obtener la versión más actualizada de PNR; - modificar la versión de contexto local de PNR para satisfacer la petición de usuario; - actualizar el área de almacenamiento de contexto compartido para reflejar la última versión modificada de PNR.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores Campo de la invención
La presente invención se refiere al campo de sistemas de reservas de viajes, más particularmente a un método y sistema para manejar reservas de viajes en múltiples servidores usando un mecanismo de sincronización de contexto distribuido.
Antecedentes de la invención
Las empresas de viajes modernas (por ejemplo, aerolíneas) normalmente emplean aplicaciones sofisticadas para manejar peticiones de reservas por clientes. Es más, y más frecuente el caso en el que se usa más de una arquitectura por todo el sistema de la empresa. En tales cases deberían tenerse en cuenta cuestiones de compatibilidad y sincronización cuando se diseña y planifica el sistema de reservas. Un ejemplo es cuando parte de la gestión de reservas se realiza en aplicaciones basadas en Internet o infraestructuras de comunicación. Otro ejemplo es cuando un sistema (no necesariamente un sistema de reservas) debe migrarse desde un sistema de ordenador central heredado (por ejemplo, TPF) a un sistema nuevo (por ejemplo, un sistema abierto). Nos referimos a este último ejemplo como un Desmantelamiento, es decir cuando una aplicación debe migrarse desde por ejemplo un ordenador central de TPF a por ejemplo un sistema abierto. Para evitar la interrupción del servicio en el sistema de reservas, se aconseja realizar esta migración de forma progresiva, en lugar de cerrar el sistema existente y cambiar al nuevo en un único movimiento, con todos los posibles problemas que podrían surgir: además de la complejidad de un gran procedimiento de activación en el momento del cambio entre el sistema viejo y nuevo, también debería considerarse la necesidad de doble mantenimiento de software en ambas plataformas, mientras el sistema nuevo está en construcción y el viejo continua evolucionando. Quizás deban desarrollarse nuevas funcionalidades y esto requiere un esfuerzo doble, mientras que, si los dos sistemas pueden trabajar juntos, todo el esfuerzo de desarrollo puede dedicarse a la nueva plataforma. Por estas razones, se prefiere una migración progresiva a una así llamada estrategia de migración de "gran explosión", sin embargo, deben considerarse algunas dificultades. En particular, cuando los servicios de reservas se distribuyen entre dos plataformas diferentes (por ejemplo, ordenador central y plataformas abiertas) requieren compartir los mismos datos contextuales de Registro de Nombres de Pasajeros (PNR) en modo lectura y escritura para realizar sus funcionalidades de actividad. Una de las cuestiones a considerar es la sincronización de datos (por ejemplo, datos de PNR) que se comparten en modo lectura y escritura a través de plataformas diferentes y a través de protocolos de comunicación (por ejemplo, ordenador central de TPF y sistemas abiertos) de modo que los sistemas pueden compartir los mismos datos de contexto de PNR actualizados. Con "contexto" queremos decir el contexto de la sesión de compra que se vincula a una sesión de usuario (final) activa. Representa toda la información funcional y técnica que se usa por el sistema para que este usuario específico realice las funcionalidades solicitadas, por ejemplo, en el sistema de reservas de viajes, el contexto de sesión de reserva (compra) que se vincula a una sesión de usuario final activo.
El documento US2005/108298 (IYENGAR ARUN K [US] ET AL IYENGAR ARUN KWANGIL [US] ET AL) del 19 de mayo de 2005, describe un sistema de sincronización de múltiples servidores que proporciona una solución para actualizar múltiples copias del mismo objeto cuando el objeto se actualiza. Sin embargo, el contexto de la ultima actualización no incluye la ubicación de servidor en la que se hizo la actualización y deben realizarse más actualizaciones de las necesarias para mantener la consistencia.
El documento EP2259217 (ACCENTURE GLOBAL SERVICIOS GMBH [CH]) del 8 de diciembre de 2010, describe sincronización de lotes de PNR en sistemas de reservas de viajes. Sin embargo, se requiere una gran sobrecarga de recursos para implementar una solución de sincronización de este tipo.
Objeto de la invención
Un objeto de la presente invención es mitigar al menos algunos de los problemas asociados con los sistemas de la técnica anterior.
La solución de la presente invención se proporciona mediante la materia objeto de las reivindicaciones. Según un aspecto de la presente invención se proporciona un método para mecanismo de sincronización, en un método de reservas que opera en un sistema de múltiples servidores, para garantizar que se usa el registro de PNR más actualizado durante una transacción de usuario a través de al menos dos servidores del sistema de múltiples servidores, en el que una versión de contexto local del PNR se mantiene dentro de cada servidor del sistema de múltiples servidores, estando los servidores interconectados a través de un bus de sistema, incluyendo el mecanismo las etapas de: mantenimiento en un área de almacenamiento de contexto compartido, accesible por todos los servidores del sistema de múltiples servidores, de información acerca de la ultima versión actualizada de PNR; en respuesta a una petición de usuario que provoca que uno seleccionado de los servidores modifique la versión de contexto local de PNR, realización de las siguientes acciones: comprobar en el área de almacenamiento de contexto compartido qué servidor modificó por última vez el PNR; si el servidor que modificó por última vez el
5
10
15
20
25
30
35
40
45
50
55
60
65
PNR es diferente del servidor seleccionado, obtener la versión más actualizada de PNR; modificar la versión de contexto local de PNR para satisfacer la petición de usuario; actualizar el área de almacenamiento de contexto compartido para reflejar la ultima versión actualizada de PNR.
El método según una realización preferida de la presente invención permite la sincronización de los valores de PNR a través de un sistema de múltiples servidores (posiblemente multiplataforma) con un mecanismo eficiente y consistente. El mecanismo aborda las cuestiones de consistencia y rendimiento gracias a sus versiones y su vago comportamiento (la sincronización se produce únicamente cuando se requiere). Puede usarse como una solución durante una fase de migración desde un sistema a otro con migración progresiva de aplicaciones que comparten datos y también como una solución permanente para aplicaciones distribuidas a través de plataformas diferentes.
Según un segundo aspecto de la presente invención se proporciona un sistema que comprende uno o más componentes adaptados para realizar el método descrito anteriormente.
Según una realización adicional de la presente invención se proporciona un programa informático que comprende instrucciones para efectuar el método descrito anteriormente cuando dicho programa informático se ejecuta en un sistema informático.
Breve descripción de los dibujos
Se hará ahora referencia, a modo de ejemplo, a los dibujos adjuntos, en los que:
la Figura 1 es un diagrama del sistema de inventario según una realización de la presente invención;
la Figura 2 muestra esquemáticamente una posible estructura de un Dispositivo de Correlación de Contexto Distribuido usado en una realización preferida de la presente invención;
la Figura 3 muestra un procesamiento de peticiones en plataformas diferentes con el cambio asociado de valores en el contexto compartido con un formalismo de caso de uso;
la Figura 4 es un diagrama de un sistema informático general adaptado para soportar el método de una realización preferida de la presente invención;
las Figuras 5 a 9 (a y b) muestran los cinco servicios de Sincronización de Contexto Distribuido con una estructura de EDIFACT (figura a) y un diagrama de caso de uso (figura b), según una realización preferida de la presente invención;
la Figura 10 es un diagrama de flujo de las etapas de método de un proceso, según una realización de la presente invención.
Descripción detallada de las realizaciones
El ejemplo en el que se basa la presente descripción es la migración desde una arquitectura TPF compleja para un sistema de reservas a una arquitectura de sistema abierto. Por muchas razones, como se ha mencionado anteriormente, no es deseable hacer la migración en un único movimiento. Por lo tanto, durante un periodo de transición (que podría durar varios meses o años) el sistema de reservas se distribuye entre ordenador central, por ejemplo, sistemas TPF o MVS de International Business Corporation y plataforma abierta, por ejemplo, sistemas Unix o Linux. El sistema de reservas podría implementarse, por ejemplo, en una infraestructura de Amadeus. Sin embargo, la presente invención es aplicable a cualquier implementación de un sistema de reservas que trabaja a través de múltiples servidores con plataformas diferentes.
En el ejemplo de la migración desde ordenador central a plataforma abierta, en el ordenador central de TPF las aplicaciones de PNR comparten el mismo contexto de PNR en memoria y pueden acceder a los datos directamente a través de una API en modo lectura y/o escritura. Debido a la reingeniería de TPF y la migración de aplicaciones de PNR fuera del ordenador central de TPF, aparece el problema de compartición de contexto de PNR entre plataformas diferentes. De hecho, tenemos un concepto de un único sistema con contexto de usuario compartido a través plataformas heterogéneas que requieren aplicaciones distribuidas en plataformas diferentes para tener acceso a los mismos datos de PNR para garantizar la consistencia de acciones de funcionalidad de actividad realizadas a través de plataformas.
Un ejemplo con 2 aplicaciones, una dependiendo de la información de PNR proporcionado por la otra, se representa en el diagrama de la Figura 1. Muestra que ambos contextos de PNR locales tienen que sincronizarse para ser capaces de realizar las funcionalidades de actividad. Dos aplicaciones (App1 y App2) cooperan en un sistema de reservas: App1 (solo para hacer un ejemplo de una Aplicación de Reservas) se ejecuta en un sistema 101, mientras App2 (por ejemplo, una Aplicación de Precios) se ejecuta en un sistema 103. El sistema 101 de nuestro ejemplo es un ordenador central de TPF, mientras el sistema 103 es un sistema abierto, por ejemplo, un sistema Unix. Más
5
10
15
20
25
30
35
40
45
50
55
60
65
generalmente los dos sistemas 101 y 103 pueden ser cualquier sistema conocido en dos plataformas diferentes. Los dos sistemas 101 y 103 se conectan entre sí por medio de un Bus de Servicios de Empresa (ESB) 105 que también es accesible por un usuario a través de un terminal 107. La conexión entre el terminal 107 y el ESB 105 puede hacerse con cualquier disposición de red adecuada (por ejemplo, TCP/IP). También el ESB es un ejemplo de implementación, aunque podrían usarse otras estructuras conocidas en su lugar, por ejemplo, Encaminador, un Portal o un Mediador de Peticiones. Cada sistema 101 y 103 tiene acceso a un área de almacenamiento local (respectivamente 109 y 111) en la que se mantiene la información de PNR. La información de PNR local será la más actualizada para el sistema local, pero podría estar desactualizada con respecto al otro sistema. En la presente realización hemos usado un ejemplo con dos sistemas 101 y 103 trabajando en dos plataformas diferentes, pero los expertos en la materia apreciarán que otras implementaciones son posibles con varios sistemas diferentes. En el ejemplo de la Figura 1 el usuario, a través del terminal 107 y ESB 105 solicita (etapa 1) una reserva a la App1 que trabaja en una versión local de PNR 109; el PNR se actualiza (etapa 2) según la elaboración hecha por la App1. Cuando se pasa el control a la App2 (etapa 3) la aplicación trabaja (etapa 4) en la versión local del PNR 111. Antes de hacer eso es necesario verificar si el PNR local es la versión más actualizada (en el presente ejemplo no lo es), de lo contrario es necesaria una actualización. La App2 puede acceder a los sistemas externos 113 (por ejemplo, bases de datos de precios) para completar su elaboración (etapa 5).
En el método y sistema según una realización preferida de la presente invención, se replica una copia en memoria local del contexto de PNR en cada plataforma; las actualizaciones se realizan localmente y la sincronización se produce cuando otra plataforma necesita acceder a los datos de contexto actualizados. Esto es lo que llamamos sincronización de contexto distribuido. La complejidad del mecanismo de sincronización es determinar si una copia local está desactualizada o no y determinar dónde se ubican los datos de PNR más actualizados para cogerlos. Este mecanismo trabaja en todos los tipos de consultas de usuarios cualquiera que sea el protocolo de comunicación y no depende de las características técnicas de plataforma tal como representación de datos (por ejemplo, fila de datos pequeña o grande).
El presente enfoque a la sincronización de contexto de PNR responde a todos estos requisitos de una forma optimizada ya que la sincronización se realiza únicamente cuando se necesita y proporciona únicamente las actualizaciones a hacer en la copia de contexto local. Un elemento clave de la presente invención es un mecanismo para garantizar que el valor más actualizado de un parámetro compartido se usa en cualquier momento durante el proceso. En el método y sistema según una realización preferida de la presente invención se usa un dispositivo de correlación de contexto compartido distribuido. Como un ejemplo en el sistema de reservas de Amadeus descrito esto se llama DCX (Dispositivo de Correlación de Contexto Distribuido). DCX transmite información adicional encima de cada mensaje que viene desde la misma sesión de usuario, en todos los tipos de protocolos de comunicación para representar la distribución de los contextos aplicativos en las diferentes plataformas y aplicaciones.
Esta entidad de DCX se crea y almacena en el ESB y se transmite en todos los mensajes dentro de la infraestructura de Amadeus en el encabezamiento de sesión. La Figura 2 muestra un ejemplo de la estructura de DCX 200 según una realización preferida de la presente invención. Contiene referencias a contextos en las diferentes plataformas, que significa que no contiene los datos de contexto en sí. Se formatea en XML y compone de 3 partes como se muestra en la Figura 2: una reservada para información de contexto de ESB usada para encaminamiento y otros casos de uso (201), otra parte se dedica a seguridad y autenticación de usuario (203) y finalmente la tercera parte es la parte aplicativa (205) en la que la aplicación puede añadir sus preferencias de contexto e indicadores de estado asociados a las mismas. Es en la parte aplicativa que el proceso de Sincronización de Contexto almacena la información relacionada con los contextos de PNR distribuidos y es la base del mecanismo sin la que no funcionaría.
El DCX ofrece dos otras características requeridas para el mecanismo de sincronización que son la afinidad y la compartición de contexto entre diferentes protocolos de comunicación. La afinidad se requiere para dirigirse a exactamente el mismo servidor de aplicación cada vez que se invoca el mismo servicio y se necesita ya que los contextos de PNR son locales a los servidores de aplicación. Preferentemente, la información relacionada con la afinidad se comprende en claves, que pueden denominarse como "Claves de Afinidad", estando dichas claves comprendidas en el DCX. La compartición de información de contexto a través de protocolos se requiere para garantizar que un usuario que invoca los servicios de PNR en diferentes protocolos seguirá trabajando en el exacto mismo contexto de PNR.
La duración de la vida útil del contexto se controla mediante las conversaciones establecidas entre el ESB y el sistema abierto (o el ordenador central). El DCX ofrece una vista global de la actividad de usuario significando que si el usuario trabaja a través de una conversación específica (por ejemplo, conversación de EDIFACT), las otras conversaciones de protocolo se mantendrán para garantizar consistencia a través de protocolos. Cuando el usuario se desconecta desde el ESB (mediante un cierre específico de conversación o mediante una expiración por inactividad), las conversaciones a los sistemas abiertos y ordenador central también se cerrarán y desencadenará la limpieza de los contextos. Una descripción de DCX está también disponible en solicitudes pendientes por "METHOD AND SYSTEM FOR PROVIDING A SESSION INVOLVING A PLURALITY OF SOFTWARE APPLICATIONS" y "METHOD AND SYSTEM FOR PROVIDING A SESSION IN A HETEROGENEOUS ENVIRONMENT" presentadas por el mismo solicitante y que tienen la misma fecha de prioridad de la presente invención.
5
10
15
20
25
30
35
40
45
50
55
60
En los ejemplos de la descripción de la presente invención las conexiones entre servidores se realizan por medio de un ESB, sin embargo, los expertos en la materia apreciarán que podría usarse, en su lugar, cualquier otro medio de encaminamiento del estado de la técnica, capaz de encaminar una transacción a un servidor de aplicación apropiado, por ejemplo, un encaminador, un Portal o un Mediador de Peticiones.
El mecanismo de sincronización de contexto distribuido usa la parte aplicativa de la entidad de contexto compartido (DCX) para almacenar información acerca de los estados de contexto locales en las plataformas diferentes, también denominadas como máquinas o servidores de aplicación. Cada plataforma necesita referenciar su contexto local y actualizar el estado en cada transacción que implica un cambio en el contexto. Los datos relacionados con los contextos se estructuran de la siguiente forma:
<Application = SBR>
<Platform, Context Versión, Context Key, Context State> </Application>
Todas las plataformas implicadas en la sincronización de contexto de PNR distribuida tendrán sus claves de contexto almacenadas en el DCX en el mismo tipo de aplicación (en este punto llamada "SBR").
El campo "Platform" corresponde al acrónimo de tres letras comúnmente usado para diseñar un sistema tal como TPF o sistema abierto RES.
El campo "Context Version" corresponde a la versión del contexto presente en la plataforma asociada, esto es un número que se aumenta cada vez que se modifica el contexto.
El campo "Context Key", también se denomina como Clave de Contexto Aplicativa, que corresponde al identificativo único que permite la recuperación del contexto en la plataforma asociada.
El campo "Context State" corresponde al estado del contexto en la plataforma asociada. El estado de contexto puede representar el hecho de que el contexto está activo, inactivo, corrompido y si fue el último contexto actualizado.
Un ejemplo de claves de aplicación en DCX, después de 1 caso de uso procesado en TPF y a continuación 1 caso de uso procesado en RES OBE (EXTREMO POSTERIOR ABIERTO) podría ser:
<Application = SBR>
<TPF, 1, Keyl, ACT>
<RES, 1, Key2, ACT/Last>
</Application>
Las versiones de los contextos locales es la clave para implementar un mecanismo de sincronización vago (se realiza únicamente cuando se requiere) como se verá en el siguiente capítulo acerca del algoritmo. El indicador de "Último Actualizador" es también la clave para determinar qué plataforma tiene el último contexto, de modo que la sincronización se hace con esta plataforma.
Además del estado actual de los contextos de PNR distribuidos que se transmiten dentro de la entidad de DCX en todos los mensajes, cada plataforma tiene un estado de sincronización local almacenado asociado a su contexto. Este estado de sincronización local representa el estado de los contextos de PNR distribuidos en las otras plataformas en el momento de la última sincronización realizada. Permite determinar si un contexto local está desactualizado en comparación con las otras plataformas, que es la condición desencadenante para la sincronización. De hecho, si se han hecho varias actualizaciones sucesivas en un contexto preciso, la sincronización no se realizará cada vez, ya que el contexto local estará actualizado en comparación con otros contextos de plataforma.
La estructura de datos descrita anteriormente es una de las alternativas posibles, sin embargo pueden realizarse otras implementaciones para garantizar la consistencia de las diferentes instancias del mismo parámetro compartido. El requisito de tal estructura de datos es que información acerca de la ubicación de la versión más actualizada de PNR puede compartirse entre todas las aplicaciones a través de todas las plataformas usadas por el sistema.
Como se muestra en las Figuras 3, los flujos globales de modificaciones hechas en las claves aplicativas en el contexto compartido (DCX en el ejemplo actual) para la parte de sincronización se explican tomando el ejemplo de 2 plataformas llamadas Sistemal y Sistema2 (por ejemplo, una ejecutándose en un ordenador central y una en Sistema Abierto). En el diagrama de la Figura 3 se describe el procesamiento de casos de uso en plataformas diferentes con el cambio asociado de valores en el contexto compartido. El estado actual transmitido en el contexto compartido y los estados de sincronización local de las diferentes plataformas se representan en el diagrama para mostrar la diferencia entre los mismos.
5
10
15
20
25
30
35
40
45
50
55
60
65
En una primera etapa (etapa 1 en la Figura 3), el propio usuario iniciará sesión en el sistema a través del ESB; en esta fase se creará un contexto compartido vacío para esta sesión y almacenará en el ESB (etapa 2).
A continuación, el usuario empieza a trabajar, enviando una consulta de actividad que se manejará por un servicio ubicado en el Sistema1 (etapa 3). El ESB transmitirá automáticamente el contexto compartido con la consulta de usuario al Sistema! Ya que el Sistema1 no encuentra información de sincronización ni localmente ni en el contexto compartido, procesa directamente la consulta de usuario recibida (etapa 4). En caso de que un contexto de reserva se ha creado mediante el procesamiento de la consulta, los datos de sincronización locales se actualizan con el nuevo estado que es que el Sistema1 tiene un contexto de reserva en la versión 1 y fue el último actualizador para la misma (etapa 5). La respuesta de actividad se envía de vuelta al usuario, junto con el contexto compartido actualizado con datos de sincronización; el contexto compartido se almacena en el ESB antes de reenviar la respuesta al usuario de modo que puede usarse en las siguientes consultas realizadas por el usuario (etapa 6). El usuario envía después otra consulta de actividad que se manejará por un servicio ubicado en el Sistema2 (etapa 7). El ESB transmitirá automáticamente el contexto compartido con la consulta de usuario al Sistema2. En el Sistema2 no hay estado de sincronización local almacenado y una comparación con los datos de sincronización presentes en el contexto compartido recibido con la consulta muestra que se requiere sincronización con el Sistema1 ya que mantiene un nuevo contexto de reservas (etapa 8). Así que el Sistema2 preguntará al Sistema1 su contexto de reservas (etapa 9) para almacenar el mismo localmente y permitir el procesamiento de la consulta de usuario (etapa 10). Junto con el almacenamiento del contexto de reserva, el estado de sincronización local se inicializa con las diferentes claves aplicativas que representan la situación. A continuación, tiene lugar el procesamiento de la consulta (etapa 11); una vez que se completa, en el caso de que el contexto de reservas se ha actualizado, la sincronización local se actualiza para representar ese hecho de que el Sistema2 es ahora el último actualizador de la información de reserva y que su contexto ahora tiene la versión 1 (etapa 12). La respuesta de actividad se envía de vuelta al usuario, junto con el contexto compartido actualizado con datos de sincronización; el contexto compartido se almacena en el ESB antes de reenviar la respuesta al usuario de modo que puede usarse en las siguientes consultas realizadas por el usuario (etapa 13).
Puede continuar con la misma secuencia de acción con posteriores consultas del usuario, dirigiéndose o bien al Sistema1 o bien Sistema2 indiferentemente. Dependiendo de la comparación del estado de sincronización local y el contexto compartido, el sistema determinará si se requiere sincronización o no.
En la plataforma de Sistema1, por ejemplo, cuando se llama a un servicio que usa el contexto de reservas (por ejemplo, PNR) en modo lectura o escritura, se aplicará el siguiente algoritmo para determinar si se requiere o no la sincronización con otro sistema:
0- Recibir la petición
1- Conseguir Claves de Aplicación en contexto compartido actual recibido en la petición de usuario (por ejemplo,
Sistema1 v1 / Sistema2 v2 Última)
2- Conseguir estado de sincronización previo almacenado localmente (por ejemplo, Sistema1 v1 / Sistema2 v1
Última)
3- Ejecutar comprobación de consistencia:
3a- ¿Es la versión de Sistema1 actual la misma que la previa almacenada localmente? ¿Es la clave la misma? (OK si SÍ)
3b- ¿Es la versión de Sistema2 actual mayor o igual que la previa almacenada localmente? (OK si SÍ)
4- Ejecutar comprobación de sincronización: ¿es la versión de Sistema2 actual mayor que la almacenada
localmente y está presente bandera de "último actualizador"? (Se necesita sincronización si SÍ)
5- Si se necesita sincronización
5a- Ejecutar la sincronización (CONSEGUIR el contexto de la plataforma del Sistema2)
5b- Si satisfactoria, Sistema1 actualiza el estado de sincronización previo almacenado localmente con valores: Sistema1 v1 / Sistema2 v2 (significa que ahora en el Sistema1 el contexto está sincronizado con el Sistema2 v2)
6- Procesar consulta de actividad en el Sistema1
7- Actualizar la versión de Sistema1 si modificaciones hechas en el contexto de reservas (PNR)
7a- Actualizar la versión del Sistema1 en contexto compartido actual (Sistema1 v2 Última / Sistema2 v2). Este contexto compartido se enviará de vuelta al ESB para mantener el mismo para siguientes consultas de usuario
7b- Actualizar la versión del Sistema1 en estado de sincronización previo almacenado localmente con valores: Sistema1 v2 / Sistema2 v2
8- Contestar
5
10
15
20
25
30
35
40
45
50
55
60
65
Se puede ver en este algoritmo que se necesitan comparar 2 conjuntos de claves de contexto para ser capaces de determinar qué tiene que hacerse desde un punto de vista de sincronización. La bandera de "último actualizador" se requiere cuando más de 2 plataformas tienen contextos de PNR, para determinar la que tiene la última versión del contexto. Para 2 plataformas, el mecanismo podría funcionar sin la misma.
Una ventaja adicional de este mecanismo es que se pueden detectar errores de transmisión de contexto compartido en la siguiente fase de sincronización. De hecho, gracias a las comprobaciones de consistencia y la información de sincronización localmente almacenada, es posible determinar si se ha producido un error. El hecho de que la versión de la plataforma local no coincide o las claves de contexto son diferentes, muestran una corrupción del contenido de contexto compartido y esto es probable que sea la consecuencia de un error. El manejo del error puede ser bastante complejo debido a comunicaciones e intercambios colaterales, por lo que no se detallará en este documento, pero los expertos en la materia apreciarán que pueden usarse varios métodos de estado de la técnica para implementar esta tarea.
Con referencia a la Figura 4 un ordenador genérico del sistema (por ejemplo, cualquier ordenador, servidor de reservas, ordenador central de TPF, servidor de Sistema Abierto, subsistema de gestión de base de datos, encaminador, servidor de red) se indica con 450. El ordenador 450 se forma por varias unidades que se conectan en paralelo a un bus de sistema 453. En detalle, uno o más microprocesadores 456 controlan la operación del ordenador 450; una RAM 459 se usa directamente como una memoria de trabajo por los microprocesadores 456 y una ROM 462 almacena código básico para una rutina de arranque del ordenador 450. Unidades periféricas se agrupan alrededor de un bus local 465 (por medio de respectivas interfaces). Particularmente, una memoria de masa que consiste en un disco duro 468 y una unidad 471 para leer el CD-ROM 474. Además, el ordenador 450 incluye dispositivos de entrada 477 (por ejemplo, un teclado y un ratón) y dispositivos de salida 480 (por ejemplo, un monitor y una impresora). Se usa una Tarjeta de Interfaz de Red 483 para conectar el ordenador 450 a la red. Una unidad de puente 486 interconecta el bus de sistema 453 con el bus local 465. Cada microprocesador 456 y la unidad de puente 486 pueden operar como agentes maestros que solicitan un acceso al bus de sistema 453 para transmitir información. Un árbitro 489 gestiona la concesión del acceso con exclusión mutua al bus de sistema 453. Se aplican consideraciones similares si el sistema tiene una topología diferente o se basa en otras redes. Como alternativa, los ordenadores tienen una estructura diferente, incluyen unidades equivalentes o constan de otras entidades de procesamiento de datos (tal como PDA, teléfonos móviles y similares).
Los servicios de EDIFACT que se usan en el mecanismo de sincronización de contexto de PNR y que transportan los datos de PNR se componen de la siguiente información:
- El estado de sincronización local de la plataforma que solicita o proporciona los datos de contexto de PNR. Esta
información se requiere para determinar el número de transacciones de usuario que tienen que retirarse u
aplicarse en el contexto local. También permite optimizaciones para reducir la cantidad de datos intercambiados entre las plataformas.
- El contexto de PNR serializado, que puede estar completo en caso de la primera sincronización o puede
componerse de actualizaciones de contexto cuando la plataforma que solicita la última versión del contexto ya tiene una copia local de contexto. El contexto serializado es una PASBCQ que es en sí mismo un mensaje EDI.
El hecho de que el contexto se serializa en un mensaje EDI permite deshacerse de las particularidades de representación de datos de la plataforma que proporciona el mismo. De hecho, el contenido de datos se normaliza y es independiente de la representación de datos de plataforma.
La Sincronización de Contexto Distribuido se basa en 5 diferentes servicios que puede cualquiera implementarse en ambas plataformas TPF y OBE o ser específicos a una plataforma maestra/esclava. Cada servicio transmitirá el DCX junto con el mensaje, especialmente porque el DCX permitirá que las comprobaciones de consistencia se ejecuten en el estado de la sincronización de contexto. Cada servicio se describe en este punto con referencia a una estructura de EDIFACT (solicitud y respuesta) y un diagrama de caso de uso para mostrar datos intercambiados.
CONSEGUIR contexto: PCSGRQ/R
Este servicio, como se muestra en las Figuras 5a y 5b se usa para recuperar de una plataforma remota la última versión de su contexto. Debería implementarse en todas las plataformas en las que pueda leerse el contexto.
Datos intercambiados
En la consulta, el cliente debería proporcionar su estado de sincronización. Se compone de una lista de 3 valores <Platform, Context Key, Version>.
En la respuesta, el servidor debería proporcionar su estado de sincronización asociado con el contexto serializado con sus versiones. Ya que pueden encontrarse errores, la respuesta debería contener un grupo de errores que describen el problema.
5
10
15
20
25
30
35
40
45
50
55
60
65
Versiones de serialización de CONSEGUIR contexto PCSVRQ/R
Este servicio, mostrado en las Figuras 6a y 6b se usa para recuperar todas las versiones relacionadas con la serialización del contexto. Este servicio debería implementarse en OBE. En OBE, el contexto se basa en un Modelo de SBR, que se serializa en un mensaje EDIFACT llamado PASBCQ. El PASBCQ se compone de varios objetos binarios grandes que tienen una versión asociada. Ya que TPF es el maestro de las versiones de PASBCQ, el OBE tiene que recuperar las versiones actuales de serialización de TPF cuando no las conoce aún, para poder escribir un mensaje consistente. Esta situación se produce cuando sistemas externos están solicitando actualizaciones no solicitadas directamente en OBE.
Datos intercambiados
En la consulta, el cliente no debería necesitar proporcionar ningún dato.
En la respuesta, el servidor debería proporcionar sus versiones usadas para serializar el mensaje PASBCQ EDIFACT. Debería componerse de un objeto binario grande que contiene todas las versiones usadas para serializar, junto con la versión de objeto binario grande. Ya que pueden encontrarse errores, la respuesta debería contener un grupo de errores que describen el problema.
IMPULSAR contexto: PCSPUQ/R
Este servicio (véase la Figura 7a y 7b) se usa para impulsar la última versión del contexto local a una plataforma remota para actualizar el contexto en la última. Debería implementarse en plataformas que no son maestras del contexto. Este servicio es una optimización del mecanismo de sincronización para tener el maestro de contexto actualizado. En este caso, el maestro no usaría el servicio de CONSEGUIR Contexto. Ya que en TPF las llamadas de cliente son costosas, esto podría ayudar a reducir el consumo de recursos en la misma.
Datos intercambiados
En la consulta, el cliente debería proporcionar su estado sincronizado asociado con el contexto serializado con sus versiones.
En la respuesta, el servidor debería proporcionar únicamente un acuse de recibo. Ya que pueden encontrarse errores, la respuesta debería contener un grupo de errores que describen el problema.
IMPULSAR y EOT contexto: PCSEUQ/R
Este servicio (Figura 8a y 8b) se usa para impulsar la última versión del contexto local a una plataforma remota para actualizar el contexto en la última y llamar al proceso de Fin de Transacción en este contexto. Debería implementarse en todas las plataformas que requieren actualizar el contexto de PNR y llamar al proceso Fin de Transacción en estas modificaciones. Este servicio se requiere para gestionar entradas de procesamiento tales como Petición de Impresión de Billete (TTP) o Acuse de Recibo de Billete procedente de un sistema externo.
Datos intercambiados
En la consulta, el cliente debería proporcionar su estado sincronizado asociado con el contexto serializado con sus versiones.
En la respuesta, el servidor debería proporcionar únicamente un acuse de recibo. Ya que pueden encontrarse errores, la respuesta debería contener un grupo de errores que describen el problema.
IGNORAR propagación de contexto: PCSINQ/R
Este servicio se usa para ignorar todas las modificaciones que se han hecho en un SBR a través de las diferentes plataformas implicadas en los flujos. TPF recibirá la entrada "IG" y a continuación propagará la consulta a las OBE que tienen un contexto de SBR registrado en el DCX, de modo que pueden limpiar sus contextos. Se muestra en las Figuras 9a y 9b.
Datos intercambiados
En la consulta, el cliente no debería necesitar proporcionar ningún dato.
En la respuesta, el servidor debería proporcionar únicamente un acuse de recibo. Ya que pueden encontrarse errores, la respuesta debería contener un grupo de errores que describen el problema. El método descrito anteriormente también se representa en el diagrama mostrado en la Figura 10. El método realiza un mecanismo de sincronización, en un método de reservas que opera en un sistema de múltiples servidores, para garantizar que se
5
10
15
20
25
30
35
40
45
usa el registro de PNR más actualizado durante una transacción de usuario a través de al menos dos servidores del sistema de múltiples servidores, en el que se mantiene una versión de contexto local del PNR dentro de cada servidor del sistema de múltiples servidores, estando los servidores interconectados a través de un bus de sistema. El método comienza en el círculo negro 1001 y a continuación va a la caja 1003 en la que se mantiene la versión más actualizada de PNR en un área de almacenamiento accesible por todos los servidores implicados en la transacción. El sistema de reservas de múltiples servidores recibe una petición de usuario que necesita una acción de actualización del PNR (etapa 1005) por ejemplo en un servidor "A". El bus de sistema (por ejemplo, el ESB, pero más generalmente cualquier medio de encaminamiento) determina y selecciona qué servidor necesita implicarse para procesar la petición. En las etapas 1007 y 1009 el servidor seleccionado comprueba si el PNR de contexto local es el más actualizado comparando el PNR de contexto local con la información disponible en el PNR de contexto compartido en el ESB: si el PNR de contexto local no es el más actualizado (es decir otro servidor ha modificado el PNR desde la última actualización por el servidor seleccionado (si hay alguno)) el servidor seleccionado obtiene la versión más actualizada de PNR (etapa 1011). A continuación, el servidor seleccionado realiza la actividad solicitada y modifica el PNR de contexto local (etapa 1013) que también se convierte en la versión más actualizada: tal información se pasa a continuación (etapa 1015) al PNR de contexto compartido en ESB para que se haga accesible a todos los otros servidores del sistema de múltiples servidores. Los detalles de la forma en que se transmiten la información entre los servidores, el ESB y el usuario se ha analizado en los párrafos anteriores.
Se apreciará que pueden hacerse alteraciones y modificaciones a lo anterior sin alejarse del alcance de la divulgación. Naturalmente, para satisfacer requisitos locales y específicos, un experto en la materia puede aplicar a la solución descrita anteriormente muchas modificaciones y alteraciones. Particularmente, aunque la presente divulgación se ha descrito con un cierto grado de particularidad con referencia a realización o realizaciones preferidas de la misma, debería entenderse que son posibles diversas omisiones, sustituciones y cambios en la forma y detalles así como otras realizaciones; además, se concibe expresamente que elementos específicos y/o etapas de método descritas en conexión con cualquier realización divulgada de la divulgación pueden incorporarse en cualquier otra realización como una cuestión general de elección de diseño.
Se aplican consideraciones similares si el programa (que puede usarse para implementar cada realización de la divulgación) se estructura de una forma diferente, o si se proporcionan módulos o funciones adicionales; análogamente, las estructuras de memoria pueden ser de otros tipos o pueden sustituirse con entidades equivalentes (no necesariamente consistentes de medio de almacenamiento físico). Además, la solución propuesta se presta para implementarse con un método equivalente (teniendo etapas similares o adicionales, incluso en un orden diferente). En cualquier caso, el programa puede tener cualquier forma adecuada para usarse mediante o en conexión con cualquier sistema de procesamiento de datos, tal como software externo o residente, firmware o microcódigo (ya sea en código objeto o en código fuente). Además, el programa puede proporcionarse en cualquier medio usable por ordenador; el medio puede ser cualquier elemento adecuado para contener, almacenar, comunicar, propagar o transferir el programa. Ejemplos de tal medio son discos fijos (en los que el programa puede precargarse), discos extraíbles, cintas, tarjetas, alambres, fibras, conexiones inalámbricas, redes, ondas de radiodifusión y similares; por ejemplo, el medio puede ser del tipo electrónico, magnético, óptico, electromagnético, infrarrojos o semiconductor.
En cualquier caso, la solución según la presente divulgación se presta a ser efectuado con una estructura de hardware (por ejemplo, integrada en un chip de material semiconductor) o con una combinación de software y hardware.

Claims (9)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    REIVINDICACIONES
    1. Un método de sincronización, en una aplicación de reservas que opera en un sistema de múltiples servidores, intercambiando la aplicación de reservas (101) información relacionada con viajes por medio de una estructura de datos de Registro de Nombres de Pasajeros (PNR), para garantizar que se usa el PNR más actualizado durante una transacción de usuario a través de al menos dos servidores del sistema de múltiples servidores, en el que una versión de contexto local del PNR se mantiene dentro de cada servidor del sistema de múltiples servidores, estando los servidores interconectados a través de un medio de encaminamiento, incluyendo el método las etapas de:
    - mantenimiento en un área de almacenamiento de contexto compartido (1003), accesible por todos los servidores del sistema de múltiples servidores, de información acerca de la ubicación de la última versión modificada de PNR;
    - en respuesta a una petición de usuario que provoca que uno de los servidores seleccionado modifique la versión de contexto local de PNR realizando las siguientes acciones:
    - comprobar en el área de almacenamiento de contexto compartido qué servidor modificó por última vez el PNR;
    - si el servidor que modificó por última vez el PNR es diferente del servidor seleccionado, obtener la versión más actualizada de PNR;
    - modificar la versión de contexto local de PNR para satisfacer la petición de usuario;
    - actualizar el área de almacenamiento de contexto compartido para reflejar la última versión modificada de PNR.
  2. 2. El método de sincronización de la reivindicación 1 en el que los servidores del sistema de múltiples servidores intercambian información con el medio de encaminamiento y el usuario por medio de un sistema de Arquitectura Orientada al Cliente (SOA).
  3. 3. El método de sincronización de la reivindicación 2 en el que los mensajes incluyen un encabezamiento de mensaje que comprende información acerca de la última versión modificada de PNR.
  4. 4. El método de sincronización de cualquier reivindicación anterior en el que información acerca de la última versión modificada de PNR incluye un puntero a la última versión modificada de PNR.
  5. 5. El método de sincronización de cualquier reivindicación anterior en el que el medio de encaminamiento incluye un bus de sistema, por ejemplo, un Bus de Servicios de Empresa (ESB).
  6. 6. Un programa informático que comprende instrucciones para efectuar las etapas del método según una cualquiera reivindicación anterior, cuando dicho programa informático se ejecuta en un ordenador.
  7. 7. Un producto de programa informático que incluye medios legibles por ordenador que incorpora el programa informático de la reivindicación 6.
  8. 8. Un sistema de procesamiento de datos de multiples servidores de reservas, incluyendo un método de sincronización para garantizar que se usa el registro de PNR más actualizado durante una transacción de usuario a través de al menos dos servidores del sistema de múltiples servidores, en el que una versión de contexto local del PNR se mantiene (1003) dentro de cada servidor del sistema de múltiples servidores, estando los servidores interconectados a través de un medio de encaminamiento, en el que el sistema comprende uno o más componentes adaptados para realizar el método de cualquier reivindicación 1 a 5.
  9. 9. Un sistema desplegado en un sistema de procesamiento de datos para implementar el método de cualquier reivindicación 1 a 5.
ES11305278.1T 2011-03-15 2011-03-15 Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores Active ES2689112T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP11305278.1A EP2500832B1 (en) 2011-03-15 2011-03-15 Method and system for synchronization mechanism on multi-server reservation system

Publications (1)

Publication Number Publication Date
ES2689112T3 true ES2689112T3 (es) 2018-11-08

Family

ID=44170328

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11305278.1T Active ES2689112T3 (es) 2011-03-15 2011-03-15 Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores

Country Status (12)

Country Link
US (1) US20120239620A1 (es)
EP (1) EP2500832B1 (es)
JP (1) JP5841177B2 (es)
KR (1) KR101863398B1 (es)
CN (1) CN103443790A (es)
AU (1) AU2012228693B2 (es)
BR (1) BR112013021987A2 (es)
CA (1) CA2827244A1 (es)
ES (1) ES2689112T3 (es)
SG (1) SG192783A1 (es)
WO (1) WO2012123136A1 (es)
ZA (1) ZA201306241B (es)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2309389A1 (en) * 2009-10-09 2011-04-13 Amadeus s.a.s Delivery with reconciliation on client side
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
JP5649505B2 (ja) * 2011-04-19 2015-01-07 株式会社東芝 同期制御システム
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
US9235620B2 (en) 2012-08-14 2016-01-12 Amadeus S.A.S. Updating cached database query results
US9088559B2 (en) * 2012-09-11 2015-07-21 Tencent Technology (Shenzhen) Company Limited System and method for sharing login status between an application platform and an application
CN103685193B (zh) * 2012-09-20 2018-01-30 腾讯科技（深圳）有限公司 一种第三方应用接入开放平台的方法及开放平台接入系统
US8635373B1 (en) * 2012-09-22 2014-01-21 Nest Labs, Inc. Subscription-Notification mechanisms for synchronization of distributed states
US9367563B2 (en) 2014-05-30 2016-06-14 Amadeus S.A.S. Managing records in a travel management system
US10049329B2 (en) 2014-05-30 2018-08-14 Amadeus S.A.S. Content exchange with a travel management system
US9619568B2 (en) 2014-05-30 2017-04-11 Amadeus S.A.S. Content access in a travel management system
US10042871B2 (en) 2014-05-30 2018-08-07 Amadeaus S.A.S. Content management in a travel management system
KR101634571B1 (ko) * 2014-07-31 2016-07-08 주식회사 파수닷컴 문서 동기화 방법 및 컴퓨터 프로그램, 그 기록매체
US10055695B2 (en) * 2014-10-20 2018-08-21 Solution Technology Incorporated Throttling solutions into a legacy inventory system during a service disruption
CN104331501A (zh) * 2014-11-19 2015-02-04 广东花生信息科技有限公司 一种多平台的数据更新方法
US10091086B2 (en) * 2015-04-03 2018-10-02 Oracle International Corporation System and method for providing an application programming interface manager for use with a service bus runtime
US9977700B2 (en) 2015-04-03 2018-05-22 Oracle International Corporation System and method for providing an application programming interface for deploying a service bus artifact from a local development environment to a cloud environment
US9652269B2 (en) 2015-04-03 2017-05-16 Oracle International Corporation System and method for supporting representational state transfer services natively in a service bus runtime
US10313451B2 (en) 2015-04-03 2019-06-04 Oracle International Corporation System and method for providing a configuration wizard for use in creating representational state transfer services for execution in a service bus runtime
US10063376B2 (en) 2015-10-01 2018-08-28 International Business Machines Corporation Access control and security for synchronous input/output links
US10120818B2 (en) 2015-10-01 2018-11-06 International Business Machines Corporation Synchronous input/output command
US10068000B2 (en) * 2015-10-01 2018-09-04 International Business Machines Corporation Synchronous input/output replication of data in a persistent storage control unit
CN109788017B (zh) * 2017-11-15 2022-12-06 中国移动通信集团终端有限公司 跨品牌儿童手表信息同步方法、装置、设备及介质
CN109474616B (zh) * 2018-12-17 2021-06-25 秒针信息技术有限公司 多平台数据共享方法和装置及计算机可读存储介质
CN109783502B (zh) * 2018-12-28 2021-03-23 汉海信息技术(上海)有限公司 支持多端登录的结算方法、装置、系统及服务器
FR3099619A1 (fr) 2019-07-30 2021-02-05 Amadeus Dispositif, système et procédé pour la synchronisation, basée sur un mode, d’enregistrements de données
FR3102587B1 (fr) * 2019-10-24 2023-04-07 Amadeus Sas Système, procédé et appareil pour la corrélation d’objets de données
CN113627840A (zh) * 2021-07-08 2021-11-09 支付宝(杭州)信息技术有限公司 一种多平台场馆库存信息处理方法、装置以及设备

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0218635A (ja) * 1988-07-06 1990-01-22 Nec Software Ltd 分散処理ファイル管理方式
DE69031164T2 (de) * 1989-09-14 1998-01-02 Fujitsu Ltd Zeitlich begrenztes zentrumsystem für dezentralisiertes datenbanksystem
US6392997B1 (en) * 1999-03-16 2002-05-21 Cisco Technology, Inc. Technique for group-based routing update with limited per neighbor/adjacency customization
WO2000063808A1 (en) * 1999-04-16 2000-10-26 Cg & G Software Plus Tee time reservation system
US8209200B2 (en) * 2002-03-13 2012-06-26 Orbitz Llc System and method for synchronizing passenger name record data
US20030220966A1 (en) * 2002-05-24 2003-11-27 International Business Machines Corporation System and method for dynamic content dependent conflict resolution
US7213026B2 (en) * 2002-08-23 2007-05-01 Sun Microsystems, Inc. Apparatus and method for associating classes
US7395279B2 (en) * 2003-11-17 2008-07-01 International Business Machines Corporation System and method for achieving different levels of data consistency
JP4452533B2 (ja) * 2004-03-19 2010-04-21 株式会社日立製作所 システムおよび記憶装置システム
US7778962B2 (en) * 2004-04-30 2010-08-17 Microsoft Corporation Client store synchronization through intermediary store change packets
US7925624B2 (en) * 2006-03-31 2011-04-12 Amazon Technologies, Inc. System and method for providing high availability data
US8510404B2 (en) * 2006-04-03 2013-08-13 Kinglite Holdings Inc. Peer to peer Synchronization system and method
US8112550B2 (en) * 2006-09-19 2012-02-07 Tacoda Llc System and method for preserving consumer choice
JP4504969B2 (ja) * 2006-12-18 2010-07-14 みずほ情報総研株式会社 データ更新処理装置、データ更新処理方法及びデータ更新処理プログラム
US7809593B2 (en) * 2007-05-16 2010-10-05 Amadeus S.A.S. Method and system for automatically keeping travel data consistent between passenger reservation records and corresponding electronic tickets
KR100813013B1 (ko) * 2007-05-29 2008-03-13 주식회사 비투엔컨설팅 오디엑스 데이타를 이용한 트랜잭션 처리 소프트웨어프레임 웍
US8185916B2 (en) * 2007-06-28 2012-05-22 Oracle International Corporation System and method for integrating a business process management system with an enterprise service bus
JP4561800B2 (ja) * 2007-09-25 2010-10-13 沖電気工業株式会社 データ同期システム及び方法
US8055775B2 (en) * 2009-03-25 2011-11-08 International Business Machines Corporation SOA policy engine framework
US8423973B2 (en) * 2009-05-08 2013-04-16 Ca, Inc. Instrumenting an application with flexible tracers to provide correlation data and metrics
US20100312586A1 (en) * 2009-06-03 2010-12-09 Drefs Martin J Generation of Travel-Related Offerings
EP2282287A1 (en) * 2009-07-28 2011-02-09 Amadeus S.A.S. Method to keep coherent a travel shopping basket

Also Published As

Publication number Publication date
ZA201306241B (en) 2014-05-28
AU2012228693A1 (en) 2013-04-18
EP2500832A1 (en) 2012-09-19
BR112013021987A2 (pt) 2016-11-16
JP2014522513A (ja) 2014-09-04
EP2500832B1 (en) 2018-07-25
SG192783A1 (en) 2013-09-30
CN103443790A (zh) 2013-12-11
KR20140047580A (ko) 2014-04-22
AU2012228693B2 (en) 2014-11-06
JP5841177B2 (ja) 2016-01-13
CA2827244A1 (en) 2012-09-20
WO2012123136A1 (en) 2012-09-20
US20120239620A1 (en) 2012-09-20
KR101863398B1 (ko) 2018-05-31

Similar Documents

Publication Publication Date Title
ES2689112T3 (es) Método y sistema para mecanismo de sincronización en sistema de reservas de múltiples servidores
CN103403742B (zh) 用于多服务器预订系统上的集中预订上下文管理的方法和系统
US9069626B2 (en) Trusted client-centric application architecture
US20050165883A1 (en) Symbiotic computing system and method of operation therefor
WO2005034213A2 (en) System and method for providing record synchronization in a healthcare setting
US8380787B2 (en) Federation of master data management systems
JP2015505096A (ja) 分散型アプリケーション・オブジェクトに関するアップデート通知の提供
TW201229795A (en) Web service patterns for globally distributed service fabric
CN108027828A (zh) 与无状态同步节点的托管文件同步
US11627122B2 (en) Inter-system linking method and node
US11799839B2 (en) Cross-regional replication of keys
US8527995B2 (en) Synchronization system for entities maintained by multiple applications
Naab et al. Why data needs more attention in architecture design-experiences from prototyping a large-scale mobile app ecosystem
US20120254104A1 (en) Maintaining client data integrity in a distributed environment using asynchronous data submission
BRPI0808068A2 (pt) Módulo de personalização remoto e sistema compreendendo o referido módulo
Pardo-Castellote Data-Centric Programming Best Practices: Using DDS to Integrate Real-World Systems
Bravo et al. UniStore: A fault-tolerant marriage of causal and strong consistency (extended version)
Arun A Low-latency Consensus Algorithm for Geographically Distributed Systems
Schnoll Microsoft Exchange Server 2003 Distilled
Zeghache et al. Reliable mobile agents with transactional behaviour
WO2015059650A1 (en) Detachable functionality