Uno de los principios de SOA es que no se debe romper nada de lo que ya hay. Es decir, no pretender empezar de cero en la definición de una aplicación o sistema informático.

Si trabajamos en una gran empresa, lo más normal será que existan decenas (quizás 100 o 200) aplicaciones de todo tipo y condición, hechas con lenguajes, herramientas y metodologias totalmente distintas, que se ejecuten sobre diferentes sistemas operativos y con diferentes arquitecturas.

Un diseño SOA debe ser capaz de integrar todas esta casuística en un sistema homogéneo, reutilizable y flexible, que pueda aportar un valor añadido al negocio.

Evidentemente esto es más dificil cuanto más antigua o rara sea la aplicación que tenenemos que integrar.

A veces me pregunto cómo será esto dentro de 15 o 20 años, cuando el legacy, en esta ocasión, sea el propio SOA y los miles de servicios que tendremos soportanto el negocio.

Por supuesto, seguramente los lenguajes con los que estarán escritos estos servicios, como el Java por ejemplo, estarán obsoletos. También la tecnología WS-*, estará superada por cualquier otra (espero que más sencilla, productiva y fácil de entender). Alguno dirá que la tecnología REST seguirá vigente porque su base es el mismo protocolo HTTP. Pero también éste será superado algún día.

;

¿Que situación tendremos en este momento? Creo que infinitamente mejor que con el que tenemos que lidiar ahora con las aplicaciones legacy. ¿Por qué? Por las ventajas que ofrece SOA sobre otra forma de diseñar software.

  1. Desacoplamiento: la única dependencia entre el cliente y el proveedor del servicio está en la definición del contrato. Mientras éste no cambie, la implementación interna del servicio no afecta a los clientes. Podemos rehacer el servicio con otro lenguaje, con otro sistema operativo sin ningún problema. Aun en el caso de que se sustituya la tecnologia de web services por otra tendremos identificada la dependencia entre proveedor y consumidor en un sólo punto, el contrato.
  2. Abstracción: los servicios definen operaciones de negocio de alto nivel. Precisamente los conceptos de negocio dependen únicamente de la empresa, no de la tecnología. Con esto tenemos una relativa independencia y aislamiento de cambios técnicos.
  3. Realmente SOA no es una cosa nueva. El diseño de software basado en servicios no es una cosa que haya aparecido reciententemente. El concepto de rutinas, procedimientos y módulos de software es tan viejo como la programación estructurada (por lo menos de hace 40 años). Lo más probable es que no cambie tampoco en los próximos 15 o 20 años (aunque no se puede estar seguro de nada).

En definitiva, dentro de unos años, cuando tengamos que sustituir los actuales sistemas basados en SOA, creeo que lo tndremos más fácil que ahora cuando queremos sustituir los actuales sistemas legacy. Esperemos estar aquí, al pie del cañón, para verlo.

Comparte este artículo:
Share

Anuncios