En el artículo anterior hablamos sobre el problema de la “arquitectura espagueti”, y comprobamos que era necesario encontrar una solución al problema de la multiplicación de las conexiones.

La solución es SOA, en este artículo veremos en qué consiste y qué roles puede jugar nuestra aplicación en esta arquitectura.

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.

¿Qué entendemos por SOA?

SOA significa “Arquitectura Orientada a Servicios” por sus siglas en inglés. En Internet podemos encontrar muchas definiciones del término, dependiendo de quién lo adopte, cómo y dónde.

Hay proveedores tecnológicos que ven SOA como una arquitectura tecnológica centrada en un ESB, otros relacionan el término con los servicios web o con un conjunto de aplicaciones para la integración de sistemas. Al término se le ha atribuido casi de todo.

Pero lo cierto es que SOA no representa una tecnología o una arquitectura software/hardware en sí misma, ni tan siquiera un concepto. Nosotros estamos con los que piensan que SOA es una estrategia centrada en procesos de negocio que dan lugar a un catálogo de servicios. Los servicios web son parte de la solución tecnológica recomendada (aunque no obligatoria como veremos en el próximo artículo) para su implementación.

Imagen cortesía de Danilo Rizzuti / FreeDigitalPhotos.net

Nosotros, como proveedores tecnológicos especializados en integración de sistemas, hablamos de SOA desde el punto de vista de las aplicaciones integradas. Y desde nuestro punto de vista hay una enorme diferencia entre integrar un aplicación en el marco de SOA o sin él. Así que siempre les diremos lo mismo a las organizaciones: ¡apostemos por una estrategia SOA! Es una inversión a largo plazo que realmente merece mucho la pena.

Para un enfoque más teórico desde el punto de vista de la gobernanza de toda una organización, recomendamos el blog de Manuel Jesús Morales, con entradas muy interesantes para entender SOA a todos sus niveles.

Otros enlaces de interés son:

• SOA en wikipedia.
• SOA en arcitura.com.
• Un caso de éxito SOA en España: el Servicio Andaluz de Salud (SAS).

¿Qué roles puede jugar nuestra aplicación en la arquitectura orientada a servicios, SOA?

En SOA existe un catálogo de servicios. Ejemplos de estos servicios son:

• Ingresar un paciente.
• Dar un alta.
• Fusionar dos historias clínicas.
• Informar resultados de laboratorio.
• Informar estudios radiológicos.
• Informar prescripciones médicas.
• …

Aunque cada sistema sanitario tenga su propio catálogo, hay un conjunto básico de servicios comunes que se suele implementar, como los anteriores.

Para integrar nuestra aplicación con una arquitectura orientada a servicios, debemos determinar qué servicios queremos consumir, y qué servicios somos capaces de producir (o proveer). Así, nuestra aplicación deberá declararse consumidora de algunos servicios y productora (o proveedora) de otros.

Nuestra aplicación como consumidora de servicios

Imagen cortesía de Salvatore Vuono / FreeDigitalPhotos.net

Lo primero que necesitaremos para integrar nuestra aplicación será la información de pacientes e historias clínicas sobre la que montar nuestra lógica de negocio.

Para ello existe un conjunto de servicios básicos, generalmente producidos por el HIS, que nos permite mantener el censo de pacientes debidamente actualizado para nuestra aplicación.

Los servicios más comunes son:

• Creación de nuevo paciente.
• Modificación de datos demográficos de un paciente.
• Fusión de pacientes.

Menos comunes, pero a veces implementados son:

• Eliminar un paciente.
• Anular una fusión de pacientes.

En caso de necesitar información de otros sistemas, como LIS o RIS, simplemente debemos declararnos consumidores de sus servicios. Para ello tendremos que justificar a la organización la necesidad de recibir esta información adicional.

Aquí vemos que una de las grandes ventajas de la arquitectura orientada a servicios es el débil acoplamiento de los sistemas. Si uno de los sistemas anteriores cambiase en un futuro, el nuevo solo tendría que implementar los mismos servicios, y nosotros como consumidores no nos veríamos afectados. De igual forma tenemos que ser conscientes de que nuestro propio sistema también puede ser reemplazable por otro. Esto es impensable con el punto a punto.

Nuestra aplicación como productora de servicios

Imagen cortesía de franky242 / FreeDigitalPhotos.net

Si la información que proporciona nuestra aplicación se adapta a algún servicio del catálogo podemos declararnos productores (o proveedores) de ese servicio.

Si nuestra aplicación produce información útil, pero no se adapta a ningún servicio del catálogo, tendremos que negociar con la organización su inclusión en éste.

En cualquier caso, la clave está en que todas las tareas de especificación y análisis se realizan directamente con la organización, independientemente de las aplicaciones con las que compartamos la información en los extremos.

Hasta aquí el segundo artículo de la serie. Hasta el momento hemos hablado del problema del espagueti, hemos introducido el término arquitectura orientada a servicios, SOA, y hemos visto algunas de las ideas que tenemos que tener en cuenta si queremos integrar en SOA.

Como colofón a esta serie, en el último artículo veremos la relación entre SOA, los servicios web y los estándares sanitarios, para finalmente hacer balance de las ventajas de adoptar una estrategia SOA.