Lo prometido es deuda, y como comenté en esta entrada del blog, voy a repasar una de las mejores presentaciones (al menos de las que yo vi) del congreso de IBM en Düsseldorf. Me refiero a la presentación de buenas prácticas en SOA. Me gustó mucho, pero no porque nos hicieran grandes revelaciones sobre este tema, sino que sobre todo, por su gran claridad y sencillez. Muy fácil de entender y sobre todo porque destilaba sentido común. Y esto no es fácil encontrarselo en un documento sobre SOA, donde las definiciones claras y sencillas no es lo más habitual. La presentación empieza con las definiciones de rigor, y después lista una serie de buenas prácticas o consejos (en cursiva). ¿qué es un servicio? una tarea de negocio reutilizable, o lo que es lo mismo, un software reutilizable que aporta valor para el negocio. ¿qué es SOA? Es un estilo arquitectural que soporta la integración de tu negocio como servicios integrados Buenas prácticas:

  1. Anda antes de correr. En lugar de acometer un cambio traumático haz la evolución lógica: primero conexiones punto a punto, después EAI (conexión de aplicaciones con un hub centralizado) y por último SOA. Esto es otra forma de decir lo de “piensa a lo grande y actua pequeño
  2. SOA es más que una tecnología. SOA se puede implementar con web services, de hecho es lo más habitual. Pero el uso de web services no es condición necesaria ni suficiente. Se pueden tener servicios en producción que siguen un esquema tipo RPC que no son SOA y al contrario, se puede tener una arquitectura SOA que no usa web services (basada en mensajería asíncrona, mensajes, etc.) Lo bueno del uso de web services es que es una tecnología estándar y es interoperable con tecnologías de diversos fabricantes a nivel de sistema operativo, lenguaje de programación, servidores de aplicaciones, etc. Este es otro de los conceptos que se repiten por activa y por pasiva, incluso en este blog 😉 ver esta entrada, esta y esta.
  3. (para los arquitectos) haz que tu arquitectura sea conocida y que se pueda usar. Poniendo enfásis en la documentación, en explicar claramente las decisiones que se han tomado para llegar a esta arquitectura, sus principios, etc. Creo que éste es un de los grandes problemas que tenemos los arquitectos: El primer paso para que una arquitectura sea conocida es que esté puesta por escrito y en un lugar accesible por todo el mundo (es curioso e interesante el caso de AME, la arquitectura de Endesa, que se pone a disposición del público). El segundo paso es lograr un equilibrio entre un exceso de documentación (que también hay casos) y una documentación manejable, útil y en la que sea fácil encontrar lo que buscas. En tercer lugar, pero  no menos importante, es divulgar todo esto entre los usuarios de la arquitectura, los desarrolladores.
  4. Identificar correctamente los servicios. Un servicio debe tener sentido desde el punto de vista de negocio. No todo es un servicio por el mero hecho de que lo puedas exponer como tal. Se recomienda establecer una clasificación de los servicios: por ejemplo, servicios atómicos o de entidad, servicios compuestos y servicios de procesos. Cada servicio hace una cosa: un consejo para esto es evitar las descripciones de los servicios con “Y”, por ejemplo: este servicio hace un depósito y una transferencia. En el blog ya se ha tratado también este tema en la entrada ¿Cómo identificar los servicios de negocio en SOA?
  5. Hacer el servicio reutilizable. Fomentar el uso de la patrón de diseño Façade El patrón de diseño Façade o Fachada es ampliamente usado en los desarrollos software. Es un patrón muy sencillo pero muy potente que se basa en publicar la funcionalidad de alto nivel que se proporciona al cliente, ocultado aquella funcionalidad de bajo nivel (o privada) que no necesita conocer. También es un punto único de entrada en el que la arquitectura puede establecer mecanismos de control, seguridad y trazas.
  6. 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).
  7. Pensar en las comunicaciones asíncronas. No todo son mensajes sincronos. La mejor forma de integrar servicios y con mejor rendimiento son las llamadas asíncronas (siempre que sea posible). En algunos escenarios, la comunicación asíncrona es la única posible. En un entorno web, cuando una tarea se puede demorar más de 2 minutos (o creemos que puede hacerlo) tenemos que implementarla de forma asíncrona. Esto es así, con más motivo, si en la comunicación se ven implicados dos sistemas o dos empresas diferentes. ¿podemos confiar en que cuando invocamos un servicio de otra empresa ésta siempre responda en un tiempo establecido?.
  8. Planifica la gestión de errores. Especificar unos patrones o clases de errores: Error de negocio: una acción no se puede realizar por una razón que tiene sentido para el cliente. Esto quiere decir que con la información que le proporciona el error, el cliente puede decidir realizar otra acción que solventa el error. Errores de tiempo de ejecución: Error temporal: un fallo puntual de conexión con la base de datos, bloqueo de hilos, etc. La acción que tendría que hacer el cliente es volver a intentarlo. Error permanente: la explicación de error no le aporta nada al cliente. No le queda más remedio que abortar lo que esté haciendo. Lo normal es que se requiera un cambio en el programa para arreglar este error. Éste es otro de los aspectos importantes en el desarrollo de software al que no se suele prestar la suficiente atención. Además de la división de los errores en los tipos que comenta, se debe establecer una gestión integral de errores que cubra los siguientes objetivos: a.- En todo momento se debe saber lo que ha fallado y por qué. Ante una incidencia, esto es imprescindible para una rápida solución. b.- Se debe orientar a poder solucionar el error. Se debe dar al usuario la posiblidad de arreglar el error (un ejemplo claro es un error de negocio debido a una introducción de datos incorrectos) c.- Se debe establecer el mecanismo por el que se puede seguir una petición del cliente de un servicio (usuario o aplicación) desde el principio hasta el final. Una forma de hacer esto es generar un identificador único que se va propagando por todas las capas. d.- En lo posible, hay que facilitar al desarrollador la implementación de la gestión de errores. De manera ideal, éste ni siquiera debería tener que codificar el control de errores (en su lugar debería hacerlo el framework de arquitectura).
  9. Gobierno SOA.Una vez que se tienen todas las piezas ¿como se gestionan?¿qué hace un buen modelo de gobierno? Principios: establecer objetivos y metas y las métricas asociadas para asegurar que se logran Roles y responsabilidades: que facilitan el alineamiento entre negocio e IT  para tomar las decisiones correctas Documentación de las decisiones: políticas, guías, mejores prácticas, estándaresMetodología: establecimiento del gobierno SOA y aplicarlo a lo largo del ciclo de vida Plataforma: Establecer la tecnología (registro, monitorización ,etc.)
  10. Registro de servicios. Mejor usarlos en tiempo de diseño. El descubrimiento dinámico de servicios es difícil de gestionar bien y es problemático si no se hace bien. Teóricamente se puede hacer que en tiempo de ejecución se puedan descubrir los servicios que mejor se adaptan a las necesidades de un cliente. Esto se hace con una taxonomía de servicios y la indicación de la consulta o query que nos devolverá el servicio adecuado. Sin embargo, como se dice en la presentación esto es bastante difícil de lograr (añade mucha complejidad). En su lugar, hay que empezar por usar el registro en tiempo de diseño: nos permitirá buscar servicios ya existentes que nos proporcionan la funcionalidad requerida. Si no existe, nos permitirá solicitar una ampliación de uno existente o la creación de uno nuevo. Ante una modificación nos permitirá hacer un análisis de impacto (¿un cambio en un servicio a quién afecta?) , etc., etc.
  11. Versionado de servicios. El control de las versiones de los servicios debe una parte del diseño del interfaz y del gobierno.Cuando el interfaz de un servicio se publica, debe ser respetado hasta que el servicio se retira oficialmente. Esto indica que un interfaz de un servicio no se debe modificar nunca. Por supuesto se pueden añadir nuevos parámetros de entrada/salida con valores por defecto que resulten transparentes a los clientes actuales.

En resumen, un buen listado de buenas prácticas, basadas en el sentido común y que se pueden llevar a cabo sin mucha dificultad. Comparte esta entrada… Share

Anuncios