BPM-SOA

4. INTEGRACIÓN DE APLICACIONES Y BPM

 Se necesita una fuerte integración de las tecnologías de la información como apoyo a la gestión de los procesos de negocio por tanto se necesitan soluciones con una gran capacidad de integrar sistemas de información de las organizaciones. los sistemas de workflow se convirtieron en un mecanismo natural de integración de aplicaciones, al requerir invocar diferentes aplicaciones durante la ejecución de una instancia de un proceso. Lo mismo sucederá con los BPMS. Pero la integración de aplicaciones es importante porque las organizaciones están demandando más capacidades de colaboración entre ellas a través de los sistemas informáticos. Algunos de los temas clave que las organizaciones requieren para hablar de integración entre aplicaciones y entre procesos son: - Capacidad para describir los servicios que se necesita de los socios. - Permitir que firmas especializadas ejecuten ciertos pasos en sus procesos (por ejemplo, pago electrónico). - Comprar en servicios de socios y de proveedores de servicios como elementos integrados en la gestión de procesos de principio a fin. - Realizar outsourcing sobre ciertas partes de los procesos, pero reteniendo el control de monitorización sobre esos procesos. - Exponer capacidades internas como nuevos servicios que puedan ser integrados en los procesos de clientes potenciales. - Permitir a especialistas de terceras partes que monitoricen, midan y valoren la mejoría en los procesos. La mayoría de las organizaciones actuales poseen multitud de aplicaciones informáticas con funcionalidades muy concretas, asociadas habitualmente a las áreas de negocio, y normalmente fabricadas bajo distintas plataformas y lenguajes de programación. Estas aplicaciones han sido el resultado de una forma de desarrollo de software dirigida por la información. Cada vez que se necesitaba procesar ciertos datos, se creaba una aplicación aislada que los calculaba. Los sistemas ERP (Enterprise Resource Planning) vinieron a resolver este problema planteando sistemas de información integrales que cubrían todas las áreas de negocio. No obstante, estos sistemas son caros y en muchas ocasiones presentan dificultades a la hora de adaptarlos a una organización concreta. Así, hoy en día, son muchas las organizaciones que disponen de un amplio catálogo de sistemas heredados diseñados para ejecutarse de forma aislada, que deberían ser integrados para llevar a cabo eficientemente sus procesos de negocio. Pero no solo es necesaria la integración de las aplicaciones internas a una organización, sino que debido a la forma en la que han evolucionado los mercados, gracias al establecimiento masivo de Internet en las organizaciones, se ha convertido en muy importante la integración de las aplicaciones de una organización con las de otras entidades, conocidas como socios de negocio, tales como proveedores, clientes, sistemas de pago, administraciones, etc. Este proceso de integración de aplicaciones suele ser muy costoso, con un gran nivel de complejidad y demanda de tiempo y suele requerir soluciones informáticas distribuidas. 

4.1. Técnicas de integración de aplicaciones 

