Bom amigos vamos fazer como o Jack, por partes:
ESB: Já explicaram seu papel, finalidade e vamos a alguns fatos: Muitos produtos possuem performance fantástica. O Mule possui processamento SEDA - http://www.eecs.harvard.edu/~mdw/proj/seda/ assim como o Apache Camel para Assíncrono entre outros.
Participei de um projeto que um fluxo era coreografado pelo ESB com 15 serviços diferentes e não levava 2ms para processar toda a operação - pasmem !! Claro que isso leva em conta o excelente Hardware também, mas no geral ESB tende a ser muitíssimo performático, afinal foi criado com esse propósito.
Aliás, fui o arquiteto pelo lado da Oracle-partner, responsável por esse case: http://www.oracle.com/customers/snapshots/grupo-stp-weblogic-snapshot.pdf , que acabei de citar.
Quem usa hoje ? Diversas Teles, como Tim, Claro e só pra citar um exemplo recente a Vivo está fazendo uma promoção junto com a Globo que deve passar dos 4 milhões de requisões por minuto em período de pico e toda a infraestrutura está apoiada no OSB - antigo ALSB (Aqualogic Service Bus).
[Acomplamento: [quote]Alto lá… o que eu quis dizer foi que deve-se EVITAR composição de serviços, pela lentidão de desenvolvimento (acho que me expressei mal, anteriormente).
[/quote]
Na verdade hoje há outras maneiras de se manter o mesmo nível de produtividade olhando para serviços e a arquitetura RESTFul está aí pra mostrar isso.
Forte acomplamento te inibe na flexibilidade, se precisar extrair funcionalidade terá que “desacoplar” e isso é um parto de fazer. Alto acomplamento é necessário para casos específicos que exigem muita performance.
BAM: Há muitos produtos para o propósito, alguns mais performáticos outros menos, mas para a área de negócio como o Alexandre mencionou, é vital e o ganho de ter a visibilidade paga com folga os pentes adicionais 