Connect OTA se compone de un conjunto de servicios web que facilitan la conectividad entre los productos de gestión y distribución de reservas, y los portales de reservas de la Federación.
Para la implementación de este módulo de software se utiliza METRO, un proyecto Open Source. Quienes deseen saber que es y para que sirve, pueden consultar este enlace.
El módulo Connect OTA contiene, en su versión inicial, dos servicios web (y un cliente) que cubren las necesidades básicas de conectividad XML para el portal de reservas de la Federación.
En algunos servicios se sigue una de las normas OTA (2010A), mientras que en otros no.
Es un servicio web que permite a otros fabricantes de software conectar sus sistemas con la base de datos del portal de reservas de la Federación, para actualizar la disponibilidad, precios e inventario publicados.
Es un servicio web que se utiliza para comprobar la disponibilidad publicada en un establecimiento hotelero entre dos fechas.
Esta API define el servicio web que otros fabricantes de software necesitan implementar para recibir las notificaciones de las reservas cuando estas se producen en el portal de la Federación.
El servicio web de esta API no tiene una verdadera implementación tras él; su propósito es definir formalmente la API para intercambiar datos. Responde siempre con un aviso que informa de esta circunstancia.
El portal de reservas de la Federación usa un cliente del servicio web descrito para enviar la información relativa a las reservas, cuando estas se producen.
Para usar los servicios web es necesario realizar un proceso de registro y certificación, que garantiza que ambos sistemas intercambian información con el mismo significado en ambos extremos. Este proceso comienza en modo test, o de pruebas.
Básicamente, el proceso consiste en:
Crear un entorno de pruebas que envía la información a un establecimiento especialmente creado para este propósito, sin visibilidad en el portal de reservas.
Facilitar unas credenciales para el fabricante de software, que le identifican en todas las operaciones del entorno de pruebas (usuario y contraseña).
Crear un mapa de correspondencias para el establecimiento de pruebas, que incluye el código de establecimiento, códigos de habitación y códigos de tarifas de precios.
Facilitar unas credenciales para el establecimiento hotelero que autorizan los cambios o consultas en ese establecimiento, en el entorno de pruebas (contraseña para el establecimiento).
Intercambiar mensajes usando el entorno de pruebas hasta comprobar que las peticiones y respuestas funcionan como se espera en ambos extremos.
Una vez que concluye el proceso, el fabricante de software posee la capacidad de comunicarse correctamente con el portal de reservas de la Federación, y se le permite publicar, consultar y/o recibir notificaciones sobre las reservas, en función de los servicios que tenga implementados.
Observe que se facilita un doble juego de credenciales: el primero autentifica el origen de los mensajes, mientras el segundo autoriza la tarea solicitada en cada mensaje.
Una vez que ambos sistemas están conectados en modo test, y superadas las pruebas que verifican la validez de la conexión, se procede de igual modo para conectar en modo producción.
Esta vez, los cambios serán visibles en el portal de reservas, y la lógica de la conexión ya habrá quedado establecida correctamente, por lo que la única cuestión en la que centrarse será la seguridad.
En el modo producción, la autenticación se realiza utilizando certificados SSL expedidos por nuestra Autoridad Certificadora Privada, en lugar de la contraseña y usuario del entorno de pruebas. Además, se utilizan otros recursos que ofrece METRO para aumentar la fiabilidad de los servicios, como son Secure Conversation y Reliable Messaging. Ambos recursos añaden mensajes de control que se intercambian entre el emisor y el receptor durante el uso del servicio.
Todos los mensajes se intercambiarán cifrados y firmados usando el certificado SSL. El proceso, de forma muy resumida (sin tener en cuenta los mensajes de control; Secure Conversation altera ligeramente este proceso), sería el siguiente:
El emisor del mensaje lo firma usando su clave privada; de este modo, su identidad queda establecida en el mismo mensaje.
A continuación, el emisor encripta el mensaje utilizando la clave pública del receptor, antes de proceder al envío. De este modo se garantiza que sólo el legítimo receptor puede examinar el contenido del mensaje.
Cuando el receptor recibe el mensaje, utiliza su propia clave privada para descifrarlo, y comprueba si la autoridad que emitió el certificado utilizado para firmar es de confianza.
Si se confía en el emisor del certificado, se utiliza su clave publica para comprobar la firma.
Si la firma resulta válida, el contenido y origen del mensaje queda autentificado y se procede a darle curso.
Si la firma no resulta válida, o no se confía en el emisor del certificado, se responde informando de esa circunstancia, siguiendo el mismo procedimiento descrito aquí.
Para saber más acerca de la seguridad para los servicios web, se pueden consultar los siguientes enlaces:
Para saber más sobre Reliable Messaging, se pueden consultar los siguientes enlaces:
Para saber más acerca de Secure Conversation, se pueden consultar los siguientes enlaces:
Para acceder a la documentación de la API es necesario cumplimentar el registro de usuario, siguiendo este enlace, e inscribirse como desarrollador.
