Arquitectura Orientada a Servicios (SOA): Guía completa

Introducción a la Arquitectura Orientada a Servicios (SOA)

Las arquitecturas orientadas a servicios (SOA) representan el estado del arte de la ingeniería de software y son un tema central en los grupos de desarrollo. Este artículo introduce las SOA, discute por qué las empresas las requieren, define qué es una arquitectura orientada a servicios y aborda mitos y realidades de las SOA.

¿Qué es SOA?

Una SOA es una evolución de la computación distribuida, basada en el paradigma pregunta/respuesta para aplicaciones síncronas y asíncronas. Modulariza la lógica de negocios o funciones individuales, presentándolas como servicios para aplicaciones consumidoras/clientes. La clave de estos servicios es su naturaleza desacoplada: la interfaz de servicios es independiente de la implementación. Desarrolladores o integradores pueden construir aplicaciones componiendo uno o más servicios sin conocer los detalles de su implementación. Por ejemplo, un servicio puede implementarse en .NET o J2EE, y la aplicación consumidora puede estar en una plataforma y lenguaje diferentes.

Características Clave de SOA

• Autodescripción: Los servicios SOA describen su interfaz en documentos XML independientes de la plataforma, utilizando el estándar Web Service Description Language (WSDL).
• Comunicación con Mensajes: Los servicios SOA se comunican con mensajes formalmente definidos mediante un esquema XML (XSD). La comunicación ocurre en un ambiente heterogéneo, con poco o ningún conocimiento del proveedor. Los mensajes pueden verse como documentos de negocios clave.
• Registro de Servicios: Un registro actúa como directorio de los servicios SOA en la empresa. Las aplicaciones pueden buscar e invocar servicios desde este registro, utilizando el estándar Universal Description, Definition, and Integration (UDDI).
• Calidad de Servicio (QoS): Cada servicio SOA tiene una QoS asociada, que incluye requerimientos de seguridad (autenticación, autorización), mensajería confiable y políticas que definen quién puede invocar los servicios.

¿Por qué SOA?

Las empresas de TI suelen tener una infraestructura heterogénea con sistemas operativos, aplicaciones y software instalados en diferentes momentos y bajo diferentes paradigmas. Reconstruir la infraestructura desde cero no es viable, ya que algunas aplicaciones existentes ejecutan procesos de negocios clave. Las empresas deben responder con agilidad a los cambios del negocio, escalando las inversiones existentes para atender nuevos requerimientos, soportar nuevos canales de interacción con clientes, socios y proveedores, y definir una arquitectura que soporte negocios orgánicos.

La naturaleza desacoplada de SOA permite conectar nuevos servicios o escalar los existentes de forma granular para atender nuevos requerimientos, hacer servicios consumibles a través de diferentes canales y exponer aplicaciones actuales y heredadas como servicios, preservando la inversión previa.

Como se muestra en la Figura 1, una empresa que emplea SOA puede crear una aplicación compuesta para la cadena de suministros utilizando aplicaciones existentes que exponen su funcionalidad mediante interfaces estándar.

Figura 1. Aplicación de cadena de suministros.

Para implementar SOA, las empresas necesitan una arquitectura de servicios, como la que se muestra en la Figura 2.

Fig. 2. Ejemplo de una arquitectura de servicios

En la Figura 2, los consumidores invocan servicios enviando mensajes. Estos mensajes son transformados y enrutados por un Bus de Servicios hacia la implementación apropiada del servicio. Esta arquitectura puede proveer un motor de reglas de negocios implementadas por uno o más servicios. También provee una infraestructura de administración que gestiona los servicios y permite actividades como auditoría, facturación y registro. SOA ofrece flexibilidad para procesos de negocios ágiles, mejor atención a requerimientos regulatorios (como Sarbanes Oxley - SOX) y cambios en servicios individuales sin afectar a otros.

Infraestructura SOA

Para ejecutar y administrar aplicaciones SOA, se necesita una infraestructura SOA, que forma parte de la plataforma SOA. Esta infraestructura debe soportar todos los estándares relevantes y los contenedores necesarios para el tiempo de ejecución. Una infraestructura SOA típica se muestra en la Figura 3. La siguiente sección describe los componentes individuales de la infraestructura.

SOAP, WSDL y UDDI

SOAP, WSDL y UDDI son fundamentales en la infraestructura SOA. WSDL describe el servicio; UDDI lo registra y permite su búsqueda; y SOAP actúa como capa de transporte para mensajes entre consumidores y proveedores. Aunque SOAP es el mecanismo por defecto para servicios web, existen alternativas. Un consumidor puede buscar un servicio en UDDI, obtener el WSDL para ver su descripción e invocarlo usando SOAP.

Perfil Básico WS-I

El perfil básico WS-I, provisto por la Organización para la Interoperabilidad de Servicios Web (WS-I), se está convirtiendo en una pieza clave para las pruebas de interoperabilidad de servicios. Los proveedores pueden usar las suites de testing de WS-I para probar la interoperabilidad entre diferentes plataformas y tecnologías.

J2EE y .NET

