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
[quote=Rafael Steil]O que eh “conversar entre si” no seu caso?
Rafael[/quote]
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[/quote]
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?
[quote=skill_ufmt]
Um sistema acessar dados de outro sistema…
Servidores diferentes, bancos diferentes…[/quote]
Isso vc consegue de maneira relativamente facil sem EJB. Ate mesmo replicacao de objetos eh facil (oscache, jboss-cache etc.)
Rafael
[quote=Rafael Steil][quote=skill_ufmt]
Um sistema acessar dados de outro sistema…
Servidores diferentes, bancos diferentes…[/quote]
Isso vc consegue de maneira relativamente facil sem EJB. Ate mesmo replicacao de objetos eh facil (oscache, jboss-cache etc.)
Rafael[/quote]
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/
[quote=skill_ufmt][
Mesmo estando os sistemas em locais fisicos diferentes?
[/quote]
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!
[quote=Thiago Senna]E ai Skill!
[/quote]
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…)!!!
[quote=LIPE]hehe 
RPC ou RMI são bonitos.
http://www.retrogui.com/cgi-bin/wiki_dualrpcserver.pl/FAQ
[/quote]
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.
[quote=louds]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.[/quote]
É 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…