Además, por parte de Oracle se continuará dando soporte a los productos de BEA que estén adquiridos, sin obligación de migración de los mismos por parte de los clientes.

Lo primero que resulta de esta fusión, es el Oracle Technology Network, resultado de las comunidades online de Bea (Dev2Dev) y de Oracle (Oracle Java Developer Community).

A nivel de productos, Oracle va a buscar completar una suite lo más extensa y perfecta posible en lugar de una estrategia de productos separados.

1. A nivel de SOA, según el Roadmap del producto, se distinguen 3 categorías:
   • Productos estratégicos : Productos de Bea que serán integrados directamente en Oracle Fusion Middleware, en un periodo máximo de 12-18 meses. Aquí se incluyen :
     • Oracle Data Integrator para integración de datos y ETL batch.
     • Oracle Service Bus, que unifica AquaLogic Service Bus y Oracle Enterprise Service Bus.
     • Oracle BPEL Process Manager para orquestación de servicios e infraestructura de composición de aplicaciones.
     • Oracle Complex Event Processor para procesamiento de eventos en memoria, integrado con WebLogic Event Server
     • Oracle Business Activity Monitoring (BAM) para monitorización de eventos de negocio y KPIs de procesos.
   • Productos a continuar y converger : Productos de Bea que serán rediseñados e incrementados para integrar con la suite de Oracle en un desarrollo continuo y mantenimiento por al menos 9 años. Aquí se incluyen :
     • BEA Weblogic Integration que convergerá en Oracle BPEL Process Manager
   • Productos a mantener : Productos de Bea que se continuarán manteniendo por un periodo de 5 años pero que no se busca integrar en la suite de Fusion. Aquí se incluyen :
     • BEA Cyclone
     • BEA RFID Server
2. A nivel de BPM, se intentará dar soporte tanto a BPEL para la ejecución, como BPMN para el modelado. Según Oracle hay 4 tipos de procesos de negocio : centrados en sistema, en tareas humanas, en documentos y en decisiones. Este punto es muy importante, ya que en el caso del BPM la estrategia a seguir en cuanto a la gama de productos de ambas plataformas, será la siguiente:
   • Productos estratégicos :
     • Oracle BPA Designer para modelado y simulación de procesos
     • BEA AL-BPM Designer para modelado iterativo de procesos
     • Oracle BPM, que convergerá como resultado de BEA AquaLogic BPM y Oracle BPEL Process Manager en un único motor de ejecución
     • Oracle Document Capture & Imaging para captura de documentos y workflows documentales con integración ERP
     • Oracle Business Rules como motor de reglas de negocio.
     • Oracle Business Activity Monitoring (como BAM)
     • Oracle WebCenter como interfaz de portal para visualizar la composición de procesos.
3. A nivel de Portales y Enterprise 2.0 tenemos por parte de Bea los productos de Aqualogic UI y Weblogic Portal. La convergencia en este caso será la siguiente:
   • Productos estratégicos :
     • Oracle Universal Content Management como repositorio de gestión de contenidos, seguridad, publicación, imagenes, registros y archivo.
     • Oracle WebCenter Framework para desarrollo de portal y servicios Enterprise 2.0
     • Oracle WebCenter Spaces & Suite como entorno de portal empaquetado con servicios de computación social.
     • BEA Ensemble para ensamblado de portales ligeros basados en REST.
     • BEA Pathways para analisis de interacciones sociales.
   • Productos a continuar y converger :
     • BEA WebLogic Portal que será integrado en el Framework WebCenter.
     • BEA AquaLogic User Interaction (AL-UI) que será integrado en el WebCenter Spaces & Suite
   • Productos a mantener :
     • BEA Commerce Services
     • BEA Collabra
