La estrategia SOA ante el patrón petición-respuesta, o qué ocurre cuando se abusa de ello

por

La resistencia al cambio es una de las principales causas que dificultan la expansión de patrones de integración en tiempo real en una estrategia de interoperabilidad basada en la Orientación a Servicios. El patrón petición-respuesta es la solución más frecuente a un requisito de integración, y aunque en algunos casos es efectivamente la mejor opción, en la mayoría de las situaciones su uso acarrea más problemas que ventajas. Además, soy de los que piensa que el abuso que se hace de este enfoque, es reflejo de cierto defecto viciado, muy extendido en la profesión a la hora de diseñar los modelos de datos de los sistemas de información.

 

En este post vamos a analizar todo este asunto.

 

¿QUÉ ES EL PATRÓN PETICIÓN-RESPUESTA?

El patrón petición-respuesta consiste en publicar un servicio por parte de un sistema, para que los sistemas interesados en acceder a la información que dicho servicio provee, lo invoquen cada vez que lo necesitan. La llamada es síncrona de extremo a extremo, es decir, la transacción del sistema que realiza la petición no finaliza hasta que recibe la respuesta por parte del sistema que provee el servicio.

 

El patron de integracion peticion-respuesta es el mas generalizado, pero en la Estrategia SOA su uso debe reducirse todo lo posible

 

Principales características en el funcionamiento del patrón petición-respuesta

1. El usuario del sistema peticionario desencadena una transacción en su sistema. Mientras dure esa transacción, el usuario debe esperar a que otro sistema responda (el que publica el servicio). Normalmente el usuario no tiene que conocer este detalle, porque en teoría para él lo que ocurra “detrás del telón” (su interfaz) es transparente. Si embargo, en ese caso de uso, su experiencia de usuario depende de la disponibilidad y el rendimiento de otro sistema que le es ajeno.

2. El sistema que provee el servicio normalmente no lo publica específicamente para un sistema peticionario concreto, sino para todos aquellos sistemas que puedan estar interesados en la información que facilita mediante dicho servicio. Por lo tanto, su capacidad para responder a múltiples hilos o transacciones es crucial para no perjudicar a otras aplicaciones y sus usuarios dentro del ecosistema. La infraestructura necesaria y la complejidad para garantizar un rendimiento óptimo encarecen la solución, lógicamente.

3. Habitualmente, el esquema que soporta los datos que viajan en la petición y en la respuesta, son “propiedad” del sistema que publica el servicio. Desde el punto de vista de ese sistema esto es lógico, porque cualquier transformación necesaria entre la recepción de la petición y su procesamiento tan solo añadiría tiempo a la respuesta. Pero desde el punto de vista del ecosistema, este detalle añade acoplamiento entre los sistemas peticionarios y el sistema que provee el servicio. Si éste modifica su esquema, todos los sistemas que invocan al servicio deben adaptar también su software. Y además, este cambio debe hacerse de forma simultánea, o gestionar una doble versión del servicio mientras los sistemas que lo usan evolucionan a la nueva versión. El mantenimiento evolutivo del ecosistema se complica y encarece, y la probabilidad de que se produzcan errores en producción aumenta significativamente.

4. La información que se encuentra distribuida en el ecosistema sobre esa entidad en un determinado momento cualquiera, no respeta uno de los principios más sagrados en las tecnologías de la información: la integridad referencial. Todos los sistemas afectados deberían hacer una llamada casi simultánea al servicio publicado para asegurar dicha integridad referencial. De lo contrario, existe inconsistencia de datos. Y estaremos de acuerdo en que esto es grave.

5. Por último, pensemos en un ecosistema medianamente grande, donde este patrón se utiliza en distintos sistemas. El escenario no es precisamente eficiente, ni escalable, ni sostenible.

 

Pero aún cabe una reflexión más.

 

El punto de vista del usuario

 

Pongámonos en la piel del usuario del sistema peticionario. Imaginemos que nos enteramos de este funcionamiento, probablemente alertado por las numerosas veces que mi interfaz me dice que no ha sido posible atender mi acción en este momento, y que vuelva a intentarlo de nuevo pasados unos instantes, o algo parecido. Quizás me preguntaría lo siguiente: ¿por qué mi aplicación tiene que acudir a otro sistema para obtener una información que yo necesito aquí y ahora?. ¿Por qué no puedo tener esa información en mi sistema para usarla cuando la necesite?. ¿Acaso es una información menos importante que el resto de información que obtengo con rapidez y eficacia en mi sistema?. Seguramente no. ¿Entonces?. ¿Cuál es la justificación?.

 

La respuesta que recibiría del técnico correspondiente se parecería a esto: “porque aquel sistema es el responsable de la entidad que usted está consultando, y por tanto es ese sistema quien tiene que suministrarle la información”.

 

Si yo fuera ese usuario le podría responder algo así: “Perdone, pero a mí no debería afectarme el diseño de otros sistemas, o qué entidades mantiene y cuales no. Yo en mi trabajo necesito esa información tanto como cualquier otro dato de los que obtengo sin fallo y de inmediato, pero esa información a menudo me produce errores o no puedo consultarla, por lo que mi aplicación, para mí, está mal hecha”.

 

Y tendría razón. En concreto estaría mal diseñado su modelo de datos, y el error sería de los de bulto, de primero de informática: falta una entidad. O como mínimo, faltan atributos en alguna entidad. Y la solución que el equipo técnico le ha facilitado a ese usuario consiste en que esos datos que no están en su modelo de datos, los pido a otro sistema que sí los tiene, y tiene publicado un servicio que puedes invocar para que te devuelva esa información.

 

¿QUÉ PLANTEA LA ESTRATEGIA SOA COMO ALTERNATIVA AL PATRÓN PETICIÓN-RESPUESTA?

