En artículos anteriores hemos visto las ventajas de integrar en sistemas de sanidad y los principales estándares sanitarios. Ahora conviene que describamos el escenario deseable para integrar nuestra aplicación y esto nos lleva a la Arquitectura Orientada a Servicios: SOA.

En esta serie de artículos hablaremos sobre SOA, su objetivo, su rol en las aplicaciones, su relación con los servicios web y alguna otra cosa interesante más. Veremos por dónde empezar si queremos integrar con SOA y mencionaremos las ventajas que supone adoptar esta estrategia según nuestra propia experiencia.

Serie de artículos sobre Arquitectura Orientada a servicios (SOA):

• I: El problema de la arquitectura espagueti.
• II: ¿Qué es SOA?
• III: Servicios web, estándares y ventajas de SOA.

Antes de dar una definición de SOA, es importante que conozcamos cuál es (y, por desgracia, seguirá siendo) el problema que provocó su nacimiento. Esto nos lleva a comenzar nuestra serie de artículos hablando sobre la “arquitectura espagueti”, un anti-patrón en toda regla.

La arquitectura espagueti y los problemas

Desde hace muchos años ha habido la necesidad de integrar aplicaciones en los sistemas sanitarios bajo una rapidísima evolución tecnológica de los sistemas de información. Todos hemos sido conscientes de lo rápido que ha evolucionado la tecnología en los últimos años y los que llevamos un tiempo en esto sabemos lo que pasa cuando las cosas se hacen a marchas forzadas.

En definitiva, el problema es que estas necesidades se han ido abordando de forma puntual, pensando en abaratar costes a corto plazo y cumplir objetivos inmediatos, sin visión estratégica ni de futuro.

Cada comunicación en la integración se realizaba punto a punto y se implementaba mediante aplicaciones embebidas, conexiones a bases de datos, ficheros FTP, etc. De esta forma los sistemas quedaban fuertemente acoplados entre sí. Y además cada sistema usaba su propia semántica o hacía un mal uso de estándares en las comunicaciones.

Tras un tiempo adoptando esta “estrategia” (por llamarla de alguna forma), los sistemas quedan presos de la “arquitectura espagueti”. Esto se puede medir calculando el número total de conexiones necesarias punto a punto en función del número de sistemas integrados.

Haciendo números:

• 2 sistemas: 1 conexión.
• 3 sistemas: 3 conexiones.
• 4 sistemas: 6 conexiones.
• 5 sistemas: 10 conexiones.
• …
• 50 sistemas: 1225 conexiones.
• 100 sistemas: 4950 conexiones.

C = (N * (N - 1)) / 2 
N: es el número de sistemas
C: número de conexiones punto a punto

Es fácil ver que, a poco que se integren algunos sistemas, se hace prácticamente imposible reemplazar sistemas, añadir nuevos o actualizar los existentes.

SOA al rescate

Una vez planteado el indeseable escenario anterior, podemos hacernos las siguientes preguntas:

¿No sería deseable centralizar todo este flujo de información redundante de algún modo que permita desacoplar los sistemas entre sí?

¿No sería deseable disponer de procesos de negocio generalizados plasmados sobre un catálogo de servicios, en lugar de necesidades y requisitos funcionales específicos de cada aplicación?

¿No sería deseable obligar a los sistemas integrados a usar de forma correcta los mismos estándares para la mensajería y para la semántica?

¿No sería deseable adoptar una estrategia común que permita una evolución tecnológica natural de los sistemas de información, y la sustitución, añadido y actualización de los sistemas integrados sin asumir costes desorbitados?

Las respuestas a todas estas preguntas y a muchas más las podemos encontrar en SOA, la Arquitectura Orientada a Servicios como veremos en los siguientes artículos de la serie.