SOA no va de reusar

El pasado día 7 asistí a un curso de un día sobre SOA organizado por iMeta e impartido por el reconocido Udi Dahan. Por cierto que fue en las instalaciones de Microsoft en “La Finca”. Uuuuyyy, qué miedooorrr… Bueno, tampoco es para tanto, soy muy Linux y muy Java, pero tampoco soy tan “talibán” como para no “entrar en la boca del lobo”. 🙂

Bueno, bromas aparte, la organización de iMeta fue muy buena (el catering estuvo a la altura, je, je) y Udi Dahan es toda una garantía. Además, como Hadi Hariri (de iMeta) me había explicado, el curso no estaba centrado en ninguna tecnología en particular. Yo, por si acaso, advertí de mi “orientación ideológica” en mi presentación. Por cierto, pensé que mi inglés estaba más oxidado, aunque al final de la tarde ya no daba pié con bola… 🙁

Pero vamos al tema. Udi Dahan es muy conocido en ambientes SOA (Service Oriented Architecture) y DDD (Domain-Driven Design) porque tiene un enfoque diferente al SOA de otros autores. Durante el curso le pregunté directamente por esto y sobre cómo se encaja con la visión de, por ejemplo, Thomas Erl. Udi me contestó que simplemente no encajan: el enfoque de Erl se centra en reusar, mientras que el de Dahan se centra en la autonomía de los servicios y el principio de única responsabilidad (single responsibility principle). En un correo posterior, Udi me ha aclarado que, según él, Thomas Erl ve los servicios más como construcciones de software, mientras que él los ve más como construcciones de negocio (implementados mediante varias construcciones de software).

No hace mucho leí “Implementing SOA” de Paul C. Brown, y hay muchas más coincidencias con Dahan que con Erl. Y eso que de Erl tengo nada más y nada menos que tres tochacos que voy a tener que rifar, salvo que el último, “SOA Design Patterns” me sirva para algo más que para hacer bulto en la estantería. :-/

Todo esto que resumo en apenas dos frases queda bastante claro a lo largo del curso porque Udi dedica bastante tiempo a explicar que al reusar realmente incrementamos el acoplamiento mientras que lo que realmente buscamos cuando decimos que queremos reusar es reducir el esfuerzo  empleado al desarrollar las aplicaciones para nuestros clientes. Por ello explica que, aunque sea paradójico, aquellas piezas de código en las que empleamos mayor esfuerzo, y que por tanto serían las que más nos interesaría reusar, suelen ser aquellas que son más específicas y que son las más dificiles de reusar puesto que están fuertemente acopladas al negocio que resuelven. Y por otro lado, resulta que nos empeñamos en que todas nuestras aplicaciones compartan componentes y diseños poco acoplados al negocio (es decir, que no aportan valor de negocio por sí mismos) con el objetivo de que sean lo más reutilizables posible. Pero parece que nos olvidamos de que, hagamos lo que hagamos, en algún punto de nuestro código tendremos que acoplarnos al negocio puesto que para eso desarrollamos software: para resolver problemas de negocio.

Udi nos presenta los conocidos cuatro principios de la orientación a servicios (según Microsoft):

  • los servicios son autónomos
  • los límites son explícitos
  • los servicios comparten esquemas y contratos, no clases
  • la compatibilidad de un servicio se determina en base a una política

y se centra en la autonomía de los servicios. Nos explica cómo alcanzar esa autonomía de una manera genuína, llegando hasta el extremo de que cualquier servicio se pueda implementar con el diseño que se quiera y sin la obligación de compartir siquiera la misma base de datos.

– ¡Eh! ¿Qué ha dicho? ¿Qué no se comparte la base de datos?
– ¿Y qué pasa con las restricciones de integridad? ¿Qué hago con mis foreign keys?

Muchos le preguntaron a Udi por esto. Je, je, yo ya sabía por dónde iba él porque esta discusión me la conozco de cuando estaba en Degesys, aunque allí no llegamos a ninguna conclusión (al menos mientras yo estuve). El caso es que la respuesta es bien fácil: las restricciones de integridad en la base de datos sólo sirven para acoplar servicios entre sí. Así que tú verás si quieres estar acoplado o no… 🙂 Claro, para conseguir esta autonomía hay hacer concesiones:

  • no tenemos un único modelo de datos compartido por todos los servicios
  • no tendremos un estado coherente de los datos al que estamos acostumbrados
  • tendremos que asumir un cierto nivel de redundancia en nuestros datos almacenados

