Orquestadores y SOA

Existen tecnologías dentro del ambiente SOA, y BPM, que tienen mucho en común, y por lo tanto muchas veces no se logra visualizar de forma clara sus diferencias, estamos hablando de los “coordinadores de tareas”, u “orquestadores” en general , herramientas que permiten organizar actividades en un flujo. Bajo este concepto podemos tomar:

  • ETL (Extract Transform and Load)
  • WorkFlow tradicional
  • ESB (Enterprise Service Bus)
  • BPM o BPMS (Business Process Management Suite)

Estas herramientas en general permiten a través de asistentes gráficos crear un proceso a partir de la organización de tareas, o subprocesos.

Extract, Transform and Load (ETL)

Nacida para traspasar información desde un repositorio de datos origen a uno destino, esta tecnología esta orientada a los procesos de datos, procesos basados en repositorios como Base de Datos y archivos.

ETL es una de las tecnología mas antiguas de integración, integración a nivel de datos, y tal como las Bases de Datos relacionales su utilidad se ha consolidado en el tiempo. Incluso en la actualidad dentro de la “Arquitectura Orientada a Servicios” (SOA) tiene su puesto en lo que son los “Servicios de Información”, porque a pesar de que su principal uso es en procesos Batch (procesos de actualización masivos), también se puede usar para el desarrollo de funcionalidades especificas pero que involucran la integración de entidades de información dispares (distintas).

Tal como su nombre lo indica permite Extraer (Extract), Transformar (Transform), y Cargar (Load), información desde, y hacia distintas fuentes de datos.

  • Extraer: permite extraer la información de distintas fuentes de datos, principalmente bases de datos, y de la mayoría de los proveedores conocidos: Oracle, Sybase, DB2, MySQL, esto lo hace directamente desde las tablas, o usando “Stored Procedures” existentes. También permite extraer datos de archivos como XML, Excel, CSV, Texto, entre otros. Y han evolucionado hasta incluso obtener información de colas de mensajes, objetos Java, y Webservices, abarcando de cierta forma el terreno de los ESB.
  • Transformar: a través del manejo de Metadata (datos en un formato estándar desacoplado de la fuente) permite unir la brecha existente debido a la diferencia de los tipos de datos, por ejemplo el proceso de información “Actualizar Datos de un Cliente” que involucra actualizar en distintos lugares, puede requerir que un dato que esta en entero deba pasarse a tipo float (real), o que los apellidos que están separados en una base de datos deban guardarse juntos en un solo campo en otra base de datos, o que un código de comercio que esta en cierto estándar (como EAN) se deba traducir a otro estándar (como ISBN) porque así se maneja en el otro repositorio.
  • Cargar: permite guardar la información procesada en la misma diversidad de entidades que maneja dentro de la extracción: Bases de Datos, y archivos de distinto tipo.

En la actualidad las herramientas de ETL permiten componer estos procesos mediante asistentes gráficos, ambientes de desarrollo (IDE) que realizan una introspección de las fuentes de datos, obteniendo todos los objetos y sus campos de datos, permitiendo a través de “arrastrar y soltar” construir el flujo de proceso de datos. Además pueden incorporar reglas de negocio que permiten potenciar la funcionalidad del procesos.

Ejemplo: Proceso de Información Agrega Nuevo Producto

Proceso ETL

A este proceso ejemplo se le entrega un producto, el cual lo transforma en metadata, para poder por un lado obtener la marca asociada (desde una base Sybase), y por otro lado su código EAN (usando un Stored Procedure), si el código EAN no existe se busca en un archivo XML, luego finalmente toda la información se carga en la tablas de Productos (Base DB2), y además se registra en un archivo de Log (archivo txt). Mas que nada este ejemplo sirve para mostrar la relación que se puede establecer entre los distintos objetos ETL, pero la estructura definitiva de un diseño ETL dependerá de la herramienta que se utilice.

Los principales objetos que maneja un ETL son:

  • Tablas de Bases de Datos
  • Procedimiento Almacenados (Stored Procedures)
  • Archivos XML
  • Archivos de Texto, Archivos Excel.
  • Transformaciones de Datos.

