Como prácticamente no existen grandes sistemas empresariales de I.T. totalmente nuevos, no nos queda otro remedio, si queremos implantar SOA, de partir de un sistema que no es SOA. Es decir, un sistema que se ha construido como las cordilleras montañosas, mediante la sedimentación de varias capas a lo largo de mucho tiempo, alguna que otra erupción repentina y algún que otro, como no, terremoto…
Pues bien, ¿como hacemos para pasar de un sistema a otro sin romper nada?
Hay que seguir, en mi opinión, tres ejes de acción:
- Eliminar las conexiones directas entre aplicaciones
Muchos de los problemas y riesgos detectados se deben en gran medida a las conexiones directas (punto a punto) entre aplicaciones. Esto provoca un gran acoplamiento entre las mismas y dificulta su evolución y adaptación a las nuevas necesidades funcionales. - Establecer un intermediario (bus) entre las conexiones de todas las aplicaciones
Las conexiones punto a punto implican que es necesario implementar cada conexión cada vez. Cada una de estas conexiones normalmente necesitan adaptar el formato y protocolo de ambas partes involucradas en la misma (cliente y servidor). Esto provoca que sea necesario implementar cada vez más conectores ad-hoc para cada conexión.
Ojo que esto no quiere decir necesariamente que necesitamos un ESB. Existen muchas alternativas a tener en cuenta dependiendo de la situación y necesidades presentes y futuras de la empresa, desde un framework de integración como Spring Integration o Apache Camel, a un ESB más sencillo y gratuito como MuleESB o un suite de Middleware comercial. - Establecer el principio de propiedad de los datos.
Los datos (de una tabla) son propiedad de una lógica de negocio y por extensión de una aplicación. Ninguna lógica de negocio que no sea propietaria de los datos puede acceder a ella directamente. Siempre tiene que hacerlo a través de la lógica de negocio que es propietaria.
Creo que son estos los tres puntos sobre los que hacer girar todo nuestro diseño de como será la arquitectura futura (modelo TO BE), teniendo en cuanta de que partimos de un modelo (AS IS) que seguramente no tendrá que ver nada con SOA, pero del quedemos hacer la transición dentro de unos plazos, de un presupuesto y sobre todo, sin romper nada y que el negocio siga levantando la persiana todos los días para atender a nuestros clientes.
¿y tú? ¿Por donde empezarías la transformación de un sistema existente a SOA?
23/06/2013 at 20:16
Buen articulo, a mi modo de ver algo simplista y con tendencia a generar cierta confusión en lectores con poco conocimiento en lo que representan las arquitecturas orientadas a servicios.
Si nos centramos únicamente en los interfaces no conseguiremos nuestro objetivo de transformar nuestro sistema en un sistema orientado a servicios, en realidad lo unico que habremos hecho con una alta probabilidad es un cambio en la tecnología de integración.
Muchas aproximaciones como la que se comenta en al articulo terminan homogeneizando las integración entre sistemas a través de servicios web, lo cual es todo un avance y una mejora pero desde luego que no tienen porque acercarnos al objetivo deseado.
Algun “pope” denomina a esta aproximación Integración basado en Servicios o Services Oriented Integration(SOI).
Como punto de partida, si a lo que se dice, como fin desde luego que no.
Para hacer dicha transformación, lo importante es no olvidar que el objetivo es que cada una de las capacidades que ofrece el sistema a trasformar debe ser expuesta como servicio para que otros sistemas actuales o futuros puedan consumir dichas capacidades y esto no se consigue exclusivamente centrándonos en los interfaces.
Recomiendo un articulo de open Group ( no es que me entusiasmante mucho open group) pero este articulo creo que ilustra los cambios a realizar en un legacy, especialmente importante como los front-end del sistema a transforma consumen los servicios generados, algo olvidado cuando se habla de SOA.
http://www.opengroup.org/soa/source-book/l2soa/case-study-1.htm
23/06/2013 at 20:46
Gracias por el comentario, es un gran aporte a la entrada. Comparto lo de que es simplista, la verdad es que ese era mi objetivo. Dar tres pinceladas sobre como enfocar la transformación de un sistema legacy. Vendrán más posts en esta línea.