Muito provavelmente no site da BEA você também vai encontrar algo parecido.[/quote]
Alguém lembra de algum caso de sucesso pelo ponto de vista de quem usa e não pelo ponto de vista de quem vendeu?
Sei que devem existir muitos mas bem menos do que contam os vendedores de ferramentas e empresas especializadas no vendor lock-in
[]s
Luca[/quote]
No exato momento estou num projeto para construção de uma Arquitetura SOA para o Grupo STP. Há muita expectativa sobre descentralização dos serviços, permitindo que os serviços sejam compostos apenas por processos - BPEL.
Acredito que se o modelo canônico for bem desenhado e os serviços também, isso pode ocorrer sem maiores traumas. O grande problema está na experiência dos arquitetos do projeto, meu ponto de vista, pois pode sair uma meleca geral
Isso vai depender muito das tecnologias envolvidas.
Mas em suma, eu vejo segurança(autenticação/autorização), confiabilidade das mensagens, auditoria de serviços, gerenciamento do fluxo de serviços, monitoramento dos serviços…[/quote]
Ok, faz sentido. Mas se vc pensar bem tudo isso já foi resolvido no mundo web. Em qualquer projeto web temos que se preocupar com essas mesmas coisas.
Então pra que inventar um middleware gigantesco, complexo e proprietário no meio disso?
Por que não usar HTTPClient para trocar mensagens com o servidor e cair no vasto, seguro e livre mundo http?
Com HTTPClient por exemplo eu posso usar cookies para autenticação. Posso usar HTTPS. Posso usar 10000 frameworks web. E por aí vai…
Talvez porque um cliente não terá acesso a um HTTPClient. Tudo bem, mas entre um HTTPClient para os meus clientes e um elefante branco proprietário ou qualquer framework louco de web services, eu fico com o HttpClient…
E qual cliente não pode fazer uma forcinha para obter um HttpClient para suas requisições?
:arrow: Na grande maioria dos cenários que passei, o simples fato de não ter um ‘ecossistema’ de aplicações todo em Java já impossibilitaria isso. Certo que qualquer plataforma com um minimo de caráter e bons costumes consegue fazer uma requisição http. Porém até você fazer com que seu fornecedor implemente algo tão RESTful no produto dele já é um loooooongo caminho.
:arrow: Para você fazer com que a SAP implemente essa requisição HTTP no R3 dela já se vão alguns bons meses só para você saber se isso é possivel, e depois disso começar a testar -ou qualquer outro ERP famoso por aí-.
:arrow: Ou outro cenário em que aquele fornecedor de uma micro-nano-empresa que desenvolve em Delphi/VB/Clipper/etc até a equipe implementar essa chamada que nunca tentou já é um grande passo.
:arrow: Outro problema que tive em utilizar http era quando a carga de serviços era muito grande, na ordem de milhares/milhões de requisições
:arrow: E outro grande problema do HTTP é que ele é síncrono, e nem sempre você vai querer fazer isso com seus serviços.
Mas concordo contigo, esses middlewares-mágico-satânicos são mais promessas e dor de cabeça do que solução pra os problemas técnicos, a grande maioria que tive contato. E integrações consegue-se simplificar na maioria dos casos. Ou seja, a questão técnica sempre há alternativas, a gente sempre dá um jeito.
É como o Vinícius Teles sempre diz nas palestras de XP: ‘O grande problema é que seu chefe é uma besta, e pior ainda, o chefe do seu chefe é mais besta ainda…’
