Detalles internos de un portal de turismo
Este artículo analiza la estructura interna de viajarporextremadura.com, un portal de turismo que integra un sistema de publicación web con una central de reservas online, tanto desde el punto de vista de la arquitectura interna de software como de los sistemas externos que utiliza y la comunicación con los usuarios.

El sistema que sirve de soporte a viajarporextremadura.com está basado en una arquitectura modelo-vista-controlador.

Simplificando un poco, el modelo representa el núcleo del sistema, la maquinaria que describe el estado del sistema en cada instante, procesa la información y aporta soluciones.

Las vistas son representaciones de la información que se obtiene del modelo. Por ejemplo, si el modelo es un sistema de búsqueda de alojamientos, una posible vista podría ser la representación de un listado de alojamientos que cumplen un determinado criterio.

Finalmente el controlador se encarga de actualizar las vistas cuando el modelo cambia (por ejemplo para diferentes criterios de búsqueda ofrece diferentes soluciones) y de hacer llegar al modelo los cambios del exterior (interactividad, por ejemplo si el usuario cambia el criterio de búsqueda).

Una de las ventajas de esta arquitectura es que se separan los detalles internos de funcionamiento de la forma en la que se representan y muestran los resultados al usuario. La separación en bloques o capas es fundamental para simplificar el mantenimiento y la actualización de sistemas.

En viajarporextremadura.com, la zona pública es independiente del backoffice o sistema de gestión, aunque por debajo está un modelo de negocio común. El modelo o lógica de negocio es el conjunto de algoritmos, estrategias y operaciones. Por ejemplo, ante una petición por parte del usuario y en función de la información y el estado del sistema, la lógica de negocio generará una determinada respuesta o solución.

La lógica de negocio accede a la información a través de una capa de acceso a datos. Esta capa es fundamental. En primer lugar porque en caso de cambiar de sistema o de motor de base de datos sólo habría que sustituir o actualizar esta capa. Y en segundo lugar porque el acceso a determinados datos puede cambiar de forma dinámica y es esta capa la que se encarga de adaptar la información para pasarla a las capas superiores.

En el otro extremo de la cadena, la capa de presentación se encarga de generar las diferentes 'vistas' a partir de la información obtenida del modelo. Por ejemplo un listado de alojamientos rurales, el contenido de un artículo a petición del usuario, etc. La forma en que se representa esta información de define mediante plantillas y hojas de estilo que forman parte del diseño.

En general, la funcionalidad de una aplicación se puede dividir en módulos. Por ejemplo un módulo de búsqueda de alojamientos, un módulo de publicación de artículos, un módulo de solicitud de reservas...

Cada uno de estos módulos responde ante una serie de estímulos (órdenes o acciones que solicita el usuario), contiene una determinada lógica de negocio (inteligencia), genera una serie de vistas (presentación) y accede a unos determinados datos (información). Lo ideal es que cada módulo sea independiente de los demás.

La arquitectura de viajarporextremadura.com permite que los módulos se puedan 'enchufar' directamente al controlador, de tal forma que la funcionalidad global de la aplicación puede crecer o modificarse de una forma muy sencilla.

De esta forma se integran en este portal dos aplicaciones distintas: una plataforma de publicación y gestión de contenidos (artículos, documentos, menús, formularios...) y una central de reservas online (catálogo de alojamientos, solicitud y tramitación de reservas...)

Para facilitar la gestión, la central de reservas está diseñada de tal forma que el administrador puede delegar sus funciones (en todo o en parte) hacia agencias, minoristas, distribuidores, etc. Cada uno de estos agentes tiene a su cargo un subconjunto de los alojamientos dados de alta en el sistema, y se encargan de la gestión de los mismos (actualizaciones) y de las reservas que generan esos alojamientos.

Para hacer posible esta descentralización el sistema necesita organizar y distribuir la información de forma segmentada. Por ejemplo, un agente sólo tiene acceso a las reservas relacionadas con los alojamientos que él gestiona. Todos los agentes y administradores acceden al mismo panel de control, y el sistema se encarga de determinar qué información suministra a cada cual.

Siguiendo la misma filosofía, el sistema se encarga de avisar a cada agente cada vez que hay una nueva incidencia (por ejemplo una nueva solicitud de reserva). El aviso se envía por email y por SMS (a través de una pasarela de envío de mensajes que se integra con la aplicación).

La comunicación con el cliente final se puede realizar a través del propio panel de gestión, por email, a través de telefonía IP o mediante telefonía convencional. El uso del correo electrónico y la telefonía IP puede suponer un ahorro de costes importantes cuando se trata de clientes internacionales.

Todo el proceso de reserva se puede completar online, incluyendo el pago mediante tarjeta de crédito en entidades de confianza: por ejemplo PayPal para pagos internacionales o los TPV virtuales de entidades bancarias: pasarela 4B, Banesto... La aplicación se integra con estas pasarelas de pago de tal forma que la confirmación de pago es procesada en tiempo real: por ejemplo, cuando el cliente realiza el pago del depósito de su reserva, automáticamente recibe un ticket (email) con la confirmación de la reserva y el sistema se encarga de actualizar el estado de la reserva y de avisar al agente correspondiente.

Aunque de una forma muy aproximada, este breve recorrido por el interior de una aplicación web puede servir como referencia para conocer un poco más sobre el funcionamiento y las posibilidades que ofrecen este tipo de sistemas.

Felipe Fernández Perera
Jefe de proyectos de Epsilon Eridani