Componentes de una plataforma SOA - I Parte

ESB - Capacidades BASICAS

El componente principal de las implementaciones Orientadas-a-Servicios está construido como un middleware en la forma de un Enterprise Service BUS (ESB). La funcionalidad de un ESB es la de entregar todo las capacidades de interconexión requeridas para aprovechar los servicios implementados a través de la arquitectura completa, incluyendo los servicios de transporte, servicios de eventos y servicios de mediación. La mejor forma de definir las funcionalidades de un ESB es especificando sus capacidades. Las capacidades de un ESB son las siguientes:

Enrutamiento, es la habilidad para canalizar una petición a un determinado proveedor de servicios sobre un criterio o variable de enrutamiento. Los tipos de enrutamiento pueden ser estáticos o deterministas, enrutamiento basados en contenido, enrutamiento basados en políticas o enrutamiento basados en reglas complejas gestionados sobre componentes de reglas de negocio.
Transformación de Mensajes, es la habilidad para convertir la estructura y el formato de un requerimiento del servicio de negocio a la estructura y formato esperado por el proveedor del servicio.
Enriquecimiento de Mensajes, es la facilidad para adicionar o modificar la información contendía en el mensaje requerido por el proveedor del servicio.
Transformación de Protocolos, es la habilidad para aceptar un tipo de protocolo de un consumidor como entrada (ejemplo: SOAP, TCPIP, JMS, RMI) y comunicar al proveedor del servicios a través de un protocolo diferentes (ejemplo IIOP, HTTP).
Mapeo de Servicios, es la facilidad para traducir un servicio de negocio a una correspondiente implementación de servicio, brindando un enlace y proporcionando la localización de información.
Procesamiento de Mensajes, es la habilidad para gestionar el estado y llevar a cabo la gestión del requerimiento aceptando un requerimiento de entrada y garantizando la entrega al cliente vía la sincronización de mensajes.
Coreografía de Procesos, es la facilidad de gestionar procesos de negocios complejos que requieren la coordinación de múltiples servicios de negocios para cumplir un solo requerimiento de servicio de negocio.
Orquestación de Servicios, es la habilidad para gestionar la coordinación de múltiples implementaciones de servicios.
Gestión de Transacción, es la facilidad para brindar una única unidad de trabajo para un requerimiento de servicio de negocio brindado un marco de trabajo para la coordinación de múltiples recursos a través de múltiples servicios.
Seguridad, es la facilidad de proteger los servicios empresariales desplegados a través del ESB del uso no autorizado.

Adaptadores de Integración

En los albores de la integración con herramientas EAI la integración entre aplicaciones se realizaba a través de mecanismos propietarios utilizando en cada aplicación que requería intercambiar información un conjunto de librerías llamadas APIs, las cuales eran de por sí intrusivas ya que requerían que las aplicaciones incluyan dentro de su funcionalidad de integración código que implemente las funciones de las APIs. El estándar JCA brinda un mecanismo para interactuar con aplicaciones empresariales bajo una arquitectura JEE (Java Enterprise Edition). Con adaptadores que soportan JCA se puede realizar la composición de aplicaciones dentro de una arquitectura orientada-a-servicios usando una Arquitectura de Componentes de Servicios (Service Component Architecture-SCA).
Toda solución de integración basada en JEE, además de traer consigo un Juego de Herramientas para el Desarrollo de Adaptadores (Adapter Development ToolKit) soporta dos tipos de adaptadores:
Adaptadores de Aplicación, los cuales están diseñados para integrar las aplicaciones más populares del mercado. Estos encapsulan la lógica que brindan las aplicaciones y las exponen como métodos dentro de los adaptadores para ser consumidos y reutilizar dicha funcionalidad. Pero como nada hay perfecto, algunos adaptadores de este tipo no ofrecen toda la funcionalidad provista por las aplicaciones si no la principal y más reutilizable.