En una estrategia de interoperabilidad basada en la Orientación a Servicios, el asunto debería tener un enfoque muy diferente. Veamos algunas de las diferencias más importantes:

1. Las decisiones deberían basarse en los intereses del ecosistema de información, no en las capacidades técnicas de uno de los sistemas que lo componen. No debería valer el argumento “ya que ese sistema tiene publicado un servicio que devuelve ese dato, vamos a usarlo”.

2. El modelo de datos de cada sistema de información debería ser completo. Si un sistema tiene entre sus requisitos la necesidad de disponer de cierta información asociada a determinada entidad, esa entidad o al menos los atributos que se necesitan deberían formar parte del modelo de datos. Y naturalmente debería haber una manera de mantener esos datos perfectamente actualizados, como el resto de entidades y datos que usa la aplicación.

3. El flujo de información no debería venir impuesto por las particularidades técnicas de cada sistema, sino por el flujo de información natural del negocio. Debería surgir por ejemplo del análisis de los proceso de negocio implicados, enfrentando el funcionamiento actual (modelado “as is”) y el funcionamiento deseado (modelado “to be”). De este análisis deberían derivarse las decisiones sobre los trabajos técnicos a acometer.

4. Todos los sistemas de información que necesitan la información en cuestión, deben disponer de dicha información con la misma fiabilidad, rapidez e integridad referencial que el resto de información que pueda ser consultada por los usuarios del ecosistema o que pueda ser procesada por sus aplicaciones. De lo contrario, se producen graves deficiencias en la calidad de los datos, y por tanto, se toman decisiones de negocio mal informadas.

5. El papel del sistema responsable de la entidad afectada sigue siendo fundamental, pero con un enfoque radicalmente diferente: en lugar de publicar un servicio que pueda ser invocado en cualquier momento por un número indeterminado de aplicaciones, el proveedor de esa información debe comunicarla de inmediato, en tiempo real, cuando se produce el evento de negocio que genera dicha información (es lo que se llama EDA, “Event Driven Architecture”).

6. Para mantener el bajo acoplamiento en el ecosistema, no debería importarle el destino de esa información: su misión termina cuando lo entrega al ESB correspondiente. Es el middleware el que debe mantener la lista de sistemas suscritos a dicho evento, el que debe proporcionar la garantía de entrega con las políticas de reintentos que se establezcan, y el que, en definitiva, orquesta el flujo de información conforme al funcionamiento de los procesos de negocio.

7. El diseño del esquema usado para el envío de la información debería basarse en un estándar de mensajería. Y si no existe en la industria, debería basarse en un diseño corporativo de mensajería. En el peor de los casos, el ESB se encargaría de garantizar las transformaciones necesarias en los datos. Este “trabajo extra” no tiene ahora el efecto negativo de antes, porque ahora no estamos en transacciones síncronas entre extremos, sino asíncronas. No hay un usuario esperando con su mano en el ratón contando el tiempo desde que hizo “click” en su interfaz. En cambio, permite mantener el bajo acoplamiento.

 

La alternativa que propone SOA al patron de integracion peticion-respuesta

 

 

Ventajas del modelo asíncrono conducido por eventos

 

1. Integridad referencial en todo el ecosistema: la calidad de los datos es la que debe ser.

2. Bajo acoplamiento en el ecosistema de información: las modificaciones en un sistema no tienen ese efecto dominó que encarece e incluso bloquea los proyectos.

3. Ecosistema escalable: incorporar nuevos sistemas al flujo de datos es tan fácil como añadirlos a la lista de suscripción del evento en el middleware.

4. Sostenibilidad: el mantenimiento correctivo y el mantenimiento evolutivo se simplifican, reduciendo los costes asociados y ampliando la capacidad del ecosistema para crecer y adaptarse a las necesidades reales del negocio.

5. Los sistemas que forman el ecosistema de información se alinean con el funcionamiento real del negocio, con sus eventos y tiempos requeridos de respuesta.

6. La experiencia de usuario mejora sensiblemente.

 

Conclusiones

No vamos a terminar este post sin señalar un matiz a lo dicho hasta ahora: existen casos en los que el patrón petición-respuesta está plenamente justificado, naturalmente. Algunas veces, el volumen de datos que corresponden a una determinada entidad, es excesivo para incorporarlo a la base de datos de una aplicación. En estos escenarios, es legítimo adoptar el patrón petición-respuesta para que esta aplicación solo recupere esos datos cuando sepa que los va a usar.

 

Un ejemplo claro de esto podemos encontrarlo en los hospitales. Los sistemas departamentales pueden ofrecer un servicio especializado, con un uso muy acotado a ciertos diagnósticos, a ciertos pacientes. Por lo tanto no es lógico que esos sistemas se suscriban a los servicios de censo del hospital para recibir la información de toda la población ingresada en cada momento. En vez de eso, cuando reciben la petición de una de las pruebas diagnósticas o analíticas que realizan, invocan al servicio de consulta de datos del paciente para recuperar su información, ya que solo necesitan conocer los pacientes cuyas pruebas deben realizar, no el censo completo del hospital.

 

Siempre hay que analizar cada caso. Pero en mi experiencia, la estrategia SOA encuentra con frecuencia un obstáculo en el patrón petición-respuesta, en su uso tan extendido como solución a todos los requisitos de integración dentro de un ecosistema de información. Es difícil reconocer que el abuso de este patrón está entre las principales causas de las arquitecturas espagueti. Es difícil cambiar la mentalidad de los responsables TIC de las organizaciones, y de los profesionales TIC de muchas empresas. La resistencia al cambio pesa mucho, y aparece con frecuencia una de las frases más paralizantes en la evolución de las TIC: “esto se ha hecho siempre así”.

 

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This