BPM and ESB

Can anyone help me understand how (or if) ESB fits in a BPMS?  In the mountains of blather you can Google on either topic I can’t find anything that makes sense about how the work together!  In fact, the more I try to understand ESB the confuseder I get.  For clarity, let’s just consider BPEL-based BPMSs like IBM, Oracle, Intalio…  Is ESB an inherent/invisible capability of these offerings (I think not) or something that can be added on in some implementations (I think so, but not sure)?  What do you get with the ESB version that you don’t with the non-ESB version?

There seems to be redundancy between what the BPMS provides and what the ESB provides, including integration adapters, data transformation tools and engines, and of course a BPEL tool and engine.  So are they sort of the same thing (except for BPMS’s “business-oriented” things like process modeling, performance management, and business rules that no self-respecting SOA Architect would be caught dead worrying about)?  I don’t think so.

A few things come to mind.  One is synchronous vs messaging-based connection to services.  Is it correct to say that BPMS integration adapters without an ESB just provide synchronous connections?  (Except for JMS or MQ adapters, I suppose).  To connect asynchronously over the network you need either an old-school message bus or an ESB.  Is that right?

Another is centralized vs distributed intelligence.  In BPMS the process engine is the centralized brain of the process.  That’s fundamental.  In the ESB literature they talk about distributing intelligence to nodes in the bus (“content-based routing”) or even to the service endpoints.  Anything else, we’re told, is “hub-and-spoke”/”can’t scale” architecture.  I.e. without an ESB, BPMS can’t scale.  Can that be right?  It makes ESB sound like those 1990s-era message brokers that BPMS was supposed to be a step up from!

And then there is the business services/loose coupling thing.  This at least makes sense conceptually (sort of), although I don’t know if people are actually doing it.  Network Computing’s review of ESB Suites in March talks about the 3 layers of SOA, the lowest being coding of services or “service-enablement” of existing systems, the middle being “service orchestration” to create coarse-grained “business services”, and the highest being “process orchestration” to create business processes.  Network Computing assigns ESB to the middle layer — orchestrating low-level services into larger service units which will be exposed to the business for use in processes — and BPMS to the top layer.  At least that idea computes in my brain, but it’s not obvious why the technical features ESB provides, like message transformation and queuing, are more relevant in the middle layer than in the top layer.

Others have described ESB in a loose coupling context.  In BPMS, the argument goes, services are not really pluggable since each has a distinct signature or request/response schema.  In BPEL terms, that means you have to change the Assign activity before the Invoke — big deal.  The better way that ESB supposedly allows is that BPMS can invoke the service through a generic interface (maybe using some industry-standardized vocabulary) and entrust the mapping to the endpoint-specific interface to the ESB.  Kind of like Crossworlds or Vitria used to do, or some EAI.  Is that what ESB is about?

I’m looking for feedback here.  Anyone?