Adaptadores de Tecnología, estos permiten la integración con determinados tipos de tecnología. Son útiles para integrar aplicaciones que no poseen un API publicado. Algunos ejemplos de estos tipos de adaptadores son los de JDBC (para accesos a bases de datos relacionales), Texto Plano (que permiten acceder a archivos en formato plano para leer o escribir sobre estos), JMS (para envió y recepción de mensajes a través de repositorios llamados colas o tópicos) y Servicios Web.

Es conocido que los adaptadores de aplicación son los más caros de la suite de integración debido a que en algunos casos los fabrica un vendedor distinto al que vende la suite de integración.

Como los Servicios se Comunican

Después de que un servicio envía un mensaje sobre el camino, este pierde el control del comportamiento del mensaje mismo. De manera que para que el mensaje exista se requiere de unidades independientes de comunicación. Esto significa que los mensajes, como los servicios deben ser autónomos. De manera que el mensaje pueda tener suficiente inteligencia para auto-gobernar sus partes de lógica de procesamiento.
La arquitectura para la comunicación de servicios vía mensajes es similar a la arquitectura distribuida que soporta mensajería y la separación de interfaces de la lógica de procesamiento. Lo que distingue a la orientación-a-servicios es como los tres componentes (servicios, descripciones y mensajes) son diseñados. Después de que un servicio envía un mensaje sobre el camino, este pierde el control del comportamiento del mensaje mismo. De manera que para que el mensaje exista se requiere de unidades independientes de comunicación. Esto significa que los mensajes, como los servicios deben ser autónomos. De manera que el mensaje pueda tener suficiente inteligencia para auto-gobernar sus partes de lógica de procesamiento.
La arquitectura para la comunicación de servicios vía mensajes es similar a la arquitectura distribuida que soporta mensajería y la separación de interfaces de la lógica de procesamiento. Lo que distingue a la orientación-a-servicios es como los tres componentes (servicios, descripciones y mensajes) son diseñados.

Como se Relacionan los Servicios

Dentro de SOA, los servicios pueden ser utilizados por otros servicios u otros programas. Independientemente, la relación entre los servicios se basa en un entendimiento de que la interacción de los servicios, deben de conocer sus estrucruas básicas entre sí. Esta toma de conocimiento se logra mediante el uso de descripciones de servicio.
Una descripción de servicio en su formato más básico establece el nombre del servicio y los datos esperados y retornados por el servicio. La manera en la cual los servicios utilizan las descripciones de los servicios resultan en las relaciones clasificadas como acoplamiento bajo.
Para que los servicios puedan interactuar e intercambiar información con significado útil, estos deben intercambiar información. Para lo cual se requiere un mecanismo de comunicación capaz de preservar las relaciones de acoplamiento bajo que son requeridos. Este mecanismo es llamado Framework. Un Framework clásico utilizado por los servicios es la mensajería.

Encapsulación de Lógica por los Servicios

Para retener su independencia, los servicios encapsulan lógica dentro de distintos contexto. Este contexto puede ser especificado a una tarea de negocio, una entidad de negocio, un requerimiento de negocio, una funcionalidad de soporte a una actividad de un proceso de negocio o alguna otra agrupación lógica.
Lo que puede llevar a cabo un servicio puede ser algo pequeño o amplio. De acuerdo a esto, el tamaño y ámbito de la lógica representada por el servicio puede variar. En algunos casos, la lógica del servicio puede involucrar lógica provista por otros servicios. En este caso, uno o más servicios están integrados en un colectivo.

Bottom-Up & Top-Down

Análisis Bottom-Up (De abajo-hacia arriba)
Es la exposición de funcionalidad como servicios de baja granularidad y la composición sobre servicios de negocios de alta granularidad.

Este análisis evita costos extras, esfuerzo y el tiempo requerido para entregar servicios; los servicios entregados con este enfoque tienden a tener una vida corta y requieren mantenimiento frecuente, volverlos a hacer y versionarlos constantemente.

