Após muitos anos trabalhando com Delphi e banco de dados Oracle (PL/SQL), a empresa onde trabalho (uma empresa de médio porte do ramo automotivo) resolveu partir para o desenvolvimento web, em Java. Além dos motivos de sempre (falta de programadores Delphi no mercado, solução do problema de atualização de sistemas, possibilidade de execução em dispositivos móveis, etc), a empresa comprou a solução de portal Oracle WebCenter, que roda no servidor de aplicação WebLogic (que é Java).
Como um dos analistas de sistemas da empresa, e o único que conhece melhor a plataforma Java (fiz uma pós-graduação em Tecnologias Java), fui designado a definir as metodologias e ferramentas de desenvolvimento na nova linguagem.
Uma das minhas principais dúvidas é em relação ao uso de EJB (mais especificamente, session beans): nossos sistemas são bastante integrados uns aos outros, e comumente usamos as mesmas tabelas e compartilhamos código entre eles. Ao meu ver, seria um caso intessante de uso de Session Beans, já que as diversas aplicações poderiam usar uma única fonte de código, sem ter que me preocupar com código repetido em diversos projetos (e para piorar, com versões diferentes).
Então a dúvida é: vale a pena usar Session Beans para manter as regras de negócio, é melhor mantê-los nas próprias aplicações ou ainda, mantê-lo em um JAR, como se fosse uma library, sendo consumida pelas aplicações)? Atualmente as aplicações rodarão todas em apenas um servidor, mas é possível que passemos a trabalhar em cluster, caso o volume de acessos aumente muito.
[QUOTE]
Então a dúvida é: vale a pena usar Session Beans para manter as regras de negócio, é melhor mantê-los nas próprias aplicações
[/QUOTE]
EJB É APLICAÇÃO JAVA.
Existem 3 tipos de EJB.
Session Bean - é o tipo mais simples de EJB, pode ter estado (stateful) ou não ter (stateless)
Para aplicação no geral usa stateless
Entity Bean - mapeam tabelas de um banco de dados relacional através de um arquivo de mapeamento. Na prática cada objeto entity representa uma linha de uma tabela. Existe uma linguagem de query específica para buscar entitys chamada EQL, deve ser usado em conjunto com stateless
MDB - são consumidores assincronos de mensagens de filas / tópicos JMS as vezes precisamos usa-lo no meu ver é o mais complicado
EM FIM
O que EU geralmente faço é criar o modulo EAR (negocio -EJB) e disponibilizar para outros sistemas…
Acho que me expressei mal. O que eu quis dizer foi: vale a pena manter as regras de negócio em Session Beans e fazer as chamadas nas aplicações, ou é não usar Session Beans manter as regras dentro de cada uma dessas aplicações? Ou há alguma outra maneira de se compartilhar código entre aplicações?
Se você quer apenas compartilhar lógica semelhante entre as aplicações, não use EJB, use um JAR comum pra todo mundo. É 50x mais fácil que usar EJB. O único problema é ter que copiar a última versão do JAR pra cada projeto sempre; mas esse problema você teria com EJB também, copiando o JAR das interfaces remotas.
Se você quer integrar com vários sistemas, incluindo mobile e possivelmente outras linguagens (você citou Delphi), não use EJB. EJB é puro Java e te limita bastante em possibilidades de integração. Use integração via Web, preferencialmente REST e serviços simples - mas até SOAP e JAX-WS já ajudaria.
Se você vai rodar tudo numa mesma máquina, não faça uma arquitetura baseada em remotabilidade logo de cara. Usar EJB aqui (e ate Web Service) vai adicionar muita complexidade logo no início, o que vai te atrasar muito.
Fazendo uma arquitetura 100% Web (usando, por exemplo, REST para integração) você consegue escalar facilmente no dia que sua demanda subir. E isso deixando as coisas relativamente simples no início.
PS. Estou falando “mal” de EJB no sentido que entendi aqui no post, de usar para integração remota. Usar como container local com EJB Lite, CDI e coisas do gênero é uma ideia que me agrada. Só tenho problemas com EJBs remotos
Com certeza o que o Sergio Lopes escreveu faz sentido. Sempre é dito para não se matar uma mosca com um tiro de canhão.
Deve-se verificar a necessidade de cada cenario para não sofrer com a curva do aprendizado sem necessidade. Mesmo a equipe adquirindo conhecimento, o que está em jogo é o projeto.
Mesmo o EJB 3 sendo mais facil de usar e enxuto, no começo vc irá “apanhar” um pouco para aprender e compreender algumas tecnologias.
Mas para cenários corporativos, onde varias aplicações acessam o mesmo conteúdo fica um pouco inviável a utilização do jar negocial embutido na aplicação.
É a minha opinião.
flw!
Acho que me expressei mal. O que eu quis dizer foi: vale a pena manter as regras de negócio em Session Beans e fazer as chamadas nas aplicações, ou é não usar Session Beans manter as regras dentro de cada uma dessas aplicações? Ou há alguma outra maneira de se compartilhar código entre aplicações?[/quote]
Vitor tenha certeza: use EJBs sim!
Seu caso pelo que descreveu é um caso classico de uso de EJBs. Eles te proporcionarão muitos beneficios. Pelo que vi você conhece, sabe para que servem, sabe aplicar, mas só está inseguro em usar. Então vá em frente. Separe sua logica de negócio em beans.
Eu prefiro não encher o projeto de complexidade logo de cara tentando adivinhar o futuro ou por empolgação tecnológica.
Faz um projeto sem interfaces remotas e evolua de acordo com a necessidade; ou você correrá o risco de perder tempo resolvendo problemas que não existem, e os que existirem, ficarão sem solução.
Acho que a dúvida dele não é se deve ou não usar EJB, e sim o lugar das regras de negocio que na minha opinião não devem ficar nos EJBs (ou seja lá o que vc vier a usar no servidor), mas sim classes java comum que são distribuídas em pacotes jar.
Bem, se essa é a dúvida então eu ainda acho que EJBs são melhores. Distribuir jars é um inferno, vocês sabem. Quando se tem 3 ou mais sistemas pra manter isso começa a ficar inviável se você tem manutenções praticamente toda semana. Pelo problema que eles explicou, creio que o uso de EJBs inicialmente já irá impedi-lo de cair em problema como distribuição de jars, o famoso jar hell!!!
O que o xdraculax comentou é muito interessante. É importante resolver os problemas que você tem agora. Mas, xdraculax, acho que pelo que ele explicou já é o caso de usar interfaces remotas sim. Ele mencionou o uso das entidades de negocio por vários sistemas. A não ser que eu tenha entendido errado…
[quote=andre2k2]
Bem, se essa é a dúvida então eu ainda acho que EJBs são melhores. Distribuir jars é um inferno, vocês sabem. Quando se tem 3 ou mais sistemas pra manter isso começa a ficar inviável se você tem manutenções praticamente toda semana. Pelo problema que eles explicou, creio que o uso de EJBs inicialmente já irá impedi-lo de cair em problema como distribuição de jars, o famoso jar hell!!![/quote]
Sem dúvida. Estava me referindo a distribuição entre equipes, não entre sistemas. Por exemplo, a equipe de desenvolvimento “distribui” o jar que contém as regras de negócio para a equipe de deploy colocar em produção.
Para distribuir entre sistemas, sinceramente, ninguém da a mínima o que vc usa, existem centenas de configurações, frameworks, EJB é uma.
Bom, fiz meus testes usando EJB3 e descobri algo que me incomodou bastante: para se usar a interface @Local (pelo menos no WebLogic), todas as aplicações deveriam ficar no mesmo EAR, já que a característica do WebLogic é de manter cada aplicação em um classloader separado (pelo menos foi o que eu entendi da documentação dele). O ruim de se fazer isso, pelo menos no meu ponto de vista, é que tudo ficaria em um lugar só, ou seja, daqui a uns 5 anos, por exemplo, a empresa teria um único arquivo EAR gigantesco que, caso desse algum problema no redeploy da aplicação (ou coisa parecida), todas as aplicações parariam de uma vez só.
Também fiz testes usando JARs separados: não sei se eu fiz alguma besteira ou se faltou configurar alguma coisa, mas não consigo acessar um JAR separado no servidor (o WebLogic chama de Shared Library): quando faço referência às classes do JAR, o servidor lança a exceção ClassNotFoundException. Só consegui resolver colocando os JARs dentro do próprio projeto web (ou seja, dentro do WAR). Mesmo assim, tive problemas com o Hibernate: ele não consegue entender que as classes estão dentro do JAR.
Então, fica minha pergunta: existe alguma forma de se resolver esse problema dos JARs ou terei que usar EJBs com @Remote?
[quote=vitorh.campos]Bom, fiz meus testes usando EJB3 e descobri algo que me incomodou bastante: para se usar a interface @Local (pelo menos no WebLogic), todas as aplicações deveriam ficar no mesmo EAR, já que a característica do WebLogic é de manter cada aplicação em um classloader separado (pelo menos foi o que eu entendi da documentação dele). O ruim de se fazer isso, pelo menos no meu ponto de vista, é que tudo ficaria em um lugar só, ou seja, daqui a uns 5 anos, por exemplo, a empresa teria um único arquivo EAR gigantesco que, caso desse algum problema no redeploy da aplicação (ou coisa parecida), todas as aplicações parariam de uma vez só.
Também fiz testes usando JARs separados: não sei se eu fiz alguma besteira ou se faltou configurar alguma coisa, mas não consigo acessar um JAR separado no servidor (o WebLogic chama de Shared Library): quando faço referência às classes do JAR, o servidor lança a exceção ClassNotFoundException. Só consegui resolver colocando os JARs dentro do próprio projeto web (ou seja, dentro do WAR). Mesmo assim, tive problemas com o Hibernate: ele não consegue entender que as classes estão dentro do JAR.
Então, fica minha pergunta: existe alguma forma de se resolver esse problema dos JARs ou terei que usar EJBs com @Remote?
Grato.[/quote]
Esse problema não é tanto dos EJBs, mas sim da configuração do seu servidor. Não sei no servidor que você está usando, mas no JBoss tem uma pasta que vai todos os jars usados na aplicação (/server/default/lib, para a configuração default). No WebLobic deve ter alguma coisa parecida.
Respondendo a sua pergunta inicial, se é projeto web eu não usaria EJBs, mas sim VRaptor, que, além de ser um framework de fácil utilização, já permite o consumo de serviços usando REST (o que tornam as coisas mais simples). Ou Spring.
