Ae galera, gostaria da opinião de vcs a respeito da utilizacão de JMS na minha aplicação. La vai…
Estou utilizando: Weblogic + ejb + swing(locais e remotos)
temos um frame q possui uns 10 combos com dependência, q são populados atraves dos listeners de seus respectivos pais, tipo a ligação entre Estado e Município, por esse motivo ao navegar entre os registros são disparadas 10 chamadas aos ejbs demorando uma vida para popular todos os combos. Foi feita uma reunião para verificar a melhor forma de solucionar esse problema.
A. Ao navegar entre os registros em vez de ir 10 vezes no Servidor, iria somente uma vez retornando uma collection com todos os 10 lists
B. Ao logar no sitema, o usuario receberia um Map possuindo todas as combinações possiveis.
exemplo: para cada Estado traria um list com seus municípios e assim sucessivamente com os outros combos. Pelo fato do combo ser trazido qndo o usuário loga no sistemas, teria q ser atualizado. é qndo entra o JMS. o cliente q alterasse o cadastrao de cada um dos registros o servidor envia um msg contendo o novo list para todos os clientes.
Exemplo: ao alterar um municipio de Alagoas, enviaria o novo list contendo seus Municípios.
A solução escolhida foi a B.
JMS se aplica a essa solução???
Espero q alguem tenha tido paciência de ler… :lol:
[quote]1) Vocês fizeram testes comparativos entre A e B antes de escolher B ou foi só na intuição?
[/quote]
Não fizemos teste não Luca.
Espero conseguir passar as informações…
Criamos um GeralEJB para as telas de cadastros e um EJB para cada modulo q é criado. A interface é remota, sendo acessada por um Facade, sendo q esse Facade não acessa esses EJB ele acessa um EJB chamado EJBUtil, q passa o ejb solicitado.
O Sevidor utilizaria JMS para enviar uma msg contendo a lista q foi atualizada por um cliente, isso para cada cli.
exemplo: Ao adicionar um funcionario a uma determinada empresa, os clientes so teriam acesso a esse novo funcionario se fechasse e abrisse o sistema, pois é nessa hora q ele pega as listas de funcionario de todas as empresas. Para q isso não seja nescessario, pensamos em utilizar JMS para q toda vez q um funcionario fosse alterado, disparasse uma msg para todos. No caso, cada cli teria um messageListener para receber essas msgs.
Gosto mais de arquiteturas onde o cliente vê as dados e um ou mais servidores fazem todo o resto. Neste caso as vezes os servidores estão espalhados em vários locais e é este tipo que para mim pode usar interface remota. Quando todos os EJBs estão no mesmo servidor interface remota é um atraso de vida. Como já disse aqui no GUJ em outro tópico: EJB com interface remota eh uma gambiarra que serve apenas e tão somente quando o projeto realmente precisa de uma arquitetura distribuída e ainda use RMI/IIOP como protocolo de comunicação entre os objetos. Lembre-se de nao usar caso voce nao precise.
Há gente que gosta de clientes que além de mostrar os dados ainda escovam os dentes e chupam cana. Gente que coloca telas acessando EJBs sem a intermediação de um servlet engine que pode inclusive estar atrás de um firewall. Não gosto disto, para mim o negócio deve ser independente de como é mostrado. Nestes casos sinto cheiro de aplicação cliente servidor modelo 2 portas sedan Delphi 1994 ou cupê banda branca VB 1993. Mas se seu sistema já é assim, sinto muito, vai ter que aturar.
Com EJBs, na maior parte das vezes um par business delegate + session beans resolvem todos nossos problemas transacionais. Raros projetos precisam de tudo dos EJBs. Muitas vezes vale é o princípio do Rod Johnson: “It is better to avoid gratuitous complexity than to rely on tools to manage it”
Entao ja q tudo esta na mesma JVM nao a necessidade de utilizar chamadas remotas aos EJBs, somente o Facade que precisa pois é o q vai ser chamado pelo cli, correto?
Certo, primeiro passo é tentar usar interface local. Veja os links e analise possibilidades. Em futuros projetos considere também a hipótese de não usar EJBs, inclua o Hibernate e o iBatis em seu cinto de utilidades.