4. A nivel de Gobernabilidad SOA la estrategia de conversión será la siguiente:
   • Productos estratégicos :
     • BEA AquaLogic Enterprise Repository para capturar, compartir y gestionar el cambio de elementos SOA a través de su ciclo de vida.
     • Oracle Service Registry para el UDDI
     • Oracle Web Services Manager para seguridad y gestión de políticas QOS en servicios.
     • EM Service Level Management Pack como consola de gestión para los niveles de tiempo de respuesta de los servicios y la disponibilidad de los mismos.
     • EM SOA Management Pack como consola de gestión para monitorización, traceo y gestión del cambio SOA.
   • Productos a mantener :
     • BEA AquaLogic Services Manager

Podeis oir el webcast del evento en inglés, directamente en la página de Oracle, obtener más información de los productos en la página de Fusion Middleware o simplemente esperar al 8 de Julio, que será cuando se anuncie el roadmap aquí en España.

Fuentes :

BPMS Watch
Column 2 by Sandy Kemsley
BEA Welcome and Oracle’s Middleware Strategy Briefing

2 días de presentaciones, demos y paneles de expertos donde se volvieron a reunir la mayoría de los fabricantes de productos SOA/BPM y diversas empresas de servicios implantadores de estas tecnologías.

Faltaron algunos de los grandes como Bea Systems o Software AG, aunque se pudo extraer de los asistentes un poco la evolución de los productos, novedades y, para mi lo más interesante, los casos de exito de diversas empresas ya "expertas" en implantación de tecnologías SOA/BPM.

Además, se entregaron los primeros premios SOA Awards que se llevó Vitria casi por duplicado (M30 como "mejor herramienta de integración" y el proyecto "SERVEI DE TELECOMUNICACIONS D´ANDORRA" como "mejor implementación SOA", con productos Vitria nuevamente).

Lo que si denoté en cierta medida y comentándolo con gente que también asistió al evento, es la reincidencia una vez más en cuestiones bastantes elementales como "qué es SOA y qué no es SOA". Fue algo que se pudo ver como parte de algunas presentaciones de manera repetitiva y que a estas alturas provoca hasta cansancio.

Creo que la empresa española (representada por la mayoría de los asistentes al evento) sabe de sobra qué es SOA; es algo que se les ha metido por activa y pasiva los últimos años en numerosas conferencias, eventos y demás presentaciones de mano de la jungla de proveedores del mercado.

Señores, implementemos SOA!! dejémonos de contar qué es y qué no es; creo que a estas alturas la mayoría de la gente ya tiene una idea bastante clara.
Creo que es el momento de dar el paso y comenzar proyectos con estas tecnologías. Incluso para proyectos ya existentes y "veteranos de SOA", habría que ir un poco más allá y empezar a implementar cosas como Gobernabilidad, BAM o Virtualización…

En fin, veremos a ver… ]]> http://www.espaciosoa.net/2008/04/30/soa-forum-2008/feed/ 0 http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/ http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/#comments Mon, 17 Sep 2007 19:45:06 +0000 Kike http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/ A menudo he visto en presentaciones, artículos e incluso charlas de diversos tipos, el uso indiscriminado de dos palabras que creo son necesarias diferenciar: Orquestación y Coreografía.
Yo mismo me he planteado serías dudas sobre el ámbito de cada palabra (e incluso ya esbozamos algo sobre el tema en algún momento) y con este post quiero por un lado aclarar ideas y dar pie a un posible debate sobre cuando debe utilizarse cada una.

Orquestación (Web Service Orchestration) y Coreografía (Web Services Choreography) se suelen ver como dos aproximaciones para la Composición de Servicios Web, pero tienen matices (la principal diferencia entre orquestación y coreografía es el alcance):

Si buscaramos la definición de Orquestación y Coreografía en un diccionario obtendríamos algo tal que así:

• La Orquestación es el estudio y práctica de ordenar la música para una orquesta. Es decir, consiste en decidir que instrumentos deben tocar qué notas en una pieza de música.
• La Coreografía es la ordenación y movimiento de los bailarines en el escenario. Es decir, consiste en decidir como debe ser el movimiento de los bailarines en el escenario al ritmo de la música.

