It's a fairly high level concept of abstraction. The central concept is that the ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code.
This could include mediation to reconcile incompatible protocols, data, and interaction.
The idea of a central bus on which everything passes gives opportunity for additional layers of abstraction. Using industry standards to "plug" other applications, clients, and such into this bus makes it so that connecting new services, data sources, clients with disparate needs is relatively easy.
Actual implementations
As far as actual implementations, that's the domain of very large enterprise support businesses. While it's very buzzwordy, the goal is an ideal that on some small level can be understood through comparison with the internet:
Similarity to Internet
One big communications bus with widely different uses and data, but all running standardize protocols.
One can, in fact, write an HTTP to FTP connector that would allow browsers to access FTP sites without invoking an FTP client (usually built into the browser now).
Mashups
Mashups demonstrate an interesting implementation - take some bus route data from the San Francisco authority, map from google, and sushi bar locations from yahoo with ratings and run a simple query that gives you the closest sushi bar, weighting it so that you'd be willing to travel a little further for a better bar.
All completely different services, incompatible by themselves, but using standard connectors (yahoo pipes, for instance) they can be pulled together into a cohesive and useful whole.
-Adam
You can use a transformation broker without a service bus, and vice versa. In terms of specific products I don't think any one is purely one or the other because of the way each complements the other. Some products are stronger in the one area, other stronger in another. Perhaps a choice needs to be made based on which function best covers an individual problem.
A broker may have better built-in "lego blocks" for constructing a transformation chain than an ESB product does. A broker pressed into service as an ESB may be crushed under load and not scale well, or may lack robust journaling and tools for dealing with journals.
Some ESBs allow database updates to be rolled back and queues to be replayed into a corrected application once an egregious error in logic has been uncovered and fixed. I don't think most brokers integrate that level of transactional support. For this to work at all your "transactions" almost have to be business events (a sale, a renewal, a change of ownership, etc.) rather than something like RPCish "database updates."
Best Answer
Yes and no. There's a thin, and sometimes indistinguishable line between orchestration and aggregation/service augmentation.
In general, if you've got any long-running or complex business process (process being the key word, although I'm going to avoid defining it) - that's best suited to BPEL.
Simple tasks, such as aggregating the results of three service calls, could and often should be done in an ESB layer.
It's not worth losing too much sleep over, though
Disclaimer: I am an IBM ESB consultant, although I'm not writing this in an official capacity.