Arquivo Discussoes de Programacao e Tecnologia 
GUJeiros,
É o seguinte,
Tenho 8 sistemas que serão desenvolvidos em java, cada um é um sistema a parte e independentes, porém preciso que todos conversem entre si em tempo real.
Eles podem estar num mesmo local, como também em locais diferentes.
Perguntas:
Realmente preciso de EJB?
Existe alguma outra coisa que faz isso sem ser EJB?
Frameworks que poderiam auxiliar, no controle, integração?
O que eh “conversar entre si” no seu caso?
Rafael
Se realmente não for preciso usar EJB, um framework bacana para se utilizar é o Spring Framework:
:arrow: http://www.springframework.org/
[]'s
O que eh “conversar entre si” no seu caso?Rafael
Um sistema acessar dados de outro sistema…
Servidores diferentes, bancos diferentes…
Se realmente não for preciso usar EJB, um framework bacana para se utilizar é o Spring Framework:
:arrow: http://www.springframework.org/
[]'s
Ja havia pensado no Spring, só não sei se ele integra com EJB.
É possivel EJB + Hibernate ? Hibernate local e EJB para algum acesso remoto?
Um sistema acessar dados de outro sistema…
Servidores diferentes, bancos diferentes…
Isso vc consegue de maneira relativamente facil sem EJB. Ate mesmo replicacao de objetos eh facil (oscache, jboss-cache etc.)
Rafael
Um sistema acessar dados de outro sistema…
Servidores diferentes, bancos diferentes…Isso vc consegue de maneira relativamente facil sem EJB. Ate mesmo replicacao de objetos eh facil (oscache, jboss-cache etc.)
Rafael
Mesmo estando os sistemas em locais fisicos diferentes?
EJBs, WebServices, RMI, Corba, SOA em geral são uma boa forma de compartilhar comportamento entre aplicações.
Mas na maioria dos casos a integração já fica legal usando banco de dados, troca de arquivos, serviços de mensageria (MoM).
Tem que estudar caso a caso, senão fica 1 porcaria. Minha recomentação, melhor que prestar atenção em tudo que escrevi acima é ler esse site http://www.eaipatterns.com/
[Mesmo estando os sistemas em locais fisicos diferentes?
Sim. Mas va mais pelo que o louds falou… 
Rafael
Valeu pelas infos e links.
Sei que o tempo de projeto com EJB é mais alongado, e por isso pensei em buscar alternativas.
Mas antes gostaria de saber:
Qual tecnologia(EJB, WebServices, SOAP, Menssagens e etc …) levaria mais tempo de desenvolvimento e aprendizado visto que a equipe não trabalhou com elas ainda.
E para os experientes, fugir do EJB é sempre bom? li em algum lugar que o proprio criador do EJB desaconselha o seu uso a menos que realmente seja necessário, também vi isto em algumas discussões, claro que cada um tem seu ponto de vista, e gostaria de sabe-las, para poder escolher melhor qual tecnologia adotar.
E ai Skill!
Cara… se eu não tivesse outra opção eu escolheria Web Services!!!
Mas sinceramente… depende muito do sistema!!!
Acho que para qualquer solução esta idéia é válida. Mas no caso de EJB acho que a importância desta frase é ainda maior!!!
Eu optaria por utilizar um framework como Spring!
Posso até estar errado, e também não manjo muito sobre essas paradas citadas acima… mas acho que Spring está de bom tamanho!!!
Um Abraço!
E ai Skill!
Fala Tiago…
Pois então as minhas dúvidas primordiais, são exatamente até onde vão os framework como o Spring, ele consegue gerenciar transações remotas? em tempo real?
Webservices, consegue isso? lembrando que não terei sistemas implementados em linguagens diferentes.
Os sistemas atuaram em conjunto, como se fossem módulos, onde um módulo pode ou não depender de informações dos outros módulos.
Não consigo entender a mania de WebServices. Se você precisa publicar seus serviços para clientes que você não conhece, ok. Caso contrário, que tal usar alguma tecnologia de comunicação remota com (bem) menos Strings e mais Objetos?
Se você sabe quem serão os clientes de cada serviço, e exatamente a maneira que cada serviço foi implementado, acho desnecessário ficar passando um monte de arquivinho xml via http …
É eu concordo…
Eu indiquei web services pela curva de aprendizagem ser mais fácil!!!
Talvez o Ideal seja usar Sockets!!! (hehe rsrs…)!!!
hehe
RPC ou RMI são bonitos.
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?
@.@
Não lembrava disso. Obrigado fabgp :thumbup:
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.
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…
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. :lol:
]['s
"
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. :lol:
]['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”
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.
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.
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.
