¿Cómo lo consigue? SOC y SOA

Antes que nada quiero aclarar el uso del término SOA, éste comúnmente se usa para indicar dos temas diferentes pero relacionados. A continuación me permito mostrar los dos conceptos:

• SOA como arquitectura, que se refiere estrictamente al significado de la sigla Arquitectura Orientada a Servicios (Service Oriented Architecture), un modelo de arquitectura tecnológica basada en los sistemas distribuidos que posiciona a los servicios como la forma principal de construir la lógica de la solución en los sistemas informáticos.
• SOA como paradigma de computación (SOC: Service Oriented Computing), que es una nueva generación de la plataforma de computación distribuida, conformada por un modelo de arquitectura (SOA), un paradigma de diseño, un conjunto de patrones, tecnologías, frameworks, esquemas de gobierno y un proceso de desarrollo.

Una vez aclarados los dos conceptos, paso a indicar que el tema del presente articulo es la SOC que contempla todos los aspectos de la orientación a servicios y es la forma que en SOA consigue obtener los objetivos y beneficios que promete (ver articulo: Qué persigue la computación orientada a servicios).

Recapitulando, SOA se compone de los siguientes aspectos que le permiten alcanzar los objetivos y beneficios que se propone:

• Modelo de arquitectura
• Paradigma de diseño
• Patrones de diseño
• Tecnologías y frameworks
• Proceso de desarrollo
• Esquema de gobierno

Modelo de arquitectura

Este modelo presenta 4 características fundamentales para poder alcanzar los objetivos de SOA:

• Manejada por el negocio. La arquitectura de tecnología debe estar alienada con la arquitectura de negocio de una organización.
• Neutral al proveedor. La arquitectura tecnológica no debe estar basada solamente en un proveedor, debe permitir que diferentes proveedores de plataforma sean combinados y/o reemplazados a lo largo del tiempo.
• Centrada en la empresa. El alcance de la arquitectura de tecnología debe abarcar un segmento importante de la empresa, permitiendo que el reuso de servicios se expanda mas allá de los silos de las aplicaciones tradicionales.
• Centrada en la composición. La arquitectura debe soportar la agregación de servicios, permitiendo acomodarse al constante cambio de requerimientos y necesidades de una empresa vía el ensamble ágil de composiciones de servicios.

Adicional a las características anteriores, este modelo de arquitectura esta formado por 4 capas o tipos de arquitectura:

Los servicios pueden definirse como colecciones de capacidades que se agrupan porque están relacionadas a un contexto funcional y en la actualidad pueden ser implementados como: componentes, servicios SOAP o servicios REST.

La composición de servicios se define como un agregado coordinado de servicios, compuestos por un iniciador y por lo menos dos servicios coordinados.

El inventario de servicios se define como una colección de servicios complementarios independientemente estandarizados y gobernados.

Paradigma de diseño

Para que los servicios diseñados sean considerados como aptos de representar SOA, deben cumplir con una serie de reglas complementarias o principios que colectivamente definen el paradigma de diseño SOA:

• Contar con contrato estandarizado
• Tener bajo acoplamiento
• Ser abstractos
• Ser reusables
• Ser autónomos
• No tener estado
• Ser descubribles
• Ser aptos de composición

Patrones de diseño

Cuando se intentan aplicar los principios anteriores al diseño de soluciones orientadas a servicios empiezan a aparecer contradicciones entre ellos y/o a ser difícil materializar los servicios de esa forma, ya que no se pueden aplicar al 100% todos los principios sino que debe existir un balance entre ellos de acuerdo a los casos particulares a los que nos enfrentamos. De allí que surgen los patrones de diseño que sirven como soluciones predefinidas (y probadas) para problemas comunes y que sirven para resolver los problemas que surgen cuando se intentan aplicar los principios de diseño.

Dentro de los patrones más destacados que se pueden mencionar a manera de ejemplo se encuentran los patrones de ESB (Entreprise Service Bus): transformación de modelo de datos, transformación de formato de datos, puente entre protocolos (protocol bridging), enrutamiento intermedio (intermediate routing), etc. Otro conjunto importante de patrones son los de orquestación: abstracción de procesos, centralización de procesos, respositorio de estado (state repository), etc.

Tecnologías y frameworks

Aquí se encuentran todas las herramientas de los proveedores que implementan los patrones de diseño como lo son ESB, los motores de procesos, motores de reglas, service registries, XML appliances, etc. También se encuentran los entornos de desarrollo, modeladores de XML (contratos, esquemas de datos, políticas, validaciones)

Con respecto a los frameworks, basicamente están las implementaciones de las especificaciones de SOAP y los WS-*, API para REST, etc.

Proceso de desarrollo

Para producir las soluciones orientadas a servicios existe un proceso que en términos generales sigue los pasos aplicados normalmente en la ingeniería de software dentro de un proyecto, pero que presentan algunas variaciones, enfocándose principalmente en un análisis más amplio y exhaustivo (con un alcance que va más allá de los limites de un proceso de negocio) y agregando una fase iterativa llamada: análisis de inventario, cuyo objetivo es producir un inventario normalizado con servicios que se complementen y que no tengan lógica redundante y con contratos y esquemas de datos estandarizados.

Los pasos generales del proceso son los siguientes:

• Análisis inventario
• Análisis SOA
• Diseño SOA
• Desarrollo Servicios
• Pruebas Servicios
• Despliegue Servicios
• Gobierno

Esquema de gobierno

Ya que SOA es un esfuerzo que aplica a nivel organizacional o por lo menos para un segmento(s) significativo(s) de una empresa, el esfuerzo de administrar, mantener y evolucionar todos los otros aspectos mencionados es grande, así que los esquemas tradicionales de gobierno, aplicados solamente a los aplicativos construidos como silos se quedan cortos, es así que en SOA se deben contemplar esquemas de gobierno para:

• Estándares
• Inventario de servicios
• Servicios
• Estructura organizacional (roles)
• Infraestructura
• Proceso de desarrollo

Para finalizar quiero mostrar gráficamente como se relacionan los aspectos anteriormente mencionados para conformar el paradigma de la computación orientada a servicios.