Bom, estou trabalhando em uma empresa na qual existem muitas aplicações e a forma de integração entre as mesmas é precária. A maioria da aplicações são feitas em Java, mas também existem aplicações feitas em PHP, ASP, Delphi e até mesmo Cobol e Natural. Bom, a alguns dias atrás estava discutindo um direcionamento que estão tomando e não achei muito interessante para a situação. A situação é que estão usando WebService para integrar estas aplicações e até mesmo as aplicações feitas em Java. Ou seja, de Java para Java (‘localmente’, servidor pra servidor interno) usam WebService. Minha preocupação vem do fato de WebService ser limitado e até mesmo pelo fato da performance não ser agradável. Pensando no futuro, isso pode vir a ficar mais crítico visto que possivelmente teremos serviços publicados e os mesmos farão uso desta estrutura, que já terão seu ‘overhead’ interno. Diante disso (resumido), gostaria de saber o que os vc’s usam, quais são as práticas mais aceitáveis e os casos de uso de sucesso e também fracasso que vc’s tem a compartilhar.
Paulo, onde trabalho nós estamos implantando um webservice para poder interagir as aplicacoes…
temos o ERP…e os “sistemas auxiliares”…o q seria isso, o nosso ERP cuida mais da parte financeira da empresa…e esses sistemas auxiliares sao de CRM, bloqueio…as aplicacoes estao no msm servidor, porem com banco de dados diferente…
estamos seguindo isso q nos foi proposto a fazer sob a alegação de q isso deixa os sistema menos acoplados uns aos outros…
ok, o nosso controle financeiro fica isolado…ele funciona sem os outros sistemas, mas os outros sistemas nao funcionam sem o esse ERP…ja q seus dados são utilizados nos mesmos…
olhando o seu problema, eu penso o seguinte, se essas aplicações JAVA nao necessariamente precisam ser tratadas de forma isolada,o q quero dizer, cada uma com um banco de dados - sistemas isolados msm, acho q poderiam integrar essas duas aplicacoes, caso exista tb uma grande demanda de operacoes de um sistema com o outro…
[quote=pardal_nb]Paulo, onde trabalho nós estamos implantando um webservice para poder interagir as aplicacoes…
temos o ERP…e os “sistemas auxiliares”…o q seria isso, o nosso ERP cuida mais da parte financeira da empresa…e esses sistemas auxiliares sao de CRM, bloqueio…as aplicacoes estao no msm servidor, porem com banco de dados diferente…
estamos seguindo isso q nos foi proposto a fazer sob a alegação de q isso deixa os sistema menos acoplados uns aos outros…
ok, o nosso controle financeiro fica isolado…ele funciona sem os outros sistemas, mas os outros sistemas nao funcionam sem o esse ERP…ja q seus dados são utilizados nos mesmos…
olhando o seu problema, eu penso o seguinte, se essas aplicações JAVA nao necessariamente precisam ser tratadas de forma isolada,o q quero dizer, cada uma com um banco de dados - sistemas isolados msm, acho q poderiam integrar essas duas aplicacoes, caso exista tb uma grande demanda de operacoes de um sistema com o outro…
[]'s[/quote]
Pois é, mas no nosso caso existem situações em que essas operações entre os sistemas integrados precisam estar em um conexto transacional, daí não vejo (ou não sei) como usar WebService. Mas estas aplicações de vc’s precisam estar tão desacopladas ao ponto de não quererem usar RMI, RMI-IOP ou qualquer outra forma mais performática que WebService?
Vejo WebService uma boa para aplicações de diferentes plataformas e até mesmo para acesso externo à sua corporação, mas internamente acho meio estranho… Não vejo muita vantagem, tirando é lógico, o fato de ser uma forma mais desacoplada de integração entre sistemas.
Ninguém, com certeza! Mas não vi WebService dentro de contexto transacional ainda… Por isso que questiono algumas coisas… Se nossos níveis de integração fossem apenas consultas, ótimo! Mas não são… Penso que temos que olhar para o futuro, mas temos que balancear tudo isso que o futuro nos proporciona de desafios e as vezes preocupação com acoplamento (se é que uma interface acopla tanto assim) prejudica a implementação requisitos não funcionais baseados em performance, segurança etc. E se os serviços das aplicações forem bem isolados e construídos, não vejo como desastre a mudança para WebService no futuro.
Fuja e qualquer coisa com cheiro de RPC. Apenas troque documentos e não fique esperando respostas síncronas.
Liste as alternativas de solução ordenando da mais simples para a mais complexa e vá eliminando as que não servem de modo nenhum até encontrar a mais adequada (que consequentemente será a mais simples possível)
Se não houver outra alternativa melhor e usar web services, comece por REST. O aspecto transacional pode ser controlado usando transações compensatórias (como fizemos no Banco Postal e todo mundo faz na área de cartão de crédito)
Só use WS-*, WSDL, etc. em último caso.
Observações finais:
Considere a possibilidade de usar um ESB como o MULE, ServiceMix ou o Fuse
Se você conhece os padrões de integração do Gregor Hohpe (que todo mundo devia conhecer), considere a possibilidade de usar o Apache Camel
Fuja e qualquer coisa com cheiro de RPC. Apenas troque documentos e não fique esperando respostas síncronas.
[/quote]
Pois é, mas como faço com aquelas operações que dependem da resposta da chamada remota?
blz! :thumbup:
Cara, pesquisei sobre essas “transações compensatórias” e achei mais coisas na área de economia do que a área de computação(distribuída). Como isso funciona? Tem alguma referência rápida aí?
É já vi que WS não é a bala de prata não(se é que existe).
Blz, vou pesquisar.
Estava pensando em adquirir o livro dele, vc tem?Recomenda?
Tenho o Gregor Hohpe e acho que vale a pena para quem se dedica a integração de sistemas. Mas você pode avaliar os patterns pelo site dele.
Operações que dependem de uma resposta remota pode ser feitas trocando mensagens de qualquer tipo, sejam elas síncronas ou assíncronas. Para mim o melhor é usar mensagens assíncronas porque entre outras vantagens permite o sistema escalar com mais facilidade. Sugiro intermediar as mensagens com um servidor de mensageria. O que não gosto é da chamada de métodos remotos (RPC) porque acopla os 2 sistemas e engessa o método chamado. O melhor é simplesmente trocar mensagens sem que nenhum dos lados se preocupe quais meios o outro lado usará para atender a solicitação.
Transações compensatórias são aquelas em que o nosso sistema cuida de tudo e desfaz as transações que não passaram por todas as etapas. Exemplo: compra com cartão de crédito. Se por algum motivo o boleto do cliente não for impresso corretamente, é enviado uma outra mensagem solicitando o “desfazimento” da transação. Normalmente se usa o chamado protocolo de 3 pernas onde cada transação precisa ser confirmada (mesmo que a confirmação venha com a próxima solicitação). Esta é uma área bem complexa que exige expertise de gente do ramo mas funciona muito bem sem que você precise de Web Services Transactions specifications
Repare que quando escrevi [color=darkblue] 4) Só use WS-, WSDL, etc. em último caso. [/color], WS- significa os padrões de especificação WS- e não apenas web services. Minha recomendação não é contra web services e sim contra web services burocratizados demais e a palavra chave aqui é demais. Se você realmente necessita atender os padrões WS-* o uso de WSDL passa a ser obrigatório e então não é demais.
O uso de um ESB facilita a troca de mensagens, porque além do servidor de mensageria, ele inclui tradutores de protocolos que permite mixar sistemas heterôgeneos. Se seus sistemas são todos do mesmo tipo, não há necessidade destes serviços de tradução e um servidor de mensageria simples pode atender.
Realmente quanto a perfomance é discutível … mas o importante e não acoplar os sistemas, acho que RMI é mais perfomático.
Ultimamente os webservices estão num nível de evolução bom, já tem implementações com Security… e ai vai.
Performance vs Desacoplamento
Sempre sempre… (classes inteligentes x classes burras)
Boa Consideração…
toda discução aqui é válida… não é porque está na moda dizer sobre integração com webservices, que devemos usar.
Bom, mas podem existir informações no sistema de RH (sistema que não é o seu) que podem ser “reaproveitáveis”, e isso a vezes é interessante pois, uma possível duplicação de dados pode te custar caro amanhã. Dados são usados para geração de informação(ões) e essas por sua vez, muitas vezes são usadas para tomadas de decisões ($$$$$$). Pode parecer uma coisa boba, mas já vi gerente “perder a cabeça” (demissão) por causa desse tipo de coisa.
Por exemplo, tenho uma aplicação A que possui um atributo que uma outra aplicação B o utiliza para tomar decisão de cálculos, por exemplo. Se a aplicação A modifica esse atributo, logo ela (a aplicação A) pode “avisar” a aplicação B que o valor deste atributo mudou, para que a aplicação B tome providências. Logo, se algum problema ocorrer no momento da mudança na aplicação A a aplicação B deve ser notificada a tempo e não deixar os dados inconsistentes. Existem outras, alternativas? Sim existem, mas provavelmente não muito interessantes ou viáveis. Bom, isso foi apenas um exemplo, não procurei o melhor.
[quote=dreampeppers99]
Acredito que se há um contexto transacional entre duas aplicações, uma deve ser responsável pela sua parte transacional e a aoutra pela outra parte.[/quote]
Integrações entre sistemas podem chegar muito mais longe do que imaginamos. Nesses servidores de aplicações, por exemplo JBoss, existe um recurso que se chama transação distribuída e que serve justamente pra isso. Imagine dois sistemas em máquinas diferentes e que precisam se integrar e até mesmo num contexto transacional, como exemplificado acima.
Mas, como exemplificado, o problema pode ocorrer em A e não em B. Pode ser que em B o operação ocorra sem problemas mas se em A ocorrer problema, preciso garantir a atomicidade da operação, que se iniciou em A e não em B.
Com certeza, seria como eu querer cadastrar uma pessoa no sistema de contabilidade ao invés no de RH. Isso já seria, uma “troca de responsabilidades”.
[quote=dreampeppers99]
Realmente quanto a perfomance é discutível … mas o importante e não acoplar os sistemas, acho que RMI é mais perfomático.
Ultimamente os webservices estão num nível de evolução bom, já tem implementações com Security… e ai vai.
Performance vs Desacoplamento
Sempre sempre… (classes inteligentes x classes burras)
…
toda discução aqui é válida… não é porque está na moda dizer sobre integração com webservices, que devemos usar.[/quote]
Por isso a criação do post, avaliarmos caso de sucesso e de insucesso pois, não vamos achar “aquela” abordagem que serve pra tudo. Por isso sempre falo, os exemplos e cases são muito bem vindos pois da experiência que vamos adquirir segurança. Teoria sem prática é apenas teoria mas com a junção das duas, chega-se a experiência.
Penso que temos que olhar para o futuro, mas temos que balancear tudo isso que o futuro nos proporciona de desafios e as vezes preocupação com acoplamento (se é que uma interface acopla tanto assim) prejudica a implementação requisitos não funcionais baseados em performance, segurança etc. E se os serviços das aplicações forem bem isolados e construídos, não vejo como desastre a mudança para WebService no futuro.