SOA

Introducción

SOA (Service-oriented architecture) es una aproximación distinta a la habitual al diseño del software. SOA no es una tecnología; es un paradigma, un estilo de diseño.

Gracias a SOA aplicaciones independientes pueden compartir datos evitando dependencias, este intercambio de datos se realiza utilizando servicios. Un servicio SOA se encarga de satisfacer una necesidad de intercambio de datos entre diferentes sistemas cumpliendo ciertas reglas. Estas reglas se denominan principios SOA.

Principios SOA

Los principios SOA son las reglas que siempre hay que tener en cuenta cuando se toman decisiones sobre arquitectura SOA como:

• Analizar propuestas de servicios.
• Decidir si añadir una nueva funcionalidad a un servicio o dividirlo en dos servicios.
• Resolver problemas de rendimiento.
• Diseñar nuevos servicios.

Estos principios SOA son:

• Estandarización.
  Los servicios deben cumplir con los acuerdos de comunicación y diseño definidos para el catálogo al que pertenezcan. Los estándares incluyen tanto especificaciones de alto nivel como detalles de bajo nivel, como:
  • Nombre del servicio.
  • Detalles funcionales.
  • Datos de entrada.
  • Datos de salida.
  • Protocolos.
  • Seguridad.
• No acoplamiento.
  Los servicios del catálogo deben ser independientes unos de otro. Lo único que debe conocer un servicio del resto de servicios en el catálogo es su existencia. La forma de conseguir esto es definiendo contratos de servicio, de forma que cuando un servicio necesite utilizar otro no tenga más que usar dicho contrato de servicio.
• Abstracción.
  El servicio debe ser una caja negra definida solo por sus contratos. El contrato especifica los parámetros de entrada y salida sin incluir ninguna información sobre los procesos llevados a cabo. Esto reduce el acoplamiento con otros servicios al mínimo.
• Reutilización.
  Es el principio más importante y significa que los servicios deben ser concebidos para usarse por el máximo número de clientes. El servicio debe reutilizarse en cualquier contexto y por cualquier cliente, no solo por la aplicación que originó la necesidad del servicio. Para conseguir la reutilización el servicio debe ser independiente de cualquier tecnología y no debe estar acoplado a ningún proceso de negocio en concreto.
• Autonomía.
  El servicio debe tener una alto grado de control sobre el entorno de ejecución y sobre la lógica que representa. Cuanto más control tenga un servicio sobre los recursos subyacentes menos dependencias tendrá y será más predecible y confiable. Los recursos pueden ser tanto hardware (por ejemplo, la red) como software (por ejemplo, una tabla de la base de datos).
• Sin estado.
  Los servicios no deben tener estado, es decir, un servicio no debe retener información sobre los datos procesados. Todos los datos necesarios llegan desde los parámetros de entrada cada vez que se consumen. La información necesaria durante el proceso muere cuando termina el proceso.
• Descubrimiento.
  Con el objetivo de maximizar la reutilización, los servicios deben poder ser descubiertos. Todos deberían conocer la lista de servicios y su información detallada. Para conseguirlo los servicios deben tener metadatos que los describan, que se almacenarán en un repositorio o catálogo. Esta información de metadatos debe ser fácilmente accesible y disponible automáticamente; para ello, se puede usar, por ejemplo, UDDI (Universal Description, Discovery and Integration).
• Componibilidad.
  Los servicios con requisitos más complejos deben usar otros servicios existentes en lugar de implementar la misma lógica ya disponible en otros servicios.
• Granularidad.
  Los servicios deben ofrecer alguna funcionalidad relevante. No pueden ser tan simples como para que su salida siempre se tenga que complementar con la funcionalidad de otro servicio. De la misma forma, no debe ser tan complejo que ninguno de los servicios de la compañía utilice toda la información devuelta por el servicio.
