Tô meio confuso

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

Oi Daniel…

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)

valeu mesmo…

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.

Usando RMI você não tem muito a ganhar em relação a Session Beans. Ai acho mais vantagem usar um AS mesmo.

Uma opção é o [url]http://www.enterpriseobjectbroker.org/[/org].

Vamos lá…

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.

Opiniões, opiniões, opiniões

[]s

Uma maneira de ter as facilidades de performance de um AS e não se matar pra usar EJB é usar um container de IoC e o pattern de comando.

É bom falar com quem entende do assunto…

Estou fazendo alguns testes com as dicas que vcs deram, inclusive com o object broker que o Louds indicou. Bastante interessante…

Valeu mesmo a força pessoal, espero um dia poder retribuir (vai demorar um pouco p/ saber tanto, mas quem sabe…)