Después de estas "definiciones" podríamos hablar de similitudes entre orquestación y música; al igual que de coreografía y danza (o bailarines). El problema es que esto no termina de dejar claro las similitudes y diferencias entre Orquestación y Coreografía aplicadas a los Servicios Web.

Cuando hablamos de Orquestación, debemos hablar de WS-BPEL y por tanto de procesos ejecutables. Es decir, la Orquestación podría verse como la ejecución de un proceso de negocio definido en WS-BPEL y que puede ser ejecutado por un motor BPEL.
Cuando hablamos de Coreografía, debemos hablar de WS-CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web.
Hay que verlo desde una perspectiva distinta, WS-BPEL (Orquestación) es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). Y WS-CDL (Coreografía) es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios proceso particulares (varios flujos de control).

WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web. La Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores. Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio (por ejemplo, BPSS – Business Process Specification Schema)) de diversos servicios web.
Por el contrario, WS-BPEL se centra en la composición de nuevos servicios a partir de otros ya existentes. BPEL nos proporciona una manera de describir el comportamiento interno de qué necesitan los servicios para trabajar conjuntamente y así poder crear otro servicio como composición de los primeros.

No se si queda claro o simplemente genera más confusión. ¿Que opinais al respecto?

Links interesantes:

Web Services Orchestration Using BPEL
Service Orchestration vs. Service Choreography by John Reynolds
What is… choreography? What is… orchestration? on Digital Walkabout
OASIS Web Services Business Process Execution Language (WSBPEL)
WS-Choreography Definition Language (WS-CDL)

Los capítulos de cada informe incluyen:

• Visión general del fabricante y el producto.
• Entorno y Arquitectura.
• Estructura y Datos de Procesos.
• Diseño y Modelado de Procesos.
• Flujos de trabajo con interacción manual.
• Experiencia de Usuario y Gestión de Tareas.
• Framework de integración.
• Reglas de Negocio.
• Contenido, Colaboración y gestión de casos.
• Eventos y Excepciones, gestión del Rendimiento.
• Servicios y Soluciones del Fabricante.

Actualmente están disponibles los informes de Appian, BEA, Cordys, FlowCentric, Global 360, Tibco y WebMethods. Proximamente se añadirán los de Adeptia, EMC, IBM, Lombardi y Oracle.

Ya sabes, si quieres estár informado sobre las últimas suites de BPM de los principales fabricantes (personalmente creo que faltan algunos), no dudes en pasarte por la página del BPM Institute (es necesario registrarse para descargar los pdf; pero si alguien no quiere y los necesita que me deje un comentario y se los mando).

También tienes disponible el BPMS Report 2006.

BPEL es un lenguaje ejecutable con sus variables y operaciones. Las operaciones permiten enviar y recibir mensajes SOAP y tiene un gran soporte para XML y transformaciones XML. Además, permite de manera fácil invocar múltiples servicios web al mismo tiempo y sincronizar los resultados.
BPEL no tiene soporte gráfico; es decir, no especifica como deben ser los diagramas interpretativos de los procesos que define.
El objetivo de BPEL es ofrecer una forma de orquestar servicios web, la secuencia de interacciones subyacente y el flujo de datos punto a punto.

XPDL, por su lado, especifica un formato de diseño de los procesos. Permite una representación gráfica de los procesos incluyendo coordenadas X e Y para cada nodo implementado. Además, los nodos pueden especificar atributos tales como roles, descripción de actividades, timers, llamadas a servicios web, etc… Suele ser preferido cuando se trata de implementar procesos o workflows con interacciones humanas, ya que en esto supera a BPEL (para soportar interacciones humanas, BPEL necesita de añadidos a la especificación, lo cual dificulta su portabilidad ya que suelen ser implementaciones propietarias de cada proveedor).
El objetivo de XPDL es almacenar y permitir el intercambio de diagramas de procesos. Intenta ofrecer una manera estándar para representar procesos de tal manera que puedan ser importados/exportados por cualquier editor que implemente el estándar.
XPDL 2.0 tiene extensiones que permite representar todos los aspectos de BPMN.

