EJB x QualQuerOutraCoisa

LIPE wrote:hehe

RPC ou RMI são bonitos.

http://www.retrogui.com/cgi-bin/wiki_dualrpcserver.pl/FAQ

RPC ou RMI que tal com

http://www.springframework.org/docs/reference/remoting.html

OK,

Então no meu caso, RPC, RMI dariam conta do problema sem mais delongas.

Nãoconheço o Spring a fundo, e pelo jeito, ele consegueria administrar perfeitamente minhas transações remotas com RMI ou RPC, estou certo?

Usaria o Spring para integrar meus sistemas feitos em java, de maneira que pareceriam um sistema maior com vários módulos sem problemas alguns, é isto?

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

@.@

Não lembrava disso. Obrigado fabgp

This message was edited 1 time. Last update was at 04/03/2005 17:23:44

RMI é uma solução provada e bem documentada. Vão ser bem menos surpresas. Funciona, mas te oferece poucos serviços que podem acabar sendo precisos, como propagação do contexto de segurança e transação que o container EJB já te faz.

WebServices é pura dor de cabeça e tem performance mediocre. Se for para somente integrar sistemas internos da tua empresa, corra, fuja e faça de tudo para NÃO usar.

EJB tem o ciclo de desenvolvimento mais lento e costuma ser o mais demorado de aprender. Apesar disso, se você não usar Entity Beans, e explorar ferramentas como xdocklet, da para suportar. O melhor a fazer é usar EJBs apenas como um layer de serviço que funciona somente como façada para o sistema.

Quase ia esquecendo, existem opções de tecnologias, como Hessian e Burlap, que são faceis de usar, mas tem tanta projeção ou abrangencia.

This message was edited 1 time. Last update was at 04/03/2005 17:15:13

louds wrote:RMI é uma solução provada e bem documentada. Vão ser bem menos surpresas. Funciona, mas te oferece poucos serviços que podem acabar sendo precisos, como propagação do contexto de segurança e transação que o container EJB já te faz.

WebServices é pura dor de cabeça e tem performance mediocre. Se for para somente integrar sistemas internos da tua empresa, corra, fuja e faça de tudo para NÃO usar.

EJB tem o ciclo de desenvolvimento mais lento e costuma ser o mais demorado de aprender. Apesar disso, se você não usar Entity Beans, e explorar ferramentas como xdocklet, da para suportar. O melhor a fazer é usar EJBs apenas como um layer de serviço que funciona somente como façada para o sistema.

É quase isso que se decidiu fazer.
Infeliz ou felizmente, o cliente exigiu EJB + Hibernate, então usariamos EJB para as chamadas remotas e bla bla bla...

Hibernate na camada com o banco.

Quanto ao Spring ainda está aindefinido...

louds wrote:Quase ia esquecendo, existem opções de tecnologias, como Hessian e Burlap, que são faceis de usar, mas tem tanta projeção ou abrangencia.

Pois é Louds, e todas essas tecnologias sao suportadas pelo Spring, nao tenho muito conhecimento do assunto com Spring pois comecei a estudar a pouco tempo. To pensando em usar ele pra uma interface remota de administracao de portal com Swing. Pelo que eu vi algumas dores de cabeca ele abstrai e isso ajuda muito, quando existe tempo curto para o desenvolvimento.

]['s

"

fabgp2001 wrote:

louds wrote:Quase ia esquecendo, existem opções de tecnologias, como Hessian e Burlap, que são faceis de usar, mas tem tanta projeção ou abrangencia.

Pois é Louds, e todas essas tecnologias sao suportadas pelo Spring, nao tenho muito conhecimento do assunto com Spring pois comecei a estudar a pouco tempo. To pensando em usar ele pra uma interface remota de administracao de portal com Swing. Pelo que eu vi algumas dores de cabeca ele abstrai e isso ajuda muito, quando existe tempo curto para o desenvolvimento.

]['s

Ja vi boas vantagens do Springs, várias pessoas falando bem, mas do jeito qeu vocês falam, parece que ele é o "Deus" dos frameworks

Não sei se ja exite mas poderia se criar um topico aqui com as vantagens e desvantagens, ou link pra algo assim, ou entao naquelas seções, "então você quer aprender Spring"

This message was edited 1 time. Last update was at 04/03/2005 19:14:39

Fabio, o Spring apenas te ajuda a usar todas essa tecnologia, ele não substitui nenhuma delas.

Ou seja, falar de spring-remoting sem falar qual tecnologia de RPC está por traz não faz sentido. Vai ter rmi, ejb, soap, xml-rpc, hessian ou burlap por traz.

Meu ponto é que são decisões diferentes usar Spring e qual solução de integração usar.

EJB é razoavel, uma vez que a performance é boa pra SLSB e a varios AS suportam exportá-los como WS.

louds wrote:Fabio, o Spring apenas te ajuda a usar todas essa tecnologia, ele não substitui nenhuma delas.

Louds, eu nao quiz dizer que ele substitui alguma delas, se foi isso que deu a entender no texto me desculpa.

O que eu quiz dizer é que ele pode deixar algumas tarefas menos dificeis, sabemos que independente da tecnologia usada, sempre existe uma complexidade maior em sistema com acesso remoto para integracao , desenvolvimento, etc.

Como ele disse que estavam pensando em usar EJB, para uma tarefa, Hibernate para outra, etc, acredito que a integracao disso tudo pode ser simplificada com o Spring. Ta certo isso nao é uma verdade, mas é uma grande possibilidade.

louds wrote:Ou seja, falar de spring-remoting sem falar qual tecnologia de RPC está por traz não faz sentido. Vai ter rmi, ejb, soap, xml-rpc, hessian ou burlap por traz.

Pois é tu atacou o ponto que eu "tentei", fora a tecnologia escolhida para o remoting ele provavelmente terá outras, O/R, Framework MVC, etc. O Spring nesse contexto seria a tal camada integradora.

Notícias, artigos e o maior fórum brasileiro sobre Java