Análisis Top-Down (De arriba-hacia abajo)
Es la descomposición de las actividades del proceso de negocio para identificar servicios de negocios reutilizables entre procesos.

Este análisis requiere de una inversión inicial considerable porque introduce una etapa de análisis algunas veces tediosa (sobre todo si no se tienen claro los conceptos y definiciones) enfocado en la creación del blueprint de inventario de servicios­. Los servicios candidatos son definidos individualmente como parte de este blueprint para permitir que el subsecuente diseño de servicios pueda ser altamente normalizado, estandarizado y alineado

Capacidad vs Operación vs Método

Los patrones de diseño de contratos de servicios evitan el uso de términos como “operación” o “método” porque estos se asocian generalmente con una plataforma especifica de implementación (como componentes o Servicios Web). El término "capacidad" del servicio es utilizado para representar una función específica de un servicio que este puede realizar y a través de la cual este puede ser invocado. Las capacidades del servicio son generalmente expresadas por los contratos de servicios. Este término también es común durante las etapas de tempranas del modelo del servicio, cuando los servicios candidatos son conceptualizados previo a determinar cómo estos pueden ser físicamente diseñados y desarrollados.

Coreografía y Orquestación

Existen dos maneras de diseñar una composición de servicios (o flujo de proceso) utilizando servicios, estas son la coreografía y la orquestación. Una coreografía difiere de una orquestación con respecto en donde debe residir la lógica que controla las interacciones entre los servicios que componen el flujo de proceso.

Una coreografía (escritura de la danza) describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero sin en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una coreografía no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.

Si usted alguna vez puedo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.

Una orquestación describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una orquestación, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una orquestación es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.

Para entender mejor la definición de orquestación, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armonioso basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías.

Lógica Agnóstica y Lógica no Agonística

El término agnóstico tiene sus orígenes en el griego “agnostos”, lo cual significa “Sin conocimiento”. La lógica que es lo suficientemente genérica y que no se especifica (que no tiene conocimiento de) a una tarea principal en particular es clasificada como lógica agnóstica. Dado que el conocimiento específico a tareas de un solo propósito es omitido intencionalmente, la lógica agnóstica se considera lógica de usos múltiples. De otro lado, la lógica que es especifica (contiene el conocimiento de) a una tarea de un solo propósito es conocida como lógica no-agnóstica.

Otra forma de pensar acerca de lógica agnóstica y no-agnóstica es centrarse en que la lógica pueda ser refinada, debido a que de la lógica agnóstica se espera que sea de uso múltiple, está sometida al principio de reutilización de servicios con la intención de convertirla en una lógica altamente reutilizable. Una vez reutilizables, esta lógica es de verdad de multipropósito en el sentido de que, como un solo programa de software (o servicio), puede utilizarse para automatizar varios procesos de negocios.

La lógica no-agnóstica no tiene este tipo de expectativas. Esta está diseñada deliberadamente como un programa de software (o servicio) de un solo propósito y por lo tanto tiene diferentes prioridades de diseño.

A nivel de servicios, el problema es suscitado por la agrupación de lógica de multipropósito agrupada con lógica de un solo propósito trae como consecuencia un poco de reutilización o ninguna lo que introduce gastos innecesarios y redundancia en una empresa. La solución lógica que es agnóstica a un gran problema es separada de la lógica que es específica al problema más amplio. Uno o más servicios con distintos contextos funcionales agnósticos son identificados dentro de lo cual se encuentra la lógica agnóstica.

La solución lógica es posteriormente descompuesta y reorganizada como resultado de llevar a cabo el análisis formal y el modelo de procesos. La lógica agnóstica es definida y continuamente refinada sobre un conjunto de contextos de servicios candidatos. Estos contextos pueden basarse en clasificaciones de modelos de servicios agnósticos pre-definidos, como la que se establecen en las capas de servicios de entidad o utilidad.

La Siguiente Revolución en la Productividad

Atrapados dentro de su empresa, los procesos son actividades que ahora pueden ser cambiados, vendidos o comprados. Si se liberan, es posible crear una manera más radical de negocios tipo conectar-y-usar.

