Question: **Is an Enterprise Service Bus** (a tool that acts as a mediator, a message broker, a service enabler, schema transformation enhancer, transparent location provider, service aggregator, load balancer, monitor, and all that stuff) **responsible to orchestrate services**?

What about putting an automated business business process with more than thousand steps and dozens of service invocations inside your enterprise service bus?

Would you do it, or would you use a specialist in orchestration such as a BPEL engine?

Please gimme you opinion.

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.
No, an ESB's responsibility is not the orchestration of services (per se).
The ESB provides a layer of abstraction at the "software infrastructure level".

This means that an ESB is a "single logical abstract port of call for connectivity" with any service that is published on the bus.

The ESB being abstract, means that consumers of services on the bus, don't "need to know" deployment details of the service, and it is possible to expose "internally facing services" with a single document model. The ESB provides low level services (such as protocol translation and message transformation), so that internally services can communicate in a simplified fashion.

This implies some orchestration: The ESB provides orchestration of the afore mentioned low level services (e.g. when service X is called via IIOP, translate this to SOAP with Attachments. Then transform the request from whatever serialized data to an XML payload).

The orchestration you would typically avoid in an ESB is: In order to process this (insurance) sale, we first need to validate the information provided by the buyer, then we need to underwrite the risk of insuring, and finally calculate the premium that needs to be paid for the insurance, after which we need to… etc.

The steps described above are clearly a business process (which could even be interrupted… e.g. if automatic underwriting is not possible, then a human underwriter needs to further assess the risk).

Business Services (e.g. Validation, Underwriting, Premium Calculation) that make up a Business Process (e.g. Insurance Sale), which is what is typically referred to as Orchestration, is best suited to happen in a Business Process Engine and defined using a formalized Business Process Modeling Language (such as BPEL).

Also making a guess about the many steps in your process: In the above example, Validation is a (course grained) service. The validation rules themselves are internal to that service. For complex business rules (i.e. not business process), the use of a Business Rules Engine may be required.