Kenobi,
Primeiro vou responder suas perguntas … depois passo para a exploração dos pontos de vista discordados 
“Acho o recurso bacana não sei o porque tiveram que usar uma implementação de Custom, mas seria legal detalhar os problemas que teve, até para base de experiência”
Na época, parte do processo de negócio requeria que algumas informações do Siebel fossem recuperadas durante o processamento da mensagem, pois esta deveria ser “enriquecida” com detalhes sobre o cliente que iriam sustentar decisões na cadeia de processamento adiante. Tentamos utilizar o conector do Siebel que a própria Oracle fornece, mas algumas questões de desempenho foram relevantes, o servidor Siebel não estava aguentando as requisições enviadas a ele (a partir do conector próprio) pois o número de requisições planejadas para o servidor do Siebel eram inferiores as chamadas enviadas pelo AquaLogic ESB. Ai tivemos que criar um Custom Transport para fazer esse “Message Enrichment”. Quanto a esse ponto, tudo ocorreu bem até, o SDK é muito simples de usar e funciona bem quando você adota as recomendações da BEA.
“Flow Control é a orquestração-coreografia, e não entendi o pq questionável, já que é um dos melhores recursos da ferramenta”
Você sabe o que são trade-offs? Quando você projeta um software, a sua maior preocupação como projetista / arquiteto de software é mensurar, avaliar e acomodar o maior número possível de requisitos não funcionais da solução. Você deve conhecer os RNF mais clássicos portanto não vou citá-los aqui (na duvida consulta a ISO 9126), e deve saber também que, em qualquer projeto de software médio ou grande, RNF conflitam. Performance muitas das vezes conflita (em termos de peso e aderência) com interoperabilidade assim como facilidade no desenvolvimento (em tempo de projeto) conflita com escalabilidade da aplicação em tempo de execução. Dito isso, qual meu ponto ao afirmar sobre ser questionável o recurso de orquestração da ferramenta?
Como disse no cenário, ao originalmente optarmos por adotar esse “poderoso” recurso do AquaLogic em pró de estimular maior produtividade no desenvolvimento (que concordo com você, é bem produtivo), acabamos nos adentrando num problema de desempenho que, para ser solucionado, tivemos que abrir mão da produtividade em pró da performance, criando uma série de Java Callouts para os estágios (você conhece este termo né ;-)) mais complexos. Como projetistas, temos sempre que fazer bom uso dos RNF dos usuários, mas devemos saber quando abrir mão de certos RNF em pró de outros. Na época, a dosagem de peso se deu em maior quantidade para a performance, e nem tanto para a produtividade. Produtividade é importante? Claro que sim! Se você é uma fábrica de software por exemplo, fazer software mais rápido significa faturar mais horas do que as negociadas com o cliente, e isso é bom com certeza. Mas as decisões arquiteturais devem balizar muito mais a qualidade da aplicação do que a qualidade do desenvolvimento da aplicação. Quando ambos são possíveis, ÓTIMO! Mas quando não são, temos que sacrificar um pelo outro.
Como dica, recomendo fortemente a leitura do livro “Evaluating Softwares Architectures”, criado pela equipe do SEI, que explica, entre outras coisas, um método de avaliação de RNF chamado de ATAM, sigla de “Architecture Trade-Off Method Analisys”. Na época, meu caro Kenobi, usei o bom senso praticado pelo ATAM para decidir sacrificar o recurso. E como consequência da experiência em questão, criei esta opnião sobre o recurso visual da ferramenta: Ela é muito legal e trás produtividade, mas ela trás consigo uma série de problemas técnicos que devem ser corretamente avaliados. XSLT é um recurso poderoso, mas é caro em termos de processamento. E infelizmente é a estratégica técnica que está por trás do editor visual. Hoje, na versão 3.0 do Oracle Service Bus, existe a forma de lidar com esta limitação técnica, que é usar implementações alternativas de XML parsing baseadas em SAX e não em DOM, assim como compreensão de XML baseado em Stax. Em suma, quando eu avalio uma ferramenta, eu não tenho comigo somente a impressão inicial que me vem aos olhos, eu avalio também as consequências da aplicação de uma dada tecnologia. Com base nisso, crio minhas opniões. Ou seja, concordo com você quanto a produtividade do recurso, mas quando ponderado com demais RNF, não tenho tanta certeza quanto a importância do mesmo
“Aqui vou discordar de você, pois usabilidade é o que faz a produtividade de uma equipe ser completamente diferente”
Como mencionei antes, produtividade é sim algo muito importante, mas quando temos outras prioridades a serem avaliadas, eu coloco a produtividade como o item de menor prioridade pois me concentro nos detalhes da aplicação. Salvo que eu esteja num projeto com prazo curto e um gerente de projetos na minha cola me ligando num sábado as 17:30 pra saber como estão os testes unitários da entrega da próxima iteração, eu não considero tempo de desenvolvimento e produtividade como algo mais importante que os demais RNF clássicos. Mas assim cara, eu respeito a sua opnião se quiser discordar, de boa
“Aqui quero enfatizar que a BEA sempre esteve à frente da Sun e da própria Oracle em concorrências onde tive oportunidade de participar, exatamente porque possui essa facilidade ao desenvolvedor.”
Concordo em gênero, número e grau. A BEA é (era) sem dúvida uma empresa de middleware respeitável
“Aqui vou discordar, pois lock-in todas essas soluções possuem. Se você desenvolver para o Mule e quiser o usar o FuseESB (outro excelente), terá que refazer a implementação.”
Você está analisando e assumindo vendor lock-in apenas pelo prisma da tecnologia 
Concordo que se você começar a desenvolver um projeto no JBoss ESB … depois que quiser trocar de ESB (por alguma razão plausível) será um duro parto migrar para outro ESB. Em minha experiência isso é quase impossível. Fatalmente você terá que reescrever a solução toda, devido a features intrínsicas de cada produto. Isso é um cenário perceptível mesmo no mundo dos Application Servers, onde a premissa do JEE “garante” interoperabilidade entre os fornecedores, mas sabemos que na prática, não é bem assim. No mundo dos ESBs, isso se torna mais verdade ainda. Concordo com você, sob este prisma técnico
Mas meu caro Kenobi, vendor lock-in deve ser medido também pelo prisma de investimento. O modelo baseado em licenças lhe priva do direito de optar por uma versão do produto que não seja baseada em licenças. Se você inicia um projeto usando Oracle Service Bus e por algum motivo você não poderá mais continuar pagando suas licenças (que como o Edgar citou, são caras de fato) sua única opção é REESCREVER a solução em outro ESB. E isso significa PERDA de investimento. E olha que todo CEO quer ter ROI, ou seja, o retorno do mesmo ou mais que o investimento. Imagina ele não ter isso e pior, efetivamente perder o investimento feito. Os custos de mão de obra investidos (os salários dos programadores) e as licenças compradas vão por água abaixo.
Agora se você adota uma iniciativa baseada em open-source, digamos por exemplo, investindo no Mule (vou até esquecer por hora o JBoss ESB para isso não virar de fato uma discussão sobre fabricantes), e na hora de colocar o projeto em produção, por algum motivo, você não pode | não quer investir no suporte enterprise, você AINDA têm a chance de manter o investimento usando a tecnologia oriunda da comunidade. As horas dos programadores serão justificadas ainda, e nenhum custo com licença teve que ser perdido. E acima de tudo, a expectativa do CEO que investiu no projeto ainda poderá ser suprida, ainda terá chances dele recuperar no mínimo o investimento feito, ou, como muitos CEOs querem, recuperar bem mais que o investimento feito.
E esta é a beleza do mundo open-source, a possibilidade de você ter possibilidades A opção a tecnologia e ao conhecimento é um direito de todos, e a filosofia open-source estimula isso, e é sustentada por iniciativas e investimentos por todo globo, desde pessoas altruístas que gostas de compartilhar o conhecimento, assim como empresas que fomentam e investem no open-source como Apache, IBM, Ericsson, Red Hat entre outros.
Caramba, este thread está ficando bem legal mesmo, mas está se distanciando um pouco do seu título. Será que dá pra mudar o título do thread ou criar outro? GUJMasters?
Cordialmente,
Ricardo Ferreira
http://architecture-journal.blogspot.com
