Tipos de aplicaciones SOA
Este escrito trata sobre los tipos de aplicaciones que se presentan cuando se implementa SOA. Se plantea la arquitectura de cada uno de los tipos mostrándola en un diagrama.
Esta no es la primera vez que escribo en este blog sobre SOA, puedes leer también los siguientes artículos: Conceptos clave de SOA y El bus de servicios en SOA [2].
Hay muchas posibles formas de aplicaciones que implementan los conceptos de SOA, pero podemos clasificarlas en tres según el Gartner’s Roadmap to SOA [1]: aplicaciones SOA puras, aplicaciones legadas y aplicaciones mixtas. Esto se puede ver en el siguiente diagrama:
Tipos de Aplicaciones SOA
Comenzaré por describir el primer tipo de aplicación, la Aplicación SOA, que es la que está más a la izquierda en el diagrama. En ella se nota que la arquitectura tiene dos partes: la interfaz del servicio y la implementación del servicio. Esta separación en interfaz e implementación es la base de la arquitectura de las aplicaciones orientadas al servicio. Consiste en que la parte de interfaz es la encargada de toda la comunicación con el exterior del servicio y es la única parte que lo deber hacer, de hecho, debe aislar a la implementación de esta tarea. Por su parte la implementación es la que hace el trabajo, contiene la lógica de la aplicación.
Esta arquitectura, que separa interfaz de implementación, permite que cuando se cambia algo en la implementación este cambio no repercuta en la interfaz. Logrando con eso que la comunicación con los demás servicios no cambie. Inclusive un servicio puede intercambiarse por otro siempre y cuando tenga la misma interfaz y en ese caso el impacto sobra las comunicaciones del sistema es nulo. Por ejemplo, se podría cambiar el sistema financiero, que es critico para cualquier organización, y desde que cumpla con la misma interfaz, los demás sistemas de información de la organización no se darían ni cuenta.
Esto permite, entre otras cosas, lograr ese gran objetivo de la Gobernanza de TI, que es la independencia de tecnología. De esa forma se puede realmente seleccionar al mejor dentro del principio de racionalidad del gasto. Y sobre todo, no seguir con una marca particular de software por que las dependencias hacen que se esté «casado» con él. En general, hace que los sistemas de la organización sean más flexibles, intercambiables y de bajo acoplamiento. Se parece más a un juego de construcción.
Pero no todas las aplicaciones en una organización tienen este esquema, de hecho cuando llega la orientación al servicio, todos los sistemas de información no son así, estos son los que se llaman aplicaciones legadas, en el diagrama es la que está de segunda. En ella podemos notar tres bloques: El de más arriba, de color gris, es la aplicación en si. Y en la mitad, el azul, se tiene el «truco» del asunto, es una pieza software llamado adaptador que como su nombre lo indica toma la interfaz de la aplicación y la adapta a la interfaz SOA.
Este adaptador puede hacer su trabajo de muchas formas. Algunas aplicaciones tienen una API muy bien definida, entonces lo que hace el adaptador es transformar de uno a otro. Pero algunas veces no se tiene esta API, pero se puede tener acceso al código fuente, en ese caso hay que escribir el adaptador en el lenguaje fuente con alguna librería que cumpla SOA. Algunas veces, no se tiene ni API, ni acceso al código fuente, pero si a la base de datos. En ese caso hay adaptadores generalizados que toman una consulta SQL y lo convierten en un servicio. Este último tipo de adaptador tiene la ventaja que es relativamente fácil de configurar y muchas veces es más fácil de hacer que con una librería en lenguaje nativo de la aplicación. Pero tiene el problema que pasa por encima de la lógica del negocio de la aplicación, pero con una buena disciplina de desarrollo este problema se puede subsanar.
El tercer tipo de aplicación la mixta, y también la tercera en el diagrama, es como su nombre lo indica una aplicación construida mezclando los dos tipos de aplicaciones anteriores, la pura y la legada. Este se da cuando SOA ya ha alcanzado un grado de madurez en su implementación en la organización, pero todavía se tienen aplicaciones legadas. En ese caso una aplicación se construye como una composición de servicios.
En el diagrama he representado los tres tipos de aplicaciones conectados a un bus de servicio, por la razones que expliqué en El bus de servicios en SOA [3]. Sin embargo, en la aplicación mixta las conexiones no aparecen mediadas por este bus, realmente esto lo hice por simplicidad y porque lo ideal es que esas conexiones sean a través del bus de servicios.
Esta clasificación en los tres tipos de arquitecturas de aplicaciones SOA son una buena guía para la implementación de SOA en una organización. Pero no es suficiente para lograr una implementación exitosa, se necesita mucho más: Saber y conocer de SOA, tener experiencia en esta arquitectura, contar con un excelente equipo de trabajo tanto en el análisis como en la implementación, saber y cumplir de estándares abiertos no solo de SOA, sino de TI en general y muchas otras cosas más son necesarias pero no suficientes para introducir SOA en una organización.
Algunas de estas cosas, pero no todas, las puedes encontrar en los siguientes artículos:
Referencias
- Gartner’ group. Gartner’s Roadmap to SOA. http://ebreez.com.au/Documents/Gartner%20Roadmap%20to%20SOA.pdf
- Luis Alejandro Bernal Romero (Aztlek). Conceptos clave de SOA.
- Luis Alejandro Bernal Romero (Aztlek). El bus de servicios en SOA.
Pensamientos de Aztlek 