Aunque J2EE y .NET son plataformas dominantes para el desarrollo de aplicaciones SOA, SOA no se limita a ellas. J2EE proporciona un framework para que los desarrolladores participen en SOA y ofrece una infraestructura madura para adaptabilidad, fiabilidad, disponibilidad y rendimiento. Especificaciones como Java API para XML Registry (JAXR), para interactuar con registros UDDI, y Java API para XML-RPC, para invocar servicios remotos en J2EE 1.4, facilitan el desarrollo y la puesta en funcionamiento de servicios web portables entre contenedores J2EE estándar, interoperando con servicios desarrollados en otras plataformas como .NET.

Calidad de Servicio (QoS)

Los sistemas de misión crítica exigen seguridad, confiabilidad y control de transacciones. Las especificaciones básicas de servicios web (WSDL, SOAP y UDDI) no cubren estas exigencias avanzadas, conocidas como QoS. Diversas especificaciones relacionadas con QoS se están desarrollando en organismos como el W3C y OASIS. A continuación, se describen algunos componentes de QoS y otros estándares relacionados.

Seguridad

Web Services Security (WSS) se ocupa de la seguridad de los mensajes, enfocándose en el intercambio de credenciales, la integridad y la confidencialidad. WSS aprovecha estándares de seguridad existentes, como Security Assertion Markup Language (SAML), y permite su uso para asegurar los mensajes de los servicios web. WSS es un esfuerzo de OASIS.

Confiabilidad

En un ambiente SOA, se intercambian muchos documentos entre consumidores y proveedores. La distribución de mensajes con características como entrega "una vez y sólo una vez", entrega "al menos una vez", eliminación de duplicados, distribución garantizada y reconocimiento son cruciales en sistemas de misión crítica. WS-Reliability y WS-ReliableMessaging abordan la mensajería confiable y forman parte de OASIS.

Política

Los proveedores pueden requerir que los consumidores se comuniquen respetando ciertas políticas. Por ejemplo, se puede requerir autorización Kerberos para acceder a un servicio. Estos requerimientos se definen como policy assertions. Una política puede consistir en múltiples aserciones. WS-Policy estandariza las políticas de comunicación.

Orquestación

Al adoptar SOA, los servicios pueden integrar silos de datos, aplicaciones y componentes. Integrar aplicaciones implica estandarizar procesos como comunicación asíncrona, procesamiento paralelo, transformación de datos y compensación. Web Services Business Process Execution Language (WSBPEL o BPEL4WS) es una especificación de OASIS para la orquestación de servicios, donde los procesos de negocios se crean utilizando servicios discretos.

Administración

A medida que crece el número de servicios y procesos de negocios expuestos como servicios, se vuelve crucial una infraestructura de administración que permita gestionar servicios en un ambiente heterogéneo. Web Services for Distributed Management (WSDM) especifica que cualquier servicio implementado según WSDM debe ser administrable por una solución de gestión que cumpla con WSDM.

Otros atributos de QoS, como la coordinación entre socios y las transacciones que involucran múltiples servicios, se abordan en WS-Coordination y WS-Transaction, respectivamente, desarrolladas por OASIS.

SOA no es sinónimo de Servicios Web

Existe confusión sobre la relación entre SOA y servicios web. Según un informe de Gartner de abril de 2003, Yefim V. Natis distingue ambos conceptos: "Servicios web se refieren a especificaciones de tecnología, mientras que SOA es un principio de diseño de software. WSDL es una interfaz estándar conveniente para SOA. SOA es un patrón arquitectónico, mientras que los servicios web son servicios implementados con un conjunto de estándares. Servicios web es una forma de implementar SOA, pero no la única. Implementar SOA con servicios web ofrece una aproximación neutral a la plataforma para acceder a servicios y una mejor interoperabilidad a medida que más vendedores soportan las especificaciones."

Beneficios de SOA

SOA se diferencia de otras tecnologías distribuidas por su amplia aceptación y soporte por parte de los vendedores. Con su conjunto de estándares, SOA ofrece una nueva reusabilidad de recursos y permite crear aplicaciones sobre aplicaciones existentes. Además, SOA aísla a clientes y servicios de los cambios evolutivos en la implementación de un servicio, permitiendo modificar un servicio sin afectar al resto. No es necesario reescribir una aplicación completa, solo se modifica la parte necesaria y se complementa con nuevos servicios que respondan a los requerimientos del negocio.

En resumen, SOA ofrece mayor flexibilidad para construir aplicaciones y procesos de negocios de forma ágil, reutilizando la infraestructura existente para componer nuevos servicios.

¿Para qué sirve SOA?

SOA busca crear un concepto, una tecnología y un marco de procesos que permitan a las empresas desarrollar, interconectar y mantener aplicaciones y servicios de forma eficiente y económica. Un proceso de arquitectura empresarial robusto ayuda a resolver cuestiones como:

• ¿La arquitectura actual soporta y agrega valor a la organización?
• ¿Cómo se debe modificar la arquitectura para agregar más valor?
• ¿Soportará la arquitectura actual los objetivos futuros de la organización?

Beneficios de SOA

• Mejora la definición de roles de desarrollo
• Delineación de seguridad más clara
• Facilita las pruebas
• Soporta múltiples tipos de cliente
• Permite la composición de servicios
• Mejora la mantenibilidad
• Favorece el reuso
• Favorece el desarrollo en paralelo
• Facilita la escalabilidad y alta disponibilidad
• Interoperabilidad