Durante los últimos años, en gran parte debido al auge de las arquitecturas SOA, las soluciones para la orquestación y coreografía de procesos han experimentado un importante posicionamiento entre las tecnologías de interés. Esta situación se materializó en un baile de estándares emergentes y poco maduros (BPML, BPMN, XLANG, WSCI, WSCDL, XPDL, BPEL…) y complicó mucho la tarea de seleccionar la tecnología por la que apostar para la gestión de los procesos. A la promesa clásica de este tipo de sistemas, esto es desacoplar la lógica de negocio de la lógica de las aplicaciones, se añadió un conjunto de nuevas expectativas encaminadas a proporcionar a los analistas de negocio nuevas herramientas que les permitieran describir los procesos de sus organizaciones de forma ágil, flexible, sencilla… e incluso ejecutable.
A día de hoy, tras fusiones, abandonos, evoluciones y campañas de marketing podemos decir que hay tres supervivientes dentro de este conjunto de estándares:
BPMN un potente estándar no ejecutable que permite representar todo tipo de flujos de control imaginables y que se alza como alternativa para la representación gráfica de todo tipo de procesos. Por desgracia gran parte de estos flujos no tienen forma de representarse en los estándares ejecutables permitiendo diseñar, sin demasiada dificultad, escenarios interbloqueantes, con realimentaciones infinitas, ramas imposibles y todo tipo de efectos secundarios. Por último reseñar que no permite capturar de forma explícita y estándar conocimiento de negocio.
XPDL, en su versión actual, se nos presenta como alternativa a la modelización no estructurada de procesos de negocio, se encuentra relativamente cercano al modo en el que se supone que los analistas de negocio idean los nuevos procesos de sus empresas (siempre y cuando estos analistas piensen con diagramas de flujo) y permite incorporar de forma explícita algunos conceptos empresariales básicos. De todas formas este nivel de abstracción teóricamente alto desaparece en cuanto hay que concretar aspectos que permitan la posterior ejecución del proceso. Llegados a este punto el estándar deja de serlo y comienzan a aparecer numerosas extensiones dependientes de la plataforma de ejecución, además su nivel de abstracción disminuye ostensiblemente dificultando el desarrollo y modelado de procesos por parte de personal no técnico.
Por último BPEL aparece como opción para la composición de WebServices (WS*). Debe verse como un lenguaje de programación que permite la construcción de WebServices a partir de la composición de WebServices mas sencillos. Para esto emplea un lenguaje estructurado con ciertas características que tratan de acercarlo a los lenguajes de definición de procesos, como puede ser la sincronización o la compensación de actividades. Como contrapartidas comentar que no contempla la interacción humana en los procesos (sólo permite interacciones entre WebServices), las dificultades que encuentran los usuarios sin conocimientos algorítmicos con el diseño estructurado y que no permite dar solución a un escenario general de gestión de procesos.
Los tres estándares han pasado de luchar por alzarse como la única opción para dar respuesta a las necesidades de la gestión de procesos de los sistemas empresariales, a coexistir de una forma más o menos amistosa. Ya no es extraño ver a los tres tomar sus posiciones en arquitecturas en las que se diferencia bien entre las capacidades y el ámbito de aplicación de cada uno de ellos. De todos modos y pese a la combinación de sus fuerzas continúa siendo muy discutible hasta que punto cumplen las expectativas y promesas que han generado, haciéndonos pensar que la solución definitiva a estos problemas aun no está disponible.
