leo.luz wrote:
De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente.

leo.luz wrote:
Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos "errados" em disponibilizar um ESB em nosso modelo arquitetural?

leo.luz wrote:
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho.

leo.luz wrote:Ola a todos!

Infelizmente não pude ir esse ano. Vida de recém casado é dureza. Nesse dia eu tava apertando torneira, instalando prateleiras, etc.. Andei meio fora de sintonia nesses últimos 2 meses. Aos poucos estou voltando a ativa!

Porém tratei de correr atras para dar uma boa olhada nos slides e ainda peguei o feedback com o pessoal do meu time que esteve por la.

Achei muito interessante essa discussão em relação ao ESB. Mesmo por que o Kenobi (@scaphe) nos ministrou um treinamento no antigo ServiceBus da BEA atual OracleServiceBus no final de 2008. Agora estamos no meio do projeto de implantação, indo para um novo datacenter e o espaço do ESB está reservado.

Sei que estou caindo de pára-quedas na discussão e não pretendo tomar nenhum partido. De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente. Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos "errados" em disponibilizar um ESB em nosso modelo arquitetural? Nunca acreditei que ele fosse a bala de prata e que com ele iremos resolver todos os nossos problemas arquiteturais, apenas acredito que ele resolva o que se propõe a fazer.

Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho. Como disse, não assisti a palestra, mas me pergunto: será que foi isso mesmo o que Jim Webber quis dizer? "Não usem ESB. Ele é o grande vilão!". Foi realmente essa a moral da história? De fato não tenho certeza se foi isso mesmo, mas o que sei é que visão, coerência e bom senso devem ser os guias de qualquer pessoa quando o assunto é tomada de decisão!

Abraços!
-LeoLuz-

pcalcado wrote:

leo.luz wrote:
De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente.

Acho que você não entendeu bem a discussão. Este não é o ponto, a crítica não diz que se pode fazer "programaticamente" (seja lá o que você quer dizer com isso) mas sim que existem alternativas mais simples.

pcalcado wrote:

leo.luz wrote:
Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos "errados" em disponibilizar um ESB em nosso modelo arquitetural?

Ok, você acha que implementar isso num ESB é simples. Seria bem interessante você dar sua opinião após algum tempo de experiência real.

pcalcado wrote:

leo.luz wrote:
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho.

Desculpe mas ridículo é a sentença acima. Você pode dizer onde leu isso?

Antes de mais nada existem apresentações do Jim Webber disponíveis online caso você queira para de usar falácias e queira discutir argumentos:

http://www.infoq.com/presentations/webber-guerilla-soa
http://www.infoq.com/presentations/soa-without-esb

Depois você poderia se dar ao trabalho de fazer uma pesquisa no Google para saber se o argumento contra o uso desemcabido de ESB é coisa apenas do Jim Webber:

http://www.google.com/search?q=enterprise+service+bus+rest+-webber

Por favor consulte a Rede Mundial de Computadores (a Internet) e leia sobre o assunto debatido antes de postar em um fórum público.

Why Buy an Enterprise Service Bus?

We come across this question frequently. The truth is that an ESB contains no magic in it at all.
It?s possible to build your own ESB from scratch. In fact, one of the authors has done it twice
before joining Oracle. There?s nothing that the engineers at Oracle can write that you cannot
write yourself, given enough time, money, and training. This principle holds true for all soft-
ware. You don?t need to use Microsoft Word to write your documents; you could create your
own word processor. In the same way, HTML standards are publicly available, and you could
use your engineering time to develop your own web browser.
Naturally, few of us would ever consider writing our own word processor or web browser.
It?s a far better use of our time and money either to buy the software or to use an open source
version. This is especially true if your company isn?t a software company. If you work in an IT
shop for a company whose primary line of business isn?t software, you?ll recognize the fact
that building software from scratch is a difficult sell to your executive staff. There simply is no
return on investment for such development efforts. Your time and skills are better spent solv-
ing problems specific to your company.

cmoscoso wrote:
Uma breve pesquisa neste fórum e na internet pode revelar que antes mesmo da palestra do Jim a discussão envolveu muito mais do que 1 pessoa criticando soluções ESB, ele apenas sintetiza tudo (numa brilhante apresentação por sinal!).

leo.luz wrote:
Caso vc não saiba está aqui a definição:

falácia
s. f.
1. Acção!Ação de enganar com má intenção.
2. Engano, logro.
3. Sofisma ou engano que se faz com razões falsas ou mal deduzidas.
4. Fam. O ruído de vozes de muitas pessoas que falam.
5. Falatório.