El haber entrelazado muchos fragmentos de los procesos de negocio ha mejorado en forma sustancial el impacto en términos de ahorro de costos, reducciones de ciclo de tiempo y mejora en los servicios. Las empresas que abrazaron la revolución de la reingeniería están ahora golpeando la pared. Afortunadamente, los medios para romper la pared están surgiendo. La frontera ya no es el proceso, sino más bien las actividades comerciales que componen cada proceso.

Cada vez es posible el diseño de muchas actividades económicas como componentes Lego de software que pueden ser de maneras más fáciles y llevados de forma independiente. La responsable principal de esto, es la Arquitectura Orientada a Servicios (SOA), una nueva forma relativa de diseño y desarrollo de software que soporta una actividad empresarial. La belleza de SOA es que permite que actividades o procesos creados a partir de actividades puedan ser accedidas usado las tecnologías ubicuas de Internet de forma estandarizada. Independientemente de las capacidades que conforman una actividad manual, son totalmente automatizadas, o implementadas en un punto intermedio, el diseño basado en SOA de un componente de software o interfaz electrónica de usuario permite que la actividad se convierta en un Servicio de facto. Esta transformación hace que sea mucho más fácil de compartir actividades discretas y todo el proceso interno, para comprar o vender al exterior, para delegar su ejecución a los proveedores o clientes y obviamente para actualizar y mantener los sistemas de TI.

Los obstáculos para utilizar SOA de esta manera existen. Uno es la carencia de estándares universales: los proveedores e industrias actualmente utilizan diferentes versiones de SOA. Este no es un problema mayor, porque de una u otra manera los sistemas utilizando diferentes versiones pueden de alguna manera conversar unos con otros sobre la mayoría de las actividades.

Un obstáculo más grande es bien conocido: el abismo existente entre los líderes de las empresas y sus departamentos de TI. Los CEOs, CFOs y personas de alta dirección han visto SOA como simplemente la próxima “gran cosa” que está siendo trabajado por los CIOs y asumen que terminara costando una fortuna sin ofrecer los beneficios que pregona. En parte debido a este miedo y por otro lado debido a que los CIOs no han entendido o han tenido problemas para articular lo que SOA hace posible, la mayoría de los CEOs han autorizado a sus departamentos de TI a desplegar SOA por moda y para mejorar y reducir el costo de mantenimiento del software de apoyo a los procesos existentes. Como resultado, muchas compañías que han entrado en SOA lo están aplicando sin repensar en el diseño de sus negocios. Esta omisión significa que han desestimado el gran valor de SOA: la oportunidad de crear una estructura organizacional más enfocada, eficiente y flexible.

Solamente las compañías que han rediseñado sus operaciones están eliminando una alta cantidad de software redundante, bajando los costos producto de la simplificación y automatización de procesos manuales y han realizado un alto incremento en su productividad.

Para el logro de estas ganancias, sin embargo requiere de un cambio radical en las operaciones de mejora de las técnicas. En esencia, se pide la transformación de las empresas de colecciones de operaciones propietarias sobre una colección de actividades estándares de conectar-y-usar.

Como ejecutar una AE-I PARTE

Mucho se habla de Arquitecturas Empresariales, pero cuando realmente se ejecutan es donde se ve el valor de su utilización y beneficios para el negocio.

¿POR DONDE EMPEZAR?

La estrategia de negocio es poco conocida en las organizaciones, si usted pregunta a cualquiera de la organización en una empresa no le va a poder decir claramente cuál es la estrategia de negocios. Esto debido a que no se ha determinado más allá de la visión y misión de una empresa.
Para una clara alineación del negocio con la TI en un esfuerzo de AE se debe empezar conociendo lo siguiente:

