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?