Fuente Wikipedia

El desarrollo del software cada vez se complica más, no hay duda. Cada vez hay más funcionalidades, más dispositivos, más componentes, más “capas” lógicas, más servidores, etc. etc.

Desde que un usuario le da al botón de aceptar para hacer una compra en una web hasta que ésta se consolida en la base de datos, puede pasar por el propio navegador, un servidor de aplicaciones que gestiona la interfaz de usuario, un servicio web de negocio que invoca a su vez a un servidor de procesos de negocio, de éste a otro servicio con una lógica de negocio de más grano fino, de aquí al componente que se encarga de escribir a la base de datos, etc. etc. Y podemos complicar esto lo que queramos.

Por no hablar además, de las herramientas y lenguajes que son necesarios para desarrollar esta funcionalidad. Podríamos tener un editor web donde se maqueta, un editor de javascript con su depurador, un herramienta de desarrollo en el lenguaje que queramos para las páginas y la lógica de frontal, una herramienta de construcción de servicios para el ESB, de modelado y desarrollo de procesos (BPEL), un motor de persistencia que transforma objetos a tablas y por último un lenguaje de acceso a la base de datos que puede ser SQL o un dialecto del mismo.

Todo esto es demasiado. Es demasiado complejo de construir y de mantener. Creo que deberíamos hacer una reflexión de hacia donde nos lleva todo esto y repensar un poco a dónde queremos ir. Yo creo que tendríamos que volver a la sencillez (en la medida de lo posible).

Para que se entienda lo que quiero decir, traigo a colación una entrada en este blog, hace casi un año, donde me hacía eco de una serie de buenas prácticas que se recomiendan para SOA y creo que hay una que en un principio quizás no le dí demasiada importancia, pero que al día de hoy he visto que aplica totalmente. El fragmento al que me refiero es este:

La infraestructura. Un ESB es útil para gestionar la integración entre servicios de alto nivel, pero no debe ser la única forma de coordinación disponible en el arquitectura. Por ejemplo, se puede hacer de manera hard-coded según el caso.
Este también es un punto de vista interesante. Se supone que la programación con herramientas específicas para el ESB nos facilita el desarrollo para ciertas tareas como la transformación, cambios de protocolos, etc. Pero cada cosa debe usarse para lo que está pensada, en ocasiones es mejor programar la funcionalidad con el objeto java plano de toda la vida (POJO).

Los POJOS o sus correspondientes en otros lenguajes es la cosa más básica de los mismos. Lo primero que aprende un programador y lo primero que sabe usar. Deberíamos hacer todo lo posible por seguir usándolo allá donde se pueda. No todo van a ser nuevas herramientas (todas ellas propietarias) que nos prometen que todo va a ser muy visual (no se programa, sólo se configura en el ratón) y después vemos que en la práctica nadie sabe muy bien cómo funciona, generan un código o lo que sea por debajo que nadie entiende y que es muy complicado de desplegar en producción.

Un POJO, es fácil de escribir, fácil de entender, de enseñar y de aprender, fácil de entender y fácil de saber si está fallando cuando ocurre una incidencia. ¿por qué no hacemos POJOs en lugar de complicarnos la vida?

Volvamos a lo simple….

Comparte esta entrada..
Share