¿Cómo se consigue esto? Pues Udi lo resuelve de una manera muy sencilla a la vez que elegante:

  • los datos son “propiedad” de una única fuente autorizada, es decir, cada dato en la base de datos sólo es manipulado por un único servicio
  • los servicios interesados en algún dato se suscriben a los cambios que publicará su fuente autorizada y guardan una copia local del dato (a modo de caché)

Esto, si no estoy equivocado, se viene conociendo como Event-Driven Architecture (EDA).

Pero Udi no nos contó sólo que la manera de implementar SOA es haciendo EDA, sino que insistió en que un servicio debe ser concebido desde el negocio y que se implementa íntegramente desde la UI hasta la BD. Para ello nos explicó diferentes maneras de componer la UI, pero todas evitando el concepto de página monolítica. Y recalcó que no tenemos que tener una única capa técnica consistente, sino que podemos decidir usar diferentes soluciones técnicas para cada problema de negocio. Claro, lo difícil es que hay que acertar en definir los “bounded contexts”, y sólo podremos acertar si tenemos claro que éste no es un trabajo tecnológico sino de análisis del negocio.

– ¡Vaya, claro, por eso hablan tanto del alineamiento de IT con el negocio cuando se hace SOA!
– ¡Ahora lo entiendo!
– ¡Y yo que pensaba que todo esto de SOA iba de reusar componentes tecnológicos y poner webservices por doquier!

Si estáis interesados, otro día puedo recopilar más notas y recordar algunos de los ejemplos que usó Udi en el curso.

¡Ah! Y que no se me olvide. Gracias a Hadi por el detalle que tuvo conmigo para Agile Spain. Lo dejo ahí porque si queréis enteraros tendréis que asistir a la charla que darán Juan, Agustín y Leo sobre “Introducción a Scrum”.

  • jcesarperez

    Hola José Manuel.

    Me ha parecido muy interesante y sobretodo rompedor desde mi experiencia de SOA = manojo de webservices, a cada cual peor diseñado.

    No sabes la envidia que me das, pero bueno es una desventaja más de no trabajar en la capi.

    Por cierto, si pudieras completar con algún ejemplo seria estupendo, sin compromiso claro.

    Un saludo.
    Julio.

  • Joserra

    Me sumo a la petición de Julio de más información y/o ejemplos!

  • Jorge Uriarte

    Buenas reflexiones, JMB.
    Sobre todo lo de "y yo que pensaba que era usar webservices"…

    El problema principal que yo he tenido con SOA, es que la mayoría de los vendors (tanto de servicios como de pegamento o de hierros) lo ven como una simple excusa para eso, para vender; "usa mi bus y estarás haciendo SOA, usa mis máquinas y estarás haciendo SOA, …"

    De ahí se deriva que es muy complicado que la "orientación a servicios", que efectivamente debe de estar alineadísima con el negocio, se quede en algo descafeinado, que en muchos sitios está muriendo por agotamiento del término, sin más… simplemente dejará de estar de moda.

    Con suerte, los principios (que no son nuevos precisamente) perdurarán, o al menos en part… pero no deja de ser doloroso este costoso ciclo de asimilación de conceptos y prácticas a base de empujones de marketing…

    En fin, que ya me da envidia no haber disfrutado de la charla.

    (y lo del detalle para Agile Spain… para los que no podremos aunque querríamos ir a la charla de Leo & Co., de qué va???)

  • Jose Manuel Beas

    Hola Julio (y a los demás),

    En realidad, si lo pensamos bien, no se trata de pensar en cómo diseñamos nuestras arquitecturas sino nuestras aplicaciones desde el punto de vista de las empresas. Se ve muy claro cuando te imaginas una empresa con departamentos y cada departamento contratando por separado una aplicación. Si tratas de poner a todos de acuerdo en un único modelo de datos, por ejemplo, te encuentras con marañas de tablas y relaciones que nadie sabe bien para qué sirven al cabo de un año. En cambio, si le das a cada departamento la autonomía necesaria para implementar su parte del negocio como quiera… parece más fácil, incluso se parece a la realidad… 🙂

    Siento lo de la envidia, chicos, pero como yo también me siento un poco “de provincias” (prefiero decir “de la periferia”), me siento en cierto modo obligado a contar estas cosas (aunque sé que no es lo mismo). De todos modos, si hay mucha gente interesada, poneos en contacto con iMeta y seguro que pueden repetir el curso (aunque advierto que no es gratis). 🙂

    Meto en el backlog la petición de un ejemplo. 😉

    Estoy con Jorge (y Udi también lo dijo en el curso) en que el marketing de algunos “vendors” está haciendo más daño que otra cosa. Sin embargo, para eso estamos los técnicos, ¿no?

    Lo de Agile Spain… mmmmm… no sé si contártelo… 🙂