James McGovern has some excellent questions on his blog.
I could write pages on some of the questions but I thought I'd limit myself to just two for now.
"When should one use BPM with an ESB?"
I think this question probably reflects the multiple inconsistent definitions used by all the vendors and analysts out there. In my view of the world, the ESB is the construct that says to the world: "You need to send some information to an application? You need to invoke an application? I'm the man. Send the request to me - in the way that makes most sense to you - and I'll take care of making it happen, in the way that makes most sense to the target application".
So, by this 'definition' it exposes services deployed in the enterprise in a way that is independent of how the services are actually implemented and it does it in both synchronous and asynchronous cases.
By contrast, BPM is the orchestration layer that sits above this. This is the layer that says: "Great! All the enterprise services I may ever need to invoke are all easily accessible via the bus. Now I can deliver some extra business value by wiring some of them together to automate a business process. I'll involve a few humans here and I'll emit monitoring information there and the result will be an end-to-end automated business process."
Now, a particular vendor's product my conflate the two worlds but, at an architectural level, they are very different.
ESB is about exposing services
BPM is about chaining them together (and more... true BPM involves people)
ESB is worried about technical details
BPM is worried about business process, key performance indicators and monitoring.
So, I would argue one implicitly uses an ESB whenever one is doing BPM.
"What's the difference between Interoperability and Integration?"
Excellent question. I agree with James that there is a difference but until now, I, too, had never tried to articulate what it was.
Here's my first stab (and I stress that this is a first pass.... I'm not totally happy with it)
If two systems are interoperable, we mean that they are capable of working together. Consider SAP: two SAP systems are interoperable.
However, two systems being capable of working together is merely a statement of fact. It says nothing about how you do it.
Two SAP systems can be integrated by configuring them to fire IDOCS at each other (or in one of all the other possible ways). Moreover, to achieve true integration, you may require the assistance of some extra technology (home-grown code, an EAI product, an ESB, whatever).
So: I would say that interoperability is a statement of the possible. Integration is how you do it.