Otra característica que ofrecen actualmente los ETL, y que es muy importante para la Arquitectura SOA, es que los procesos ETL se pueden ejecutar como WebServices, para lo cual el motor de ETL publica el proceso en formato SOAP, pudiendo ser ejecutado desde cualquier plataforma (Java, .Net), y ser integrado en tecnologías como ESB (Enterprise Service BUS).

Luego, en el contexto de SOA podríamos indicar que ETL es la herramienta que permite diseñar y construir procesos de información (servicios de información) basados en actividades (automatizadas) a nivel de datos.

Algunas herramientas ETL del mercado son:

WorkFlow Tradicional

Decimos WorkFlow “Tradicional”, porque la forma actual y bajo SOA de implementar un workflow es BPM, pero existen aun tecnologías WorkFlow tradicionales (no BPM), pero la mayoría se esta transformando en soluciones BPM.

La verdad es que actualmente muchas herramientas WorkFlow se acercan a lo que es BPM, viéndolo solo desde el punto de vista del flujo de los procesos de negocio, por eso aquí vamos a ver el concepto de WorkFlow Tradicional que se refiere al WorkFlow como era antes de evolucionar a BPM.

WorkFlow (Tradicional) es la tecnología que permite coordinar actividades humanas (realizadas por personas, Human Task), aquí se definen roles, actividades, reglas de negocio, en buenas cuentas un flujo de trabajo (WorkFlow), pero que a diferencia de BPM no contempla en forma natural los “servicios de negocio”, es decir no contempla las actividades de sistemas (System Task) bajo el estándar SOA.

Ejemplo: WorkFlow Actualizar Stock de Productos

Proceso WorkFlow

Este WorkFlow ejemplo define un procesos donde un ejecutivo ingresa Stock de productos, el supervisor verifica el stock ingresado, y si es un producto nuevo además verifica la ficha del producto, si por alguna razón no se valida el registro vuelve al ejecutivo, quien debe corregir el ingreso. Este es un ejemplo genérico, la estructura del diseño del proceso dependerá de la herramienta utilizada.

Luego en una solución (WorkFlow tradicional) el participante (usuario) debe indicar el cumpliendo de la tarea (cambio de estado), para de esta forma continúe el flujo de trabajo, y cuando debe interactuar con algún sistema, debe levantar dicho sistema y realizar la actividad en él, por ejemplo ejecutar el sistema de stock para agregar un nuevo producto.

Esa es otra gran diferencia con BPM, en BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow.

Con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada proceso, en que lugar del flujo se encuentra. Otra similitud con BPM , o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

Enterprise Service Bus (ESB)

Esta tecnología permite integrar sistemas a nivel de servicios, cuando se habla de tecnología para implementar SOA en una empresa la primera herramienta que se debe incorporar es el “Service Bus”.

Esta herramienta permite componer procesos a partir de servicios SOA, los servicios SOA son componentes funcionales encapsulados fuertemente reutilizables, haciendo el “típico” símil: son piezas de lego que permiten construir un sistema uniendo bloques, y en este caso construir un proceso uniendo servicios SOA.

Proceso ESB Actualiza Producto en Sistemas

Proceso ESB

En este proceso ejemplo se entrega el producto a actualizar se comprueba el tipo de producto (Ecommerce o SAP), usando una clase Java (conecto EJB), luego se actualiza en el sistema Ecommerce usando un WebService, o se actualiza en el sistema SAP usando un conector provisto por el ESB.

Al igual como BPM absorbió las funcionalidades de WorkFlow (a través de BPEL4People), también absorbió las funcionalidades del ESB (a través de BPEL), de hecho las BPMS (BPM Suite) suelen traer como parte de sus componentes el ESB.

La diferencia con BPM es que el ESB no maneja las actividades humanas (Human Task) solo maneja actividades automatizadas (System Task).

La diferencia con ETL (tradicional) es que ETL esta orientado a componentes de datos, y ESB esta orientado a componentes de Servicios.

Los objetos que principalmente maneja ESB son:

  • WebServices
  • Conectores a Colas de Mensajes, y JMS
  • Conectores a Aplicaciones de clase Mundial (PeopleSoft, SAP, JDEdwards)
  • Conectores a J2EE (EJB) y .Net
  • Transformaciones de Datos

