Desenvolvi uma aplicação client/serer (podem xingar…), pois comecei em Java faz pouco tempo, e queria implantaralgo para dar uma avaliada…
O resultado ficou excelente em relação a uma aplicação VB que já existia (os usuários e os home piraram!!!). Agora queria implementar as camadas de dados e negócio (que hoje rodam em COM+) mas depois de ler diversos tutoriais e fóruns fiquei mais confuso ainda! Tinha pensado em EJB ou WS mas os pessoal diz que complica demais e o resultado acaba não compensando, além da performance não ser exatamente um furacão. Ai comecei a pensar em RMI com Hibernate… sei lá! A Aplicação que estou desenvolvendo é uma parte em Swing desktop (para produção) e outra em browser (para gerenciamento/clientes). Atualmente roda em cerca de 350 usuários e faz uma média de 900.000 transações dia.
Será que vcs poderiam dar uma dica qual o melhor caminho a seguir? Qual consome mais hardware ?
Qual tem a melhor performance (é muito importante p/ mim)?
Qual pode ser usada tanto para acesso via browser como para desktop?
Se você quiser implementar as regras de negócio usando WS ou EJB, vá em frente. Não tire conclusões a respeito destas tecnologias sem testá-las antes
A única questão que talvez seja um pouco chata com o uso destas duas tecnologias é que:
:arrow: para usar EJBs você vai precisar obrigatoriamente de um servidor de aplicações.
:arrow: para usar WS você vai precisar obrigatoriamente de um servidor que disponibilize os serviços para você.
Vai valer a pena o esforço? Sei lá! Depende do seu projeto. Se você acha que o sistema VAI precisar de uma escalabilidade monstruosa ou se você achar que sua aplicação vai precisar de diversos tipos de camadas de visualização, legal, use uma destas tecnologias Caso contrário, fuck off, continue usando cliente/servidor e seja feliz
Já que hoje tá chovendo e fazendo frio (dia ideal p/ descobrir coisas), estou testando o RMI/Hibernate/Tomcat. Tô achando bem legal e mesmo no servidor aqui de casa (que é uma piada perto do que eu uso na empresa) dá para sentir que dá para fazer um trabalho bem melhor que o COM+/MTS e a performance é bem superior. Como tenho mudanças de regras constantes, o ideal é ter pelo menos a camada de negócio separada. A principal dúvida é se com o tráfego que coloquei no meu primeiro post, dá pra levar na boa, sem ter que mexer no serer… (Dell 6800, 4 Xeon 2.5, 2Gb memória, 520 Gb. de disco)
Vai depender das suas regras de negócio, mas se elas não forem nada monstruosas (tipo regras de negócio do SBP), seu servidor vai dar conta do recado muito bem.
EJB: O Dabiel está certo, mas lendo qualquer tutorial pequeno de EJB você já percebe que é muito trabalho para pouco benefício, fora que tende demais à cosntrução de uma aplicação horrorosa e bem pouco performática. Claro que se você aprender a usar EJB como eles deveriam, isso pode não acotnecer, mas a tecnologia já tem empurra para o buraco
Servidor de Aplicações: Transações, Pool de recursos, segurança… um servidor de aplicações te oferece tudo isso sem muito esforço. Com a variedade de opções no mercado, free, open-source, pagos caríssimos e pagos baratíssimos, acho que vale a pena usar um sim.
RMI+Hibernate: Como o louds falou, você poderia usar Session Beans (a parte menos horrível do EJB < 3.0) para fazer a fronteira de suas regras de negócio, conseguindo usar RMI e JNDI de maneira mais transparente e sem se quebrar com a performance dos outros tipos de EJB. Neste caso, acho que a complicação vale a pena. A dica é evitar que seus clientes saibam o que a regra de negócio utiliza (através de um Business Delegate, por exemplo, veja o catálogo de padrões da Sun), assim você pode mudar de uma versão para a outra sem muito drama.
WS: legal se você tem clientes não-java. Com a facilidade que é expôr uma interface em webservices hoje em dia, só vale a pena se preocupar quando a necessidade surgir.
Caso contrário, fuck off, continue usando cliente/servidor e seja feliz 
