Arquitetura Empresarial: usar Session Beans ou não?

Bom dia.

Como assim

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

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…

Olá,

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?

Session Beans é pra isso…
Principalmente se tem muitas aplicaçoes distribuidas
EJB 3 ESTÁ MUITO LEGAL

Use EJB.
Existem muitos recursos ao qual no futuro vc posso precisar.
Principalmente que sua aplicação deve ser escalavel.
flw!

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!

vitorh.campos:

Olá,

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?

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…

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!!!

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?

Grato.

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.

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.