Promover uma falácia não foi minha real intenção. Isso é coisa da sua cabeça.

Straw Man Fallacy wrote:
A straw man argument is an informal fallacy based on misrepresentation of an opponent's position.[1] To "attack a straw man" is to create the illusion of having refuted a proposition by substituting a superficially similar proposition (the "straw man"), and refuting it, without ever having actually refuted the original position.[1] [2]
Presenting and refuting a weakened form of an opponent's argument can be a part of a valid argument.
...
Oversimplifying an opponent's argument, then attacking this oversimplified version.

leo.luz wrote:
Voltando ao tópico da discussão, quem trabalha comigo sabe que não defendo esse ou aquele vendor. Muito pelo contrario.. Gosto de escutar e pesquisar as mais variadas opiniões sobre um determinado assunto para tirar minhas próprias conclusões. Não estou defendendo o ESB para 100% dos cenários (nem 20% deles) e tão pouco a Oracle, mas gostaria de citar um trecho do livro "The Definitive Guide to SOA - Oracle® Service Bus" que mostra a visão deles:

Thus:
- Service interfaces (operations, data types) need mediation, enrichment, and routing
- Service contracts need capability mediation (reliability, availability, security, etc.)
- Services need dependency management and monitoring
- All of this shouldn't require coding

That's what an ESB should do -- quick, simple, code-free intermediation & management. It's a configurable proxy. Features like orchestration, BPM, etc. belong in a separate architectural component.

Some examples:
- A consumer talks HTTP/S based authentication, a producer uses WS-Security
- A consumer talks HTTP/RSS, a producer uses WebSphere MQ or JMS
- A consumer talks HTTP/REST and URIs, a producer talks SOAP/WSDL
- A consumer has one set of credentials, a producer has another set (keychain mapping).
- An FTP site is the "service interface" for one end, but the files are broken up into JMS messages on the other end
- A message may need enrichment before routing to a destination, so I can perform callouts to gather extra information
- Protocol independent load-balancing and/or failover is required for a producer
- Messages need to stored and forwarded, retrofitting reliability onto an unreliable service

pcalcado wrote:
Não entendi o que este trecho agregou ao que já foi discutido antes.

Kenobi wrote:
Shoes, acredito que o trecho colocado pelo Leo reflete o seu sentimento em relação ao Core Business da sua companhia não ser TI, então eles optaram em utilizar um produto que trouxesse benefício no time-to-marketing. Hoje estão com mais de 5 meses de projeto, acredito que a experiência que relatou é válida

Kenobi wrote:
, no entanto, se quiser; posso trazer outros cases, já que trabalho diretamente envolvido com projetos SOA há algum tempo...

Como disse, TW não publica seus cases, fica difícil analisar ROI por exemplo de uma solução dessa, principal conta que alguns gestores como Leo devem fazer, antes de dar sinal verde à estratégia.

pcalcado wrote:
Mais uma sugestão de pesquisa para você: http://en.wikipedia.org/wiki/Straw_man

pcalcado wrote:
Não entendi o que este trecho agregou ao que já foi discutido antes.

leo.luz wrote:
Aonde você quer chegar com isso?

leo.luz wrote:
Realmente não deve ter agregado nada para você. Afinal sua santidade já sabe tudo.. O trecho que postei foi direcionado para outras centenas de leitores que passarão por aqui. Talvez eles não tenham tempo para fazer uma pesquisa mais aprofundada e clicar em todos os links dessa thread. E talvez para eles ajude em alguma coisa.

pcalcado wrote:
Desculpe mas eu não levo a sério "análise" em "cases" deste tipo. Não apenas este tipo de coisa não traz toda a verdade bem como ninguém publica case de projeto que falha. Falo com experiência de quem trabalhou em um projeto utilizand ESB para uma grande mineiradora brasileira que ganhou três prêmios mesmo tendo sido cancelado por ser um fracasso grotesco. E olha que ele foi cancelado antes dos prêmios saírem. Mas quem liga? O que importa é o case publicado.

martinfowler wrote:
SOA means so many different things to different people.

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

DaviPiala wrote:Nem toda solução demanda o uso de um ESB, mas não creio que seja uma minoria expressiva. Quando encaramos um projeto com um escopo pequeno ou na implantação de SOA não vemos as vantagens em termos um ESB, mas quem já trabalhou com legado de serviços sabe bem o quanto faz falta.