Gostaria de saber a opinião de voces a respeito dessa arquitetura que tenho que montar:
Teremos uma aplicação independente que fará a comunicação com diversos WebServices e vai transformar esses dados recebidos em objetos comuns a nosso sistema. Seu Front-End usará flex, por isso toda a camada de apresentação está perfeitamente desacoplada. Estando nessa aplicação apenas os Services(meus Facades), meus DAOs e as classes que se comunicam com os WebServices(incluindo as classes que fazem pool de conexões e afins)
Essa aplicação acima será usada por, pelo menos, outras 3 aplicações. Não apenas 3 front-end diferentes, mas também por outros back-ends java que utilizarão desse mecanismo de comunicação com os WebServices(o motor da aplicação que especifiquei acima) e conversão dos dados dos WebServices em dados comuns ao sistema.
Gostaria de saber qual meio de comunicação voces recomendariam nesse caso, e principalmente, por quê.
Alguns pontos que acho importante destacar:
Eu tenho controle total sobre as 4 aplicaçãoes citadas( o engine e as outras 3 que se utilizarão dela). Os WebServices que eu acesso são externos e estão além de meu controle.
Os objetos que serão transportados geralmente serão objetos complexos, acho essa informação relevante caso a sugestão seja algo que envolva XML.
Você quer saber qual a melhor forma de comunicar sua alicação com os X tipos de front-end? Depende do caso mas a primeira coisa é criar uma Camada de Aplicação, creio, minimizando a lógica da interface de modo que você não escreva a mesma lógica nas X implementações de front-end. Sobre o protocolo em si, eu nunca trabalhei com Flex mas duvido que ele tenha muitos problemas para lidar com interfaces RESTful.
Dificilmente. A menos que você precise muito de alguns benefícios que toda a parafernalha EJB traz é melhor você optar por algo mais simples e que ainda tem interoperabilidade com outras plataformas não-java.
[quote=GraveDigger].
Qual seria a melhor forma de passar os objetos de uma aplicação para a outra?
[/quote]
Seguindo a primeira lei de Fowler para distribuição de objetos: não distribua seus objetos. Objetos possuem granularidade fina demais, geralmente caindo em excesso de tráfego na rede ou terrível design. Como falei antes tenha uma Camada de aplicação e não troque objetos, troque entitdades de granularidade mais grossa
Neste caso eu vejo mais problema em distribuir objetos do que transferir XML.
oi cmoscoso,
Bom, temos nosso servidor de aplicação já instalado. Nele rodaremos todas essas aplicações acima citadas.
Realmente minha dúvida seria na comunicação de duas aplicações java dentro desse servidor,justamente a questão da distribuição dos objetos.
Qual seria a melhor forma de passar os objetos de uma aplicação para a outra?
Grato
[/quote]
Eu imagino duas formas/estilos de comunicacao. Ou vc distribui seus objetos usando algum mecanismo de chamada remota de metodos (ejb, rmi, servlets) ou simplesmente transfere documentos entre as maquinas usando HTTP (restlet, servlet).
De qq forma vc vai acabar passando pelo HTTP, a questao como bem colocou o pcalcado é qual o beneficio proveniente de se utilizar ejbs.
Se é preciso transferir grande quantidade de informacao de uma so vez eu utilizaria o mecanismo de transferencia de documentos que é exatamente o que HTTP se propoe a afazer. Inclusive acabei de baixar uma distro completinha do linux usando apenas HTTP.
Se você tem o mesmo objeto por que você teria um sistema no meio? Por que os sistemas das pontas não acessam diretamente o webservice?
Se você está falando em “mesmo objeto” quanto à mesma classe em Java, isso me parece muito estranho. DTOs são usados apenas para transferência, depois de transferidos eles são consumidos pelo sistema e se transformam em algum outro objeto de negócios, então é estranho termos estes DTOs sendo tão utilizados em tantos lugares.
[quote=pcalcado]Se você tem o mesmo objeto por que você teria um sistema no meio? Por que os sistemas das pontas não acessam diretamente o webservice?
Se você está falando em “mesmo objeto” quanto à mesma classe em Java, isso me parece muito estranho. DTOs são usados apenas para transferência, depois de transferidos eles são consumidos pelo sistema e se transformam em algum outro objeto de negócios, então é estranho termos estes DTOs sendo tão utilizados em tantos lugares.
[/quote]
Bom, eu decidi separar o acesso ao WebService em uma aplicação a parte porque algumas coisas serão comuns a todos os sistemas que tenho que acessarão esses WebServices, por exemplo, um pool de conexões aos WSs. Por isso esse sistema no meio. Pretendo também fazer cache de alguns resultados do Webservice, por isso decidi colocar algo para intermediar isso.
Realmente meu DTO será consumido posteriormente para que os dados que foram transportados sejam devidamente processados e tomem algum sentido dentro do contexto de cada uma das minhas diferentes aplicações, mas o que eu pretendo aproveitar do WebService é comum a todos.
Se você tem a mesma interface será que você não tem apenas um proxy e não um sistema entre eles? Se utilizar webservices REST basta você posicionar um proxy normal como o Squid para este tipo de coisa; como imagino que seu webservice seja SOAP/WS-* não sei como isso pode ser feito (já que tudo é via POSTem SOAP).
Na pior das hipóteses seu sistema ‘proxy’ pode oferecer uma interface simplificada, utilizando REST, ou mesmo a interface SOAP. Definitivamente não parece o caso onde EJBs seriam úteis.
Agora que vc usou o termo proxy acredito que seja sim ele o melhor termo para definir o que tenho entre minhas apps e os WebServices,já que seu único objetivo é fazer alguns tratamentos no meio do caminho.
Com toda essa discussão percebi que realmente transferir um objeto entre as APPs não seria a melhor solução, mesmo porque, embora não agora, futuramente eu possa precisar de alguma informação adicional que o WebService me fornece(ou pode vir a fornecer) e alterar esse objeto incidiria em alterar todas as minhas aplicações, inclusive aquelas que não se utilizariam dessas novas informações, isso seria muito ruim.
Além da opção de poder oferecer isso para outros sistemas mais facilmente se eu não usar um objeto java para comunicação.
Vou dar uma estudada a respeito do REST, li por cima e me parace uma saida interessante para a situação.
realmente analisando só a minha mensagem, não houve contribuição.
apenas quis entender o porque de você ter mencionado. mas deixamos isto para outro tópico, blz!
na verdade tinha achado um pouco confuso quando você mencionou no uso de 3 front-ends com outros back ends. mas relendo, e com a evolução desta thread, percebi sua preocupação para implementação desta solução. deveria te perguntado anteriormente.
[quote=GraveDigger]
Se não pode ajudar tecnicamente, ao menos evite desvirtuar o tópico em outro assunto.[/quote]
sinceramente até aquele momento não tive esta intenção, mas acabou ficando. desde já peço desculpas caso não tenho colaborado até então.
Objetos são animais sociais e extremamente dependentes um dos outros. Se você trocar objetos numa rede vai cair em um dos dois problemas:
1 - Um péssimo design - os objetos não vão poder se comunicar da maneira esperada porque cada chamada de método pode indicar uma conexão cara de rede
2 - Uma péssima performance - Criando um design completamente OO e realizando chamadas na rede em excesso