100 años de IBM. Fuente elpais.com

En compañías muy grandes se está produciendo un fenómeno curioso en la adopción de SOA. Se intenta andar mucho trecho en un corto periodo de tiempo y se pretende pasar a una arquitectura basada en servicios desde un modelo de desarrollo basado en programación estructurada. Y es que lo normal es que las grandes compañias basaran su core de negocio en plataformas mainframe IBM donde se usa COBOL/CICS/DB2. Al menos de momento claro, porque el empuje de los llamados sistemas abiertos o distribuidos con la plataforma Java está cada vez copando más y más espacio (que se lo digan a Oracle).
Y es que para asentar con éxito SOA, es necesario manejar unos cuantos principios de diseño que en un entorno tradicional pueden chocar más que en un entorno donde los conceptos de orientación a objetos son familiares.

Encapsulación de los datos

Un caso paradigmático es la encapsulación de los datos. Todos los programadores de orientación a objetos, están acostumbrados a manejar clases que definen por una parte el comportamiento que va a tener ese objeto en tiempo de ejecución (mediante sus métodos) y también los datos que va a manejar para esta ejecución. Por poner un ejemplo muy sencillo, una clase empleado tendrá un método setSueldo y getSueldo donde se puede asignar el sueldo o consultarlo. El dato sueldo, en sí, que puede ser un campo númerico de tipo float estará definido como privado. Es decir, nadie de fuera del objeto puede directamente modificar este dato.

Los datos pertenecen al servicio que los gestiona. No es posible que nadie vea los datos, ni menos modificarlos sin pasar por el servicio. Y es que el servicio puede tener (es lo normal) lógica de negocio que aplica al acceder a ese dato. ¿que pasaría por ejemplo si hay una regla de negocio que diga que cuando se obtiene el sueldo hay que hacerle un descuento del x% dependiendo del salario bruto? está claro que si leemos directamente el sueldo de la base de datos no aplicaremos esta regla de negocio (implementada en el servicio de consulta) y por tanto obtendremos datos incoherentes y un comportamiento anormal de nuestra aplicación.

Este concepto de tipo abstracto de datos, encapsulación de los datos, ocultación de la información, propiedad de los datos, o como queramos llamarlo parece que no se maneja de forma natural en entornos donde se usa la programación estructurada. Y es que con este paradigma (que data de los años 70) el código (el comportamiento) va por un lado y los datos van por otro. No existe este concepto de encapsulación ni de propiedad de los datos.

Desacoplamiento

Otro caso sería el del acoplamiento de aplicaciones o módulos de software.
Tradicionalmente lo que podemos llamar integración de aplicacione se ha hecho cuando la aplicación “A” inserta un registro en una tabla y la aplicación “B” lo lee de la misma tabla.
Esto choca diametralmente con el concepto SOA de desacoplamiento de los servicios y de la propiedad de los datos. Algo natural para un programador de orientación a objetos no lo es tanto para un analista de programación estructurada.

Conclusión

Teniendo todo esto en cuenta, parece más recomendable que antes de adoptar una arquitectura orientada a servicios hayamos tenido experiencia con la programación orientada a objetos. Si no puede ser así, debemos ser conscientes de que tenemos que hacer un gran esfuerzo de divulgación dentro de la organización para que se aplicen estos y otros principios sencillos y complicados a la vez. En esencia son sencillos pero por desgracia deben cambiar la forma tradicional de diseñar aplicaciones:

  1. Encapsulación y propiedad de los datos
  2. Desacoplamiento de los servicios

Comparte esta entrada:
Share