Para lograr la construcción rápida de sistemas distribuidos se necesita una nueva capa software que realice la abstracción de la comunicación entre sistemas heterogéneos, esta capa se coloca entre las aplicaciones distribuidas y los servicios de red, los sistemas operativos y el hardware de comunicaciones. Esta nueva capa se denomina middleware y pretende resolver el problema de la comunicación entre procesos de forma independiente del lenguaje y de la plataforma hardware o software subyacente. La definición formal de middleware es "software de conectividad que consiste en un conjunto de servicios, que permiten interactuar a múltiples procesos que se ejecutan en distintas máquinas a través de la red" (Middleware 2005). Existen multitud de soluciones de middleware para integrar aplicaciones informáticas dentro de una organización, como sistemas RPC (Remote Procedure Call), monitores TP (Transaction Processing), intermediarios de objetos (Object Brokers) o Middleware orientados a mensajes. Como evolución del middleware surgen las herramientas de integración de aplicaciones empresariales (conocidas como EAI: Enterprise Application Integration). Estas herramientas realizan un énfasis mayor en la lógica de integración y principalmente surgen dos tipos: - Intermediarios de mensajes (Message Brokers): ocultan la heterogeneidad y la distribución de los sistemas empresariales. - Sistemas de Workflow: trataran el otro problema de la integración, facilitar la definición y el mantenimiento de la lógica de integración. Estos mecanismos de middleware y EAI solo sirven como mecanismos de integración de aplicaciones dentro de la misma organización, por lo que si los procesos de negocio de una organización se extienden fuera de los límites de ésta, habrá que buscar nuevas técnicas de Adolfo R. de Soto, Eva Cuervo Fernández 145 integración. Hay que tener en cuenta que en los últimos tiempos se ha producido un uso masivo de Internet en las organizaciones, lo que constituyó un paso muy importante en la integración de aplicaciones. Trajo protocolos de interacción estándar, como el HTTP, y formatos de datos, como el XML, que fueron adoptados rápidamente por las compañías, creando por tanto un estándar de facto dónde establecer una infraestructura de middleware común que reduce la heterogeneidad. En este contexto toman mucha fuerza los servicios web, concepto muy importante para la integración de aplicaciones tanto fuera como dentro de las organizaciones. La definición más completa de servicios web es la proporcionada por el consorcio W3C (The Word Wide Web Consortium) que los define como: aplicaciones software identificadas por una URI, cuyos interfaces y enlaces son capaces de ser definidos, descritos y descubiertos como artefactos XML. Soportan directamente interacciones con otros agentes de software usando intercambio de mensajes basados en XML a través de protocolos basados en Internet. La contribución de los servicios web para resolver las limitaciones del middleware convencional se basa en tres aspectos fundamentales: Arquitecturas orientadas a servicios: donde toda la funcionalidad del sistema se expone como un servicio, y los servicios son autónomos e independientes. Esto produce un desacoplamiento de las aplicaciones y hace que sean más modulares. Rediseño de protocolos middleware: El segundo aspecto importante de los servicios web es el rediseño de los protocolos middleware para trabajar de forma punto a punto entre las compañías, sin intermediarios. Lo que se conseguía hasta ahora con una plataforma centralizada que controlaba todos los procesos tiene que ser rediseñado para conseguirlo de forma descentralizada. Estandarización: En el problema de la integración de aplicaciones, la estandarización es un punto clave, aunque a veces es muy difícil de conseguir debido a la existencia de sistemas heredados y a que la complejidad y el coste del middleware siguen siendo muy elevados. Esta necesidad de estandarización ha sido reconocida por los principales vendedores de software, por lo que surgen diversos intentos de estandarización por diversas organizaciones y consorcios, como OASIS (Organization for the Advancement of Structured Standards) o W3C (The 146 Nuevas Tendencias en Sistemas de Información: Procesos y Servicios Workflow Management Coalition). Estas organizaciones intentan estandarizar todos los aspectos de la interacción entre aplicaciones, desde la definición de lenguajes hasta el formato de los mensajes y los protocolos de interacción. A veces incluso compiten más de una especificación para cada aspecto de la interacción. 

4.2. Arquitectura de servicios web La arquitectura de servicios web está basada en las interacciones entre tres elementos: proveedor de servicio, registro del servicio y consumidor del servicio. Las interacciones comprenden las operaciones de publicación, búsqueda y enlace. En un escenario típico, un proveedor de servicios aloja un módulo de software accesible por la red (una implementación de servicio web). El proveedor de servicios define una descripción de servicio para el servicio web y lo publica en un registro de servicios. El consumidor del servicio utiliza una operación de búsqueda para encontrar la descripción del servicio localmente o desde el registro de servicio y utiliza la descripción del servicio para enlazarse con el proveedor del servicio e invocar o interactuar con la implementación del servicio web. 

