I explained that one school of thought, which I share, is that workflow doesn't run in an ESB, but it should implement its activities as service consumers and use an ESB to invoke the providers. This has been my view for several years now, since before we started to refer to all of this messaging connectivity as ESBs.
This explanation is consistent with the feature set in IBM's SOA and ESB products: WebSphere Process Server, WebSphere Enterprise Service Bus, and WebSphere Message Broker (aka the Advanced ESB). Remember that WPS is built on top of WESB. Here's a diagram of the component model in WPS/WESB:
WebSphere integration product family
All of this is in WPS. As I explained in Better WBPM Pictures, what this diagram doesn't show very well is how much of this is in WESB. WESB contains the SOA Core components and the Mediation Flows component, but none of the other Supporting Services or Service Components.
So WESB contains Mediation Flows, but only WPS contains Business Processes. That's the major difference between the products: WESB does mediation flows, but not business processes. Business process is outside of the ESB. Similarly, Message Broker does message flows but not workflow.
So the IBM ESB products are consistent with my previous explanation. They do mediation flows but not workflow. Workflow is generally considered to be functionality outside of ESBs.