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: 
Now my own vision.

Regarding all the work an ESB has to do, putting service orchestration inside the main infrastructure element of your SOA is not a good idea.

Aggregate, ok! But keeping your communication channel busy with business logic will, for sure, cause a terrible impact in the ability to delivery other features.

After all, **most ESBs** such as as BEA Aqualogic Service have a **limited support for orchestration** including **lack of stateful** capabilities, and activities like wait (a timer) or pick (wait for some input to move on the process), split/join capabilities (already added on ALSB 3.0), and so on.

No way. Just use tools like a BPEL engine or a tool like Weblogic Integration.

Thanks.
Whenever you have two or more services that interact use service orchestrator, i.e. for composition and process control services. If you have esb expose this composition service on esb. Now if you have to compose new service that includes this composition service use orchestrator and again expose on esb.
Use esb as service delivery mechanism and web service broker and proxy. In composing a service orchestrator will use esb to reach interacting services. If these interacting services use incompatible xml schemas esb can transform/map them to common schema in runtime and route service requests based on the content, e.g. namespace.