Se ha publicado hace poco un libro de la serie soa books, editado por la prestigiosa editorial McGraw Hill. Su título deja pocas dudas sobre su contenido: “SOA Gobernance” (podeis ver en su web un capítulo de manera gratuita sobre “entendiendo el gobierno SOA”).
Los autores de este libro, definen lo que consideran los 11 pasos para lograr la adopción de SOA. Los 11 pasos o etapas son estos, como siempre con mis propios comentarios.

  1. Planificación de la adopción de SOA:
    En este paso todavía no se tiene el alcance que se le va a poner a SOA, cuántos servicios se tienen ni como se van a gobernar. Normalmente en esta etapa se trata de hacer ver a la gente de Negocio (los que ponen la pasta) de las bondades que tiene para lograr una mayor agilidad y reducción de costes en el desarrollo de software de negocio. También es la etapa en la que los grandes fabricantes de Middleware tratan de vendernos sus costosas “suites”.
  2. Análisis del inventario de servicios:
    En esta etapa se identifican aquellas piezas de software reutilizables que puedan llegar a ser servicios. Se trata de ajustar su “grano” de detalle para que sean lo suficientemente genéricos para que toda la empresa los puedan usar pero lo suficientemente concretos como para servir para algo.
  3. Análisis orientado a servicios:
    Esta etapa es de las más peliagudas, identificación de los servicios candidatos. ¿cómo identificamos a los servicios de negocio? tal vez esta entrada pueda resultar  de ayuda.
  4. Diseño orientado a servicios y a contrato:
    Se define el contrato o interfaz del servicio. Qué parámetros de entrada, que parámetros devuelve, qué es lo que hace (que tenga sentido para el negocio). Se empieza también a fijar quién es el propietario del servicio y qué nivel de servicio (SLA) debe proporcionar. La propiedad del servicio es una de las decisiones que de hondo calado que van a tener repercusión durante toda la vida del servicio (de dónde sale el dinero, con que equipo se va a contar, qué plazos, qué prioridades, etc. etc.)
  5. Diseño de la lógica del servicio:
    es el diseño técnico del mismo. En este punto ya debería estar categorizado. Por ejemplo, como servicio de núcleo (expone directamente una lógica de negocio del núcleo o backend de negocio), servicio compuesto (creado a partir de otros servicios más sencillos), etc. Esto ayuda en el diseño del mismo.
  6. Desarrollo del servicio:
    la implementación del propio servicio. En casi todas las grandes empresas de banca-seguros, esto se hace en la plataforma Java (JEE). Si usamos un ESB, se puede aprovechar las herramientas gráficas que suelen acompañar este tipo de Middleware para componer servicios y procesos de manera visual (claro que no es oro todo lo que reluce). Normalmente la implementación se basará en web services (SOAP sobre HTTP)
  7. Test de los servicios:
    es necesario disponer de herramientas que permitan la prueba de servicios de manera aislada, sin depender del resto de servicios. Esto es más importante en una arquitectura SOA, donde se promete que dejaremos de desarrollar programas para “componer” servicios basándonos en otros servicios ya existentes. Si esto es así, en potencia, para probar un único servicio necesitamos que todo el resto esté desplegado y funcionando.
  8. Despliegue del servicio y mantenimiento:
    el despliegue de una solución basada en SOA suele ser varias veces más complejo y con más riesgo que una aplicación “tradicional”. Por un lado, los suites de desarrollo de los fabricantes más importantes, basadas en herramientas gráficas, generan código automáticamente que suele implicar varios aplicaciones a desplegar (varios EAR de Java). Si a esto le juntamos una aplicación de frontal como interfaz de usuario y otra aplicación con la la lógica de negocio, no es extraño encontrarnos con más de una docena de EARS que hay que desplegar de manera coordinada. Si contamos además, que la consola de despliegue puede no permitir hacerlo en paralelo, el despliegue se puede demorar más de una hora.
    Además es necesario que el despliegue se haga con un cierto orden. Una opción sencilla y efectiva en este caso, es desplegar en orden, partiendo de lo que está mas cerca de la base de datos hasta el frontal (modelo de datos, lógica de acceso a datos, lógica de negocio, servicios, frontal)
  9. Monitorización del uso del servicio:
    No sólo se quiere conocer quién usa el servicio, que tiempo de respuesta se da, qué tipo de errores, etc. etc. También se quiere llegar más allá asignando prioridades según el tipo de cliente. Por ejemplo asignar un endpoint del servicio con más rendimiento (sobre una máquina mejor) a un cliente premium y una máquina más normal a otro tipo de cliente.
  10. Descubrimiento de servicios:
    Hace relación a la posibilidad de descubrir servicios en tiempo de ejecución. Algo así como que el cliente pregunta ¿hay algún servicio de reserva de hoteles barato? y el repositorio de servicios le responde: sí, aquí tienes. Me temo que al día de hoy esto es ciencia ficción.
    Debemos conformarnos (que no es poco) con descubrir los servicios en tiempo de diseño. Es decir, que tengamos una herramienta de catalogación donde el analista pueda ver por ejemplo si una determinada funcionalidad de negocio ya está implementada para no volver a hacerla. Una cosa que parece muy simple pero no tanto de llevar a cabo.
  11. Versionado de servicios y retirada:
    Una de las características de los servicios es que el interfaz (el contrato) no cambia. En la práctica se traduce a que debemos mantener la compatibilidad hacia atrás de los descriptores WSDL. Tenemos la posiblidad de añadir nuevos parámetros pero siempre que sean opcionales y con un valor por defecto para que los clientes actuales no sea vean afectados.
    Otra opción que tenemos es crear una nueva versión del servicio. Cuando un cliente accede al registro de servicios, suele preguntar por un identificador del mismo y una versión. Puede existir varias versiones del mismo servicio en producción con diferente interfaz. Aunque no sé si la gestión de esto es peor que la limitación de conservar el interfaz.

Comparte esta entrada:
Share