Los ESB también manejan Metadata para la transformación de datos, y para lograr que los sistemas se entiendan a pesar de la diferencia en los tipos de datos que manejan.

Una característica importante es que los procesos se pueden ejecutar a través de WebServices, es decir un proceso de negocio ESB se puede publicar en protocolo SOAP, permitiendo que una gran variedad de plataformas puedan acceder a estos procesos.

Algunos ESB tienen conectores para Base de Datos, permitiendo integrar consultas a tablas (SQL Query), y procedimientos almacenados (Stored Procedures), con esto el ESB comienza abarcar terreno de los ETL, pero a decir verdad esta característica pone en riesgo la orientación a servicios (SOA), ya que los servicios deben corresponder a la capa de negocio, y no a la de datos.

Algunos ESB importantes:

Resumiendo ESB desde el punto de vista SOA es la herramienta que permite desarrollar procesos basado en servicios SOA.

BPM Suite.

BPM es la solución que permite construir procesos de negocio basado en coordinar tanto actividades interactivas (human task), como servicios (system task). BPM une lo mejor del mundo del WorkFlow Tradicional con el ESB.

En un mismo flujo se integran tareas realizadas por personas, con tareas automatizadas(sistemas), entregándole al participante de un proceso de negocio una sola interfaz, ocultando la interacción con los sistemas legados.

Ejemplo Proceso de Negocio Actualizar Stock de Productos

Proceso BPM

Basado en los ejemplos anteriores, en este proceso se integran 2 servicios al WorkFlow “Actualizar Stock”: una vez ingresado el stock, si el producto existe, entonces se obtiene los datos del producto usando un “WebService” (Obtiene Ficha Producto), y si el supervisor valida el ingreso al final se actualiza el producto usando otro “WebService” (Actualiza Producto), este ultimo servicio se supone es el proceso ESB “Actualiza Producto en Sistemas” publicado como WebService. Este es un ejemplo simplificado, en la realidad puede ser necesario incluir algunos servicios más.

La otras características de valor agregado de BPM son: que ofrece un grupo de herramientas para atender todo el ciclo de visa de un proceso de negocio, dentro de las cuales se destaca, el modelador (diseño procesos), el IDE (desarrollo de servicios), y el monitor (BAM), este ultimo que permite realizar un seguimiento y control mas acabado de los procesos de negocio.

Orquestadores en la Arquitectura de Referencia SOA

Desde el punto de vista de arquitectura marco SOA, los orquestadotes se organizan de la siguiente forma:

ETL, ESB, BPM, SOA

Advertisements

3 thoughts on “Orquestadores y SOA

  1. Hola!

    Una grata sorpresa encontrar contenido en español tan bueno como el que publican. :D

    Me gustaria ponerme en contacto con alguno de los administradores del sitio.

    Saludos!!

    RuGI
    Isaac Ruiz Guerra.

    Like

  2. Muy interesante tu blog, saludos
    Alfredo Cisterna
    Product Manager
    PECTRA Technology Inc.
    Processing Profits

    Like

  3. He estado leyendo atentamente los artículos de AgendaSOA, y he quedado gratamente sorprendido sobre la información encontrada.

    Llevo 10 años implementando soluciones de integración basadas en herramientas IBM desde MQseries System V1.0 hasta lo que hoy es Websphere Process Server, pasando por todos los sabores. Incluso mis soluciones eran SOA, antes de que estuviera en boga este concepto que todo el mundo usa y abusa de él.

    Debo de aclarar, que esto últimos años han sido los más difíciles con los productos de IBM dado la inmadurez de ellos, desde mi punto de vista. En particular me refiero a Websphere Process Server y Websphere BUSINESS Monitor. No sé si comparten conmigo, o tienen otra opinión.

    La consulta que les quiero hacer es qué opinan de FileNet, recientemente comprada por IBM, como herramienta de BPM. Para mi, reconociendo mi ignorancia en la práctica con el producto, es más una herramienta de workflow más que de BPM….qué opinan Uds? IBM la compró para potenciar ECM o BPM?

    Felicitaciones, y gracias por la información que proveen.
    Friedrich Schoess J.
    Consultor SOA.

    Like

Comments are closed.