1. Misión, porque existe la empresa
2. Valores, cuales son las creencias y como se comportara la empresa para alcanzar su visión.
3. Visión, que se quiere ser
4. Estrategia, cual es plan de acción para ejecutar los objetivos que permitan acercarnos cada vez más a la visión. Aquí se debe contemplar los objetivos, alcance de cada objetivo y los medios para llevar a cabo cada objetivo.

Luego de esto, hay que diagramar las bases para la ejecución o lo que he dado por llamar "La Base de la Pirámide" para una AE. Esto es la infraestructura de TI y la digitalización de la automatización de sus procesos de negocio de sus capacidades más representativas y que diferencian a la compañía de la competencia.
Para determinar que no se tiene la "Base de la Pirámide" establecida o adecuada puede considerar los siguientes indicadores:

1. Se da una respuesta diferente a los clientes cuando se interrelacionan con los usuarios de sus compañía. Los canales de interacción con el cliente no están integrados ni estandarizados. Por ejemplo: si el cliente llama por un centro de atención de llamadas las últimas transacciones no está disponible o la programación de entrega de un producto-servicio no está disponible.
2. Crear un nuevo reporte por requerimientos de regulación implica desarrollos nuevos y una gran inversión en infraestructura.
3. El negocio pierde agilidad cada vez que se define o cambia una nueva estrategia. Por ejemplo: minimicemos los puntos de atención en oficinas y aprovechemos los canales electrónicos. Por ejemplo: ofrecer funcionalidad por la internet de operaciones realizadas por la aplicación empresarial es imposible porque se tiene que desarrollar la funcionalidad nuevamente porque no se soportan estándares de integración para aprovechar las funcionalidades existentes.
4. TI es siempre un cuello de botella en forma constante. Por ejemplo: problemas de operación que no están totalmente automatizados originan que los sistemas estén fuera de servicio o que se tengan que reprocesar operaciones ya realizadas.
5. Existen diferentes procesos de negocio ejecutando la misma actividad a través de la compañía, cada uno soportado por diferentes aplicaciones. Por ejemplo: existen dos aplicaciones que generar información de cliente para un proceso de trámite documentario.
6. La información necesaria para crear nuevos productos-servicios o tomar decisiones no está disponible a tiempo o siempre hay que realizar desarrollos nuevos para obtener la información. Por ejemplo: no se tiene información de cuantos productos-servicios compran los clientes en una campaña determinada.
7. Existen muchos usuarios de aplicaciones que para hacer su labor diaria toman datos de una aplicación y la llevan a otra aplicación para poder generar informes o crear actividades en los procesos negocio. Por ejemplo: El cliente se crea en una aplicación de CRM, luego para crear su orden de servicio se copian datos de cliente a mano y se ingresan en el sistema de Aprovisionamiento de Ordenes de Servicio.
8. No se tiene claro cuál es el beneficio de TI para el negocio de parte de los gerentes del nivel estratégico de la empresa. Por ejemplo: No se invita a TI para la revisión de estrategias de negocio ni cambios en los modelos de negocio.
9. No se cuenta con un modelo de negocio definido y mucho menos ningún gerente de nivel estratégico, táctico u operacional puede explicar el modelo de negocio en menos de 3 minutos. Por ejemplo: no se tienen las definiciones del modelo de negocio ni como ejecutarlo para lograr los objetivos de la estrategia.
10. El gerente sénior o decisores de planes de TI tienen mucho temor en discutir o poner en debate las iniciativas, nuevas actividades, cambios o eliminaciones de componentes que están ejecutando en la arquitectura de TI de la organización y pierden mucho tiempo en definir nuevas soluciones sin llegar a acuerdos de manera efectiva. Por ejemplo: las sesiones de TI de los gerentes sénior no finalizan con acuerdos específicos que permitan resolver un problema de negocio.

Si cualquiera de estos indicadores obtiene un SI esto está ocurriendo, entonces la "Base de la Pirámide" no existe o no es la adecuada en su compañía.
En la próxima entrega abordaremos que se debe considerar para establecer una "Base de la Pirámide" que permita establecer una AE a nivel organizacional.