A veces, el intercambio de procesos BPEL entre distintas herramientas no es todo lo satisfactorio que se desearía (ya que cada proveedor implemente BPEL “a su manera”; incluso cuando el objetivo inicial de la especificación era la unificación en la forma de implementarlo).
Por el contrario, XPDL en su representación de BPMN si es transportable de una herramienta a otra (ya que luego cada proveedor realiza su conversión de XPDL a BPEL según necesite; o incluso ejecuta XPDL de forma nativa). Por eso, XPDL se puede establecer como un formato ideal para intercambio de procesos entre distintos proveedores que transformarán los desarrollos al formato BPEL adecuado a sus necesidades.

BPEL y XPDL no son competidores entre sí, ya que pueden ser complementarios según el uso que se haga de ellos. De hecho, a partir de un modelo BPMN podemos pasar a un proceso BPEL ejecutable por un motor de una herramienta.
Igualmente a partir de un proceso BPMN podemos obtener una implementacion XPDL (de hecho, desde la versión XPDL 2.0 esto es inmediato en ambos sentidos) que puede ser ejecutada por algunos motores de forma nativa. La desventaja del paso de BPMN a BPEL es que no siempre se puede hacer el camino inverso (lo que dificulta la exportación/importación entre herramientas). Pero tampoco hay una necesidad imperiosa de ello: BPEL y XPDL están pensados para cosas distintas; pero pueden ser complementarias si se utilizan de esa manera.

Es interesante la aproximación a la cadena de valor BPMN-XPDL-BPEL que se detalla en el artículo “Understanding the BPMN-XPDL-BPEL Value Chain” de Nathaniel Palmer:

1. El usuario genera un diagrama con notación BPMN del proceso que quiere construir.
2. Se guardan los diagramas parciales como XPDL durante el desarrollo. En el caso de XPDL 2.0 esto es inmediato.
3. Finalmente se traducen ciertas partes a BPEL (básicamente en lo que a intercambio de datos se refiere, no a interacciones humanas donde BPEL no es adecuado ya que necesita de modulos específicos que son diferentes en su implementación por los distintos fabricantes).

¿Qué creeis? ¿Habéis utilizado alguna vez alguno de estos estándares?

Espero que cuando menos se hallan disipado alguna de las dudas acerca de las tres implementaciones más conocidas de que disponemos para crear Procesos de Negocio.

Links interesantes:

The BPMN-XPDL-BPEL value chain (Go Flow)
Recursos XPDL (WFMC)
Recursos BPMN (OMG)
Recursos BPEL (OASIS)

Os dejo aquí, un Póster de notación BPMN bastante completo; realizado por la Universidad de Maribor, concretamente la Facultad de Ingeniería Eléctrica y Ciencias de la Computación, en el Instituto de Informática; en Eslovenia.

(Visto en Go Flow)

Links interesantes:

BPMN Information Home
Introduction to BPMN
Explicación Wiki de BPMN (inglés)
BPMN Supporters

WS-BPEL (también conocido como BPEL4WS o simplemente BPEL) es un lenguaje de composición de Servicios Web Orientado a Procesos. Se basa en los WSDL (Web Service Definition Language) y de hecho un proceso WS-BPEL puede ser expuesto a través de su propio WSDL y por tanto ser invocado como cualquier otro Servicio Web (permitiendo la reutilización de los mismos).

Nació como combinación de WSFL (Web Service Flow Language de IBM, orientado a grafos y basado en el control de los links entre tareas) y XLANG (Web Services for Business Process Design de Microsoft, basado en un control de flujos con secuencias, condiciones, bucles, etc…) y ha evolucionado adquiriendo lo mejor de cada uno e intentando evitar las malas prácticas de los mismos (debido a que el paradigma de utilización de ambos es distinto y a veces de lugar a situaciones de construcción sobrelapadas).

