jueves, 19 de marzo de 2015

Un puñado de Servicios Web NO es SOA

Me habían pedido que le pegase un vistazo a un nuevo proyecto de integración y al abrir la presentación del proyecto, en la tercera página, me encuentro con las letras SOA. ¡Imposible! me digo. SOA se basa en ofrecer servicios con bajo acoplamiento que se encargan de la orquestación y coordinación de procesos de negocio, los cuales pueden implicar uno o varios dominios.

Se de buena tinta que no se han definido es esta compañía dominios lógicos (por lo tanto no existen fronteras entre dominios), ni planificados procesos de negocio estándar, no hay coherencia ni contexto; por lo tanto no se pueden modelar servicios que coordinen ni orquesten nada. Ni siquiera existe un lenguaje ubicuo con el que entenderse. SOA no es un patrón arquitectónico tecnológico, es un patrón arquitectónico para modelar la organización lógica del negocio en servicios flexibles, escalables y sin dependencias; si no hay organización no puede haber SOA.

Cuando abrí el documento del catálogo de servicios mis sospechas se confirmaron. Lo único que hay es un puñado de servicios web que hacen cosas sueltas y completamente descontextualizadas.

No quiero poner en evidencia el equipo de desarrollo de la plataforma; estoy más que seguro que son gente lista y competente. No es su culpa. En las condiciones actuales es IMPOSIBLE montar una arquitectura orientada a servicios.





martes, 17 de marzo de 2015

Procesos de negocio de larga duración.

Cuando se modela un sistema, el cual está constituido por un conjunto de procesos de negocio, no es difícil percatarse de que existen procesos de negocio que tienen una larga duración. Esto nos genera una situación en la que el flujo de trabajo se convierte en una máquina de estados intermedios desconectada en espera de los eventos para continuar hasta su resolución final.

martes, 3 de marzo de 2015

Mantén el historial GIT limpio.

Prisas, despistes, inoportunos de última hora, dobles interpretaciones, gerencia inestable (en más de un sentido ;) ). Todas estas cosas, y muchas más, son las que provocan que acabemos con varios commits en el repositorio local de GIT para un work item que en un principio tiene bien definido el "Done" y sus fronteras. Esto genera un historial lioso e ilegible que no debería reflejarse en las ramas remotas. La mayoria de las veces, un ammend soluciona los líos; en otras se requiere una medida una tanto más drástica.

Supongamos que hemos generado 4 commits locales a partir de la rama remota para finalizar work item. En la rama remota lo único que interesa es el commit que refleja todas las modificaciones realizadas necesarias para el work item; por lo que antes de realizar el push debemos reescribir el historial de la rama local y "aplastar" (squash) todos los commits en uno sólo.

Por suerte, GIT nos permite reescribir el historial utilizando el comando rebase. Asumiendo el ejemplo anterior sólo necesitaríamos ejecutar el comando:

git rebase -i HEAD~4
y nos aparece un editor con los 4 últimos commits a partir de donde está la etiqueta HEAD. En este editor debemos marcar el primer commit con la opción "pick" y el resto con la opción "squash". Básicamente le estamos diciendo que combine los 4 commits en el primero.

El resultado final es un solo commit que contiene todos los cambios realizados para la finalización del work item. Ya sólo queda realizar el push a la rama remota sin más complicaciones.