[quote=Kenobi]Mauricio, concordo contigo que existem muitas formas de se integrar, mas arquiteturas SOA não são exatamente um Lixo. Talvez não da forma como a maior parte dos consultores implementa, mas para uma empresa que precisa ter “componentes intercambiáveis” em plataformas heterogêneas e coordenados ( Orquestrados como gostam de falar BPM) para formar um serviço, a linha de pensamento pode sim fazer sentido.
Talvez a implementação desses não seja a mais adequada, aí é olhar soluções existentes no mercado e conceber uma solução que realmente faça sentido à sua estratégia, como citado, mensagens assíncronas. [/quote]
O meu exagero é intencional 
Nas próximas semanas nós vamos ter reunião do grupo de usuários Java local e o título da minha palestra é “O SOA morreu: Por uma arquitetura orientada a Recursos” 
SOA hoje já está muito preso a SOAP e WS-*, perdeu o seu sentido como uma arquitetura e virou a “implementação”. Eu diria até que o home realmente foi infeliz, serviços lembram coisas que não tem estado, aonde você dá uma entrada e recebe um resultado, como uma calculadora, um recurso já tem uma apresentação diferente, ele parece uma coisa que tem estado, que está lá pra ser visto, alterado, ele representa melhor as nossas entidades dentro de um sistema e a maior parte dos web services é exatamente sobre isso, recursos e entidades, é só olhar web services famosos com o da Amazon que você percebe que o que é interessante são as entidades e não “serviços”.
É óbvio que o conceito de SOA em si vai muito além e não está preso aos web services baseados em SOAP, mas não é isso que os fornecedores de soluções SOAP falam, eles vendem as suas ferramentas como se fossem a última cocada do tacho e isso levou muitos “arquitetos” a acreditar que eles são, realmente, a melhor solução, tanto que muita gente caiu de boca na brincadeira e dançou. Já vi muita gente “criando” web service no Visual Studio usando um DataSet como fonte de dados e sabe como é que fica o WSDL, um “any element”, não tem ferramenta Java que entenda que diabos é isso. Cadê a interoperabilidade desse troço?
SOAP nasceu errado, nasceu na dependência de que todas as ferramentas implementariam o padrão do mesmo jeito e que tudo ia funcionar perfeitamente. Mas assim como não funcionou pra Corba, EJBs, JSF e outras tecnologias que dependiam de “ferramentas” pra poder trabalhar, falhou miseravelmente.
Acho que existem sim muitas formas de se implementar uma arquitetura aonde pequenas aplicações sejam especializadas em implementar determinadas partes do trabalho, assim como também existem diversas formas de se implementar a famigerada “orquestração” (eu, pessoalmente, detesto o termo), o problema é quando todos procuram os modos mais difíceis de se fazer isso sem nem parar pra considerar que o investimento em complexidade não vai se pagar nem no médio nem no longo prazo. É muito difícil de se encontrar uma empresa que realmente tenha necessidade (e, principalmente, capacidade) pra montar um ESB e fazer uso de verdade dele, não é uma simples questão de chegar alguém e dizer que “agora tudo é serviço”, é uma questão de se formar uma conciência nas pessoas de que agora eles não são mais equipes de desenvolvimento separadas, mas pequenos grupos de um grupo maior que tem que se preocupar com muito mais do que “escrever uma aplicação”. Dar manutenção em APIs públicas, especialmente num ambiente complexo como um ESB, não é um trabalho trivial e o “motorista de gerador de WSDL” com certeza não é uma pessoa com capacidade pra fazer isso.
[quote=Kenobi]O que realmente acontece e vejo todos os dias isso na empresa, é que muitos consultores rezam a cartilha da companhia sem estudar à fundo a base.
Mas vi muita gente também criticando WS-SOAP sem base alguma ou justificativa em seu favor. [/quote]
Criticar WS-SOAP é incrivelmente fácil, é só você ter passado por um projeto de integração de linguagens/tecnologias/runtimes diferentes, tipo Java + Perl ou Qualquer coisa + .Net, são histórias pra se carregar pela vida toda
