La adopción de SOA promete a las organizaciones ser más flexibles y rápidas a la hora de poner una nueva funcionalidad en el mercado. También promete la caída de los costos del desarrollo. ¿y como se consigue esto? con la reutilización de servicios (pequeñas piezas de software). En lugar de crear nuevo código, las nuevas funcionalidades se lograrán mediante la composición de servicios de bajo nivel para formar otros de alto nivel y más valor añadido para el negocio.

Una organización más o menos grande, con madurez en la implantación de SOA, puede perfectamente disponer de cientos o miles de estos servicios. Servicios que dependen unos de otros, que interactúan entre sí. Si no se tiene cuidado y no se dispone de la metodología y herramientas necesarias, esta inicial ventaja de SOA se tornará en desventaja.

El éxito dependerá de la capacidad que tengan los diferentes roles implicados (arquitectos, analistas, jefes de proyecto, etc.) de gestionar con orden y concierto esta enorme cantidad de servicios. De esto dependerá que no se conviertan en una maraña inmanejable de spagetti.

La primera condición que debe darse para la reutilización (usar un servicio ya hecho en lugar de programarlo) es tener una herramienta donde se puedan registrar estos servicios ya existentes, de tal manera que la siguiente persona interesada en utilizarlo pueda encontrarlo.

Esta herramienta se conoce como SOA Registry, y en esencia es un índice de lo servicios desplegados en una organización. Contiene referencia a la información de los servicios, incluyendo el interfaz de los mismos y otra información relevante para el consumidor. Por supuesto, indica la localización del punto de acceso al servicio web (endpoint), en definitiva contiene la siguiente información:

  • Metadatos que podrían describir el estado del servicio.
  • Configuración del despliegue por ejemplo, el proxy.
  • Información sobre como desplegar este servicio en un entorno de producción.

Un registro de servicios podría ser una simple hoja Excel. Sin embargo, es obvio que a poco que aumente el número de los servicios a gestionar, esta hoja se haría inmanejable. La buena noticia es que ya existe un estándar, el UDDI, que define los servicios que deben ofrecer este tipo de herramientas, y que siguen la mayoría de fabricantes de software.

Un registro de servicios debe ofrecer al menos las siguientes funcionalidades:

  1. Publicar servicios para que puedan ser descubiertos por los consumidores.
  2. Clasificación, establecer la relación entre los servicios para hacer posible un análisis de impacto.
  3. Hacer posible unos servicios desacoplados. El cliente no tiene por qué saber en que máquina se ejecuta el servicio. Este desacoplamiento se logra con el repositorio, ya que es éste el único que conoce el endpoint del servicio.

El primer paso para empezar con SOA

Una de las preguntas que todos nos hacemos cuando vamos acometer la adopción de SOA en nuestra organización, es ¿por dónde empezar?. En mi opinión, la respuesta es clara, se empieza teniendo un registro de servicios. Tal vez al principio pueda valer con una simple hoja Excel, pero de nada servirán que tengamos servicios sin que estén catalogados y accesibles.

Comparte esta entrada…

Share