• Normalización.
  Como en el diseño de bases de datos, los servicios se deben descomponer de forma que se evite lógica redundante. Este principio se puede omitir en algunos casos, por ejemplo si es prioritario el rendimiento.
• Independiente de vendedores.
  La definición del servicio debe ser tecnológicamente independiente, y cualquier característica específica de un vendedor no debe afectar al diseño del servicio.

Ventajas de SOA

Las ventajas de usar SOA son:

• Mayor posibilidad de reutilización
  Lo que se traduce principalmente en mayor consistencia.
• Desarrollo más eficiente
  Se puede dar más funcionalidad en menos tiempo y a menor coste. Para conseguir esta mayor eficiencia en el desarrollo es necesario que se cumplan los siguientes requisitos:
  – Tener una arquitectura de referencia que guíe el desarrollo de los servicios.
  – Utilizar BPM para definir los procesos de negocio, basándose en la composición de servicios en un conjunto de capas.
  – Tener procesos eficientes que gestionen la integridad de todos los servicios tanto para proveedores como para consumidores de los mismos.
  – Integrar las aplicaciones existentes y los datos. Para lograr una buena integración se necesita:
  – Un modelo semántico común (empresarial) para la información a compartir.
  – Una arquitectura de referencia que diferencie entre servicios de negocio y servicios de integración.
  – Una arquitectura de referencia que describa patrones comunes para la integración.
  – Una infraestructura capaz de transformar semánticamente los sistemas existentes y el modelo empresarial.
• Agilidad, flexibilidad y alineamiento
  Para conseguirlo se necesitan los requisitos anteriores.

Cómo aplicar SOA

El primer paso es pensar en qué servicios comprenderán nuestro catálogo SOA. El catálogo SOA es un registro donde encontrar por lo menos la siguiente información:

• Los servicios disponibles.
• Los servicios en progreso.
• Relación entre los servicios.
• Información detallada sobre cada servicio.

Una vez definido el catálogo se sigue un ciclo estándar en desarrollo para desarrollar los servicios SOA.



1. Análisis. Se determina qué hacer en cada servicio.
2. Diseño. Se define cómo hacerlo en detalle.
3. Desarrollo. Implementación del servicio.
4. Pruebas
5. Mantenimiento

En las cinco fases está presente la gobernancia que se encarga de definir políticas, principios y procesos.

Una vez hecho esto lo único que falta para tener definido SOA es habilitar el descubrimiento de los servicios disponibles. Es lo que se conoce como UDDI.


UDDI (Universal Description, Discovery and Integration)

Tecnología SOA

SOA en ningún momento nos dice qué tecnología usar ni cómo implementarla. Cada organización puede utilizar la tecnología que desee siempre que cumpla los principios SOA.

La implementación más común de SOA se basa en los siguientes estándares:

• XML. Se utiliza para modelar las entidades. Otra opción es JSON.

• HTTP(S). Es el protocolo utilizado para intercambiar información entre sistemas.

• SOAP. Se basa en XML y define la estructura que se utilizará para intercambiar la información. Un mensaje SOAP incluye los siguientes elementos:

  
  Estructura de un mensaje SOAP

  • Sobre (Envelope). Estructura de nivel superior que incluye todo los demás.
  • Cabecera (Header). Información extra sobre la seguridad, cómo se debe procesar el mensaje y la calidad del servicio.
  • Cuerpo (Body). Datos enviados al productor, o la respuesta enviada al consumidor.
  • Defecto (Fault). Información sobre los errores producidos al procesar el mensaje.

• WSDL. Es el lenguaje para definir el contrato de servicio. Define las entradas y salidas del servicio.

• ESB. Es el elemento central de la infraestructura tecnológica de SOA. Permite la comunicación entre todos los componentes.

Todos estos estándares juntos nos dan la tecnología de servicio web. Un servicio web es un proceso cuyo objetivo es intercambiar información con otros sistemas. El intercambio de información está definido por un contrato mediante WSDL.