La Arquitectura de Servicios Web En una arquitectura de servicios web se distinguen los siguientes roles Desde una perspectiva de negocio es el propietario del negocio. Desde una perspectiva arquitectural, es la plataforma que aloja el servicio. Demandante del servicio: Desde una perspectiva de negocio es la aplicación que requiere satisfacer ciertas funciones. Desde una perspectiva arquitectural, es la aplicación que busca e invoca o inicia una interacción con el servicio. El papel del demandante del servicio puede ser jugado por un navegador dirigido por una persona o un programa sin interfaces de usuario por ejemplo otro servicio web. Registro del servicio: Este es un registro donde buscar las descripciones de servicios, donde los proveedores de servicios publican sus descripciones de servicios. Los demandantes de servicios encuentran el servicio y obtienen información de enlace en la descripción del servicio durante el desarrollo para el enlace estático y durante ejecución para el enlace dinámico. Para servicios accedidos estáticamente, el registro del servicio es opcional en la arquitectura, porque un proveedor de servicio puede enviar la descripción directamente al demandante del servicio. Así mismas demandantes de servicios pueden obtener una descripción de otras fuentes. Cualquier aplicación que utilice servicios web debe realizar las siguientes operaciones: Publicación de la descripción del servicio: Para que el demandante de servicios pueda encontrar el servicio, es necesario que la descripción del servicio sea publicada. Búsqueda de la descripción del servicio: En la operación de búsqueda el demandante de servicio puede recuperar directamente una descripción de servicio o puede consultar un registro de servicios por el tipo de servicios requerido. Esta operación puede llevarse a cabo en dos fases diferentes: en tiempo de diseño, para recuperar la descripción de la interface del servicio para el desarrollo del programa y en tiempo de ejecución, para realizar el enlace e invocación del servicio. Enlace o invocación del servicio: En la operación de enlace el demandante del servicio invoca o inicia una operación con el servicio en tiempo de ejecución usando la descripción del servicio para localizar, contactar e invocar el servicio. Estas operaciones pueden darse de forma independiente o de forma iterativa.  

5. SOA COMO ARQUITECTURA IDÓNEA PARA BPM

 Las organizaciones deben establecer una arquitectura que sea flexible y basada en estándares, que permita satisfacer las demandas actuales y planificar las del futuro. El requisito exigido a la arquitectura obliga a que sea capaz de automatizar los procesos entre aplicaciones heredadas ya existentes y a integrar las nuevas aplicaciones que se vayan incorporando a la organización, dando soporte al intercambio de datos entre múltiples aplicaciones en tiempo real. Para que una organización sea efectiva y fácilmente adaptable a cambios en los procesos de negocio, el enfoque de su arquitectura debe permitir: - Exteriorizar procesos, separándolos de las aplicaciones y proporcionando herramientas para simplificar el diseño, la implementación, y los cambios de los procesos. - Diseñar aplicaciones en forma de servicios, que serán parte de los procesos. Es decir, un proceso se puede fragmentar en los servicios de los que consta. A su vez un proceso puede ser considerado como un servicio compuesto. Este enfoque permite a los procesos de negocio coordinar el comportamiento de los servicios para la ejecución y cumplimiento de los procesos e interaccionar con otros procesos. Este es de nuevo el paradigma de cambio desde las aplicaciones a los procesos, haciendo que los procesos sean la pieza central de la arquitectura de la organización. Una arquitectura SOA (Services Oriented Architecture) es una arquitectura que soporta servicios débilmente acoplados para posibilitar la flexibilidad en el negocio de una manera interoperable e independiente de la tecnología. Consta de un conjunto de servicios de negocio que soportan la realización de procesos de negocio de principio a fin de una forma dinámica y reconfigurable utilizando descripciones de servicios basadas en interfaces. Utilizando SOA se puede descomponer la funcionalidad de la organización en partes reutilizables, más manejables, que pueden ser diseñadas, desarrolladas y gestionadas de forma independiente, como servicios. El modelo SOA es iterativo, puesto que un servicio puede estar compuesto de otros servicios de grano más fino, como, por ejemplo, aquellos que proporcionan utilidades técnicas como loging, seguridad, autenticación, pagos remotos, etc. Las arquitecturas orientadas a servicios permiten que componentes ejecutables, como por ejemplo servicios web, puedan ser invocados por otros programas que actúan como clientes o consumidores de servicios. Estos servicios pueden ser programas de aplicación nuevos o heredados que son invocados para su ejecución como cajas negras. Un desarrollador no necesita saber la lógica interna del programa, sino que le basta con conocer la entrada que requiere, la salida que produce y cómo se invoca para su ejecución. Los servicios, por tanto, están débilmente acoplados al programa cliente. Pueden ser invocados basándose en decisiones tomadas por reglas de negocio. Esto se traduce en un aumento de flexibilidad, ya que los desarrolladores pueden reemplazar un servicio por otro que haya sido diseñado para obtener el mismo resultado sin tener que preocuparse de su forma de trabajar interna, ni tener que cambiar la lógica interna de programas de aplicación monolíticas como ocurría en el pasado. Cada servicio se desarrollará con la intención de aportar valor al negocio de la organización de alguna manera. 

5.1. Capas de la arquitectura SOA 

Las capas en las que se estructura la arquitectura orientada a servicios son (Arsanjani, Borges y Holley 2004): 

Capa 1: Sistemas operacionales. Contiene sistemas o aplicaciones existentes, incluyendo aplicaciones ERP o CRM existentes, sistemas heredados e implementaciones de sistemas orientados a objetos, así como aplicaciones de inteligencia de negocio. SOA puede reutilizar sistemas existentes e integrarlos utilizando técnicas de integración orientadas a servicios. 

Capa 2: Componentes empresariales. Utiliza tecnología y diseños basados en contenedores y en desarrollos basados en componentes. Es la capa encargada de realizar la funcionalidad y mantenimiento de la calidad del servicio de los servicios expuestos.

 Capa 3: Servicios. Los servicios de negocio residen en esta capa. Pueden ser descubiertos o pueden ser enlazados estáticamente y después invocados o coreografiados en servicios compuestos. Esta capa de exposición de servicios también permite coger componentes empresariales (de la capa anterior), componentes de unidades de negocio, y en algunos casos componentes específicos del proyecto y externalizar un subconjunto de sus interfaces en forma de descripción de servicios. Los servicios existen aislados o en servicios compuestos. 

Capa 4: Composición de procesos de negocio. Define la composición de procesos de negocio a partir de los servicios de la capa anterior. Los servicios se introducen en un flujo a través de orquestación y coreografía, para ejecutar un proceso de negocio. Se pueden utilizar herramientas visuales de composición de flujos para el diseño. 

Capa 5: Presentación o acceso. Normalmente esta capa estaría fuera del ámbito de la SOA, pero debido a recientes estándares como Web Services for Remote Portlets versión 2.0 (OASIS Web Services for Remote Portlets 2003) se están convirtiendo en relevantes los servicios en la capa de presentación. Es importante resaltar que SOA desacopla la interface de usuario de los componentes.  Capas y componentes de una SOA (Arsanjani, Borges y Holley 2004) 

Capa 6: Integración de servicios (ESB) Posibilita la integración de servicios a través de la introducción de un conjunto fiable de capacidades como: enrutamiento inteligente y otros mecanismos de transformación, normalmente descritos como Enterprise Service Bus (ESB) (Craggs 2005). 

Capa 7: Calidad del servicio. Esta capa proporciona las capacidades necesarias para monitorizar, gestionar y mantener propiedades de calidad del servicio, como seguridad, ejecución y disponibilidad. Es un proceso de background a través de mecanismos de sentir-responder y herramientas para monitorizar la salud de las aplicaciones SOA incluyendo las implementaciones de WS-Management (Web Services for Management) y otros protocolos y estándares relevantes que implementan la calidad de servicio para una SOA. 

6. COMPOSICIÓN DE PROCESOS DE NEGOCIO: ORQUESTACIÓN DE SERVICIOS 

En la capa 4 de la arquitectura SOA explicada en el apartado anterior aparece la composición de procesos de negocio. Para entender mejor esta capa se van a introducir dos conceptos: Un proceso de negocio abstracto se define como un protocolo de negocio que especifica el intercambio de mensajes entre diferentes partes sin revelar el comportamiento interno de ninguna de ellas (Coreografía de servicios). Un proceso ejecutable especifica el orden de ejecución entre un número de actividades que lo constituyen, las partes involucradas, los intercambios de mensajes entre estas partes y los mecanismos de manejo de fallos y excepciones (Orquestación de servicios). Tomando como ejemplo una agencia de viajes, que programa un viaje a un cliente (proceso) consiguiéndole el vuelo y hotel más económico, pero a la vez que mejor se ajuste a sus necesidades. En este proceso la agencia tendrá que hacer uso de los servicios de varias compañías aéreas, para comparar condiciones y posteriormente elegir el mejor producto en función de los gustos y necesidades del cliente. Lo mismo ocurrirá con los hoteles. Los términos orquestación y coreografía describen dos formas de crear procesos de negocio mediante la composición de servicios web. Orquestación se refiere a un proceso de negocio ejecutable que puede interactuar tanto con servicios web internos como con externos. Las interacciones ocurren al nivel de mensajes, e incluyen la lógica de negocio y el orden de ejecución de las tareas. La orquestación siempre representa control de una de las partes, a diferencia de la coreografía, que es más colaborativa y permite a cada una de las partes involucradas describir su parte en la interacción. En el ejemplo indicado de la agencia de viajes, la orquestación se refiere al proceso estudiado de la planificación del viaje. Indicará en qué orden se va a planificar el viaje, si primero consigue el vuelo y después el hotel o viceversa, qué criterios sigue la agencia para descartar vuelos u hoteles ofertados, o criterios de calidad para comparar los productos ofertados por sus proveedores (compañías aéreas y hoteleras), etc. La propia agencia de viajes establece cómo se va a desarrollar el proceso, es decir, la lógica del proceso de negocio. La coreografía de servicios examina las secuencias de mensajes entre múltiples partes y fuentes, normalmente los intercambios de mensajes ocurridos entre los servicios web, en lugar de definir un específico proceso de negocio que una única parte ejecuta. En el ejemplo, indicaría en qué orden se deben producir los mensajes entre la agencia y las compañías de aerolíneas, por ejemplo. Es decir, el conjunto de conversaciones (secuencias de mensajes) válidos entre los participantes de la invocación del servicio web. La orquestación de servicios web debe ser dinámica, flexible y adaptable para descubrir necesidades de cambios de negocio. Una separación clara entre la lógica de proceso y los servicios web usados fomentan la flexibilidad. Un motor de orquestación puede conseguir esta separación. El motor maneja todo el flujo del proceso, llamando al servicio web correspondiente y determinando qué pasos se deben realizar. Un motor de orquestación de servicios web muy utilizado es el motor de BPEL. El lenguaje BPEL permite definir la lógica de orquestación entre los diferentes servicios web. Para que esto sea posible los diferentes proveedores de servicios web tienen que proporcionar los ficheros WSDL que contienen la información necesaria para poder invocarlos. Finalmente, la entidad encargada de la orquestación es el conductor, que va a ser el motor de ejecución BPEL. A diferencia de la coreografía, la orquestación de servicios web se basa en un modelo centralizado en el cual las interacciones no se realizan directamente entre los servicios web sino que existe una entidad encargada de definir la lógica de interacción. Además, los diseñadores de procesos deben ser capaces de componer servicios de alto nivel a partir de los procesos orquestados existentes. Exponiendo estos procesos a través de sus propios interfaces de web realizan este objetivo de combinación recursiva, mediante servicios compuestos. 

6.1. Arquitectura de integración: 

ESB Como implementación de esta capa de integración de la arquitectura SOA, aparece ESB (Enterprise Service Bus), que es una plataforma muy prometedora a la que se han apuntado numerosas empresas de software. Se trata de una implementación de arquitectura SOA, altamente distribuida, dirigida por eventos, cuyo último objetivo es la integración de aplicaciones heterogéneas y distribuidas. Es una plataforma basada en estándares que combina mensajería, servicios web, transformación de datos y enrutamiento inteligente para conectar y coordinar la interacción de un número significativo de aplicaciones de empresas extendidas con integridad transaccional (Craggs 2005). Se entiende por empresa extendida una organización y sus socias de negocio, que están separadas por límites de negocio y por límites físicos. En este tipo de empresas, las aplicaciones pueden estar separadas geográficamente, por cortafuegos corporativos o incluso por políticas de seguridad interdepartamentales. Los ESB se construyen en base a los siguientes principios fundamentales: Arquitectura orientada a servicios (SOA): Los ESB aplican una arquitectura orientada a servicios (SOA) que soporta las interacciones entre aplicaciones de colaboración que se basan en estándares mejorados de mensajería XML y servicios web. Esto permite que las interacciones entre áreas, unidades de negocio, e incluso interacciones con socios de negocios se definan en términos empresariales concretos y sólidos en lugar de hacerlo en interfaces de aplicaciones débiles y complejas. En consecuencia, los ESB pueden adaptarse y absorber cambios significativos sobre detalles de implementación de aplicaciones determinadas o servicios conectados a la arquitectura, es decir al bus. Eje central de comunicación a nivel empresarial: Los ESB deben ofrecer el eje central de comunicación a nivel empresarial necesario para conectar las aplicaciones de manera fiable a través de múltiples dominios geográficos, administrativos o de seguridad.  

