Entiendo perfectamente lo que dices, porque he llegado a encontrarme con el mismo problema. No obstante, a la referencia de porqué no se usa BPEL o XPDL como motor de ejecución de un ESB yo creo que es porque están pensados para cosas distintas.

En realidad, si un proceso se considera de negocio (habría que intentar definir que se entiende por esto; y yo creo que realmente aquí es donde está la diferencia), aunque se pueda construir en un ESB como un proceso short running, no necesariamente implica que sea el mejor sitio. Si es verdad que por lo general, un motor BPEL llega a consumir y requerir más procesamiento que un flujo de un ESB montado, por ejemplo, encima de MQ. Por ello, a veces, el implementar un proceso de negocio muy simple y rápido en un ESB puede ser la solución más rápida y que mejor cumple los requisitos de rendimiento.

Pero no hay que olvidar que la función del ESB es principalmente integradora por medio de comunicación multiprotocolo y transformadora. Si el proceso a desarrollar requiere lógica de negocio, mi observación es que debería ir construido necesariamente en un motor BPEL.

Por ejemplo, una simple transformación de datos de un Modelo de Datos Común a un Modelo de Datos Particular de un servicio no necesita implementarse con un BPEL, puede ser perfectamente desarrollado como un flujo de un ESB (como un proxy del servicio). En este caso no hablaría de Proceso de Negocio sino más bien de Proxy de Servicio o Servicio de Negocio. Pero si además, necesitamos orquestación de servicios o interpretación de los datos de negocio, creo que debería transferirse su desarrollo a un motor BPEL.

Aunque en un ESB se puedan hacer, a veces, las mismas cosas que en un BPEL, creo que el plano del Bus de Servicios debería ser a un nivel técnico y en el BPEL a un nivel de negocio (en lo que al manejo de la información se refiere). El tenerlo bien diferenciado permite saber donde realmente debe encajarse.

Por ello, las herramientas de BAM suelen integrarse directamente con los BPM y no con los ESB; porque el manejo de la información de negocio, su manipulación e interpretación se hace en los procesos BPEL y no en un bus de servicios que suele utilizarse para solventar los problemas de integración de las distintas aplicaciones o sistemas de una Arquitectura Empresarial (problemas siempre a nivel técnico).

La existencia de un flujo en un ESB puede también ser denominada como un proceso de “short running”, es decir, pueden ser procesos de negocio que tienen un tiempo de vida de ejecución muy corto. En este caso, es un proceso de negocio el que se ejecuta en el ESB, por lo que deberíamos ser capaces de monitorizarlo.
Con esto lo que quiero decir es que no solo es un tema técnico lo que va en un ESB, sino que a su vez puede ser un proceso de negocio, típicamente sin interacción humana y además que se ejecuta rápidamente. La cuestión es que realmente si son procesos de negocio lo que va en un ESB, ¿No debería ser BPEL o XPDL su motor de ejecución? En fin, esta es una guerra (abierta) que tengo con mis clientes y aún no tengo una respuesta clara.