WS-BPEL define un conjunto de tareas básicas para la Composición de Servicios Web:

• Tareas de Invocación (Invoke): Invocación de operaciones one-way o request-response en un servicio web.
• Tareas de Recepción (Receive): Permite el bloqueo de un proceso a la espera de llegada de un mensaje.
• Tareas de Respuesta (Response): Permite enviar un mensaje en respuesta a un mensaje recibido previamente.
• Tareas de Espera (Wait): Permite la espera durante un tiempo del proceso.
• Tareas de Asignación (Assign): Permite copiar datos de un lugar a otro.
• Tareas de Lanzamiento (Throw): Permite indicar que ha ocurrido un error.
• Tareas de Finalización (End): Permite finalizar la orquestación de la instancia en curso.

Además, las tareas estructuradas son utilizadas para combinar las primitivas en otras más complejas:

• Tareas secuenciales (sequence): Define un orden secuencial de tareas.
• Tareas de decisión (switch): Permite seleccionar un camino en particular en base a una condición.
• Tareas de elección: Permite bloquear y esperar la llegada de un mensaje o establecer un tiempo límite de espera (timeout). Cuando uno de los eventos ocurre, se ejecutan las tareas designadas.
• Tarea repetitiva (While): Permite repetir un grupo de tareas mientras se cumpla una determinada condición.
• Tareas paralelas: Permite paralelizar la ejecución de cierto grupo de tareas.

WS-BPEL trata todos los estados como una colección de tipos de mensajes WSDL. Esa colección de mensajes que constituyen un estado es lo que se llama contenedor. Los mensajes de un contenedor pueden ser los enviados o recibidos con clientes o servicios externos; incluso los utilizados internamente por el proceso para computación temporal de los mismos. Asimismo, la comunicación se define a través de los PortType de los WSDL.

WS-BPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno de los cuales tiene una definición de esquema. Así, un mensaje se corresponde a un contenedor, que básicamente es un servicio web con información adicional sobre como procesarlo, posibles pre-condiciones y post-condiciones.

De modo gráfico, un proceso definido en WS-BPEL tendría la siguiente forma:

Todos los accesos a datos y manejos de los mismos en WS-BPEL es definido utilizando estándares como XPath y XSLT, además de basarse en los contratos de servicios establecidos por medio de los WSDL.

Durante la ejecución de un proceso se pueden establecer más de una conversación con servicios externos, por lo que es necesario establecer mecanismos a nivel de aplicación para corresponder los mensajes y conversaciones con las instancias de procesos que sean objetos de los mismos. Para ello, WS-BPEL ofrece lo que se conoce como “Correlation Sets” o Grupos de Correlaciones. Estos son conjuntos de propiedades, que juntos sirven para definir una conversación a nivel de aplicación dentro de una instancia de proceso. Básicamente son identificadores únicos de instancias de proceso, que permite saber en todo momento que instancia corresponde a qué mensaje recibido o enviado a través del mismo.

WS-BPEL puede ser utilizado tanto para orquestación de servicios (llamadas a procesos ejecutables; entendiendo como tal las llamadas a servicios y la especificación de como se llevan a cabo) como para coreografía de servicios(llamadas a procesos abstractos; entendiendo como tal los mensajes públicos a intercambiar entre dos o más partes).

Por lo general, la implementación de WS-BPEL varia según el fabricante y de hecho algunos lo interpretan como un Script XML que puede ser ejecutado con un motor específico; mientras que otros lo interpretan como un lenguaje de intercambio. La última especificación, la 2.0 incluye nuevas características como inicialización de variables, transformación XSLT de variables, acceso XPath a datos de variables, etc… No obstante, la especificación 1.1 es la más estable y en uso todavía por la mayoría de los fabricantes, ya que la 2.0 ha sido recientemente aprobada el 31/01/2007 por OASIS y todavía está siendo preparada para su publicación definitiva.