Soporte para estándares: Al dar soporte a los métodos y mecanismos estándares para desarrollar e interconectar aplicaciones a través de la empresa, tales como WSDL, SOAP, los ESB reducen drásticamente el tiempo de implementación y el coste total de propiedad de los proyectos de integración. Enrutamiento inteligente. Los ESB automatizan el enrutamiento de las transacciones empresariales en base a contenidos de documento y a reglas empresariales XML. Esto elimina la necesidad de programar esta funcionalidad en el código de la aplicación o establecer relaciones rígidas entre dispositivos. Flexibilidad en la implementación y gestión distribuidas: Los ESB incluyen la capacidad de configurar, implementar y administrar los servicios que se distribuyen a través de la empresa de manera centralizada. A diferencia de un servidor de aplicaciones centralizado y monolítico o de las arquitecturas intermediarias (broker) de integración, los ESB proporcionan una óptima flexibilidad y, más aún, permiten una administración y escalabilidad de los servicios a nivel independiente, con el fin de alcanzar la mayor eficiencia operativa posible. La transparencia de ubicación permite que los servicios se actualicen, muevan o reemplacen sin necesidad de modificar los códigos de las aplicaciones. Arquitecturas dirigidas por eventos: enfoque arquitectural basado en utilizar eventos como disparadores que inician la distribución de un mensaje que informa a varios receptores acerca de un evento para que realicen las acciones pertinentes.

Estas arquitecturas tienen las siguientes características: - Desacopladas: la aplicación o servicio que envía el mensaje no sabe quiénes están suscritos a ese tipo de mensaje. La relación se establece por la información, es decir por el mensaje, pero no entre las aplicaciones. - Mensajería publicar/suscribir: ciertos sistemas publican información acerca de algún tipo de evento en la red para que otros sistemas (que se han suscrito y por tanto autorizado a recibir este tipo de mensajes) puedan recibir dicha información y actuar en consecuencia. - Asíncronas: Soporta interacciones asíncronas donde la información se envía sin que se espere una respuesta inmediata o se necesite mantener una conexión activa entre los dos sistemas mientras se espera la respuesta. En un ESB los datos se pasan entre los sistemas conectados al bus utilizando mensajes. La coordinación de mensajes se realiza mediante un concepto denominado enrutamiento basado en itinerarios. Un itinerario de un mensaje es un metadato que viaja junto al mensaje y proporciona la lista de direcciones siguientes a alcanzar por el mensaje. El itinerario es un conjunto de instrucciones que le dice al framework de ejecución del ESB a qué sistemas se tiene que enviar el mensaje y este viaja de sistema a sistema a través del bus. 

6.2. POA: 

Arquitectura Orientada a Procesos El objetivo perseguido por las organizaciones es centrar su arquitectura global en los procesos de negocio que realiza. POA identifica el proceso como la pieza central de la arquitectura (Smith y Fingar 2003). En realidad, POA utiliza SOA para la parte técnica, exponiendo la funcionalidad de la organización como servicios. En Leading Edge Forum Report (2003) se define POA como "la extensión de SOA para posibilitar el uso de procesos compartidos basados en servicios web, que están basados en compartidos servicios web definidos dentro de SOA trabajando en concierto con el resto". POA se construye sobre los fundamentos de SOA, si SOA se centra en los bloques de construcción (servicios), POA se centra en cómo construir algo con significado (procesos) utilizando estos bloques de construcción. Como estas arquitecturas están relacionadas, algunas organizaciones están pasando previamente a SOA, para más tarde ser capaces de pasar a POA más fácilmente.

FUENTE:

file:///C:/Users/Nataly%20Milena%20Orozco/Downloads/Dialnet-NuevasTendenciasEnSistemasDeInformacion-1945340%20(1).pdf
https://www.gestiopolis.com/teoria-de-la-toma-de-decisiones-definicion-etapas-y-tipos/
https://es.slideshare.net/beritza/sistema-de-informacion-gerencial-en-la-toma-de-decisiones