WebBeans - Um EJB para o dia a dia?

Vou dar minha opnião, mas não sou expert no assunto…

O WebBeans (que mudou de nome a pouco tempo), não faz somente que o um ManagedBean vire um EJB tem toda uma especificação de Injeção e Ejeção, escopos, etc etc…

1. Mais sim, uma das possíveis coisas é tornar um MB um EJB. Vantagem nisso? Só vejo vantagem para quem precisa acessar um EJB remotamente. Deste modo escreveremos menos código…

2. A anotação @PersistentContext só funciona em um EJB, se o MB for um EJB, essa anotação também funcionará lá dentro. O que não muda muita coisa já que no Seam (Bem parecido com o WebBeans), mesmo que seu MB não seja um EJB é possível injetar um EntityManager através da anotação @In.

Agora também acho que não faz sentido algum utilizar EJB se vc não precisar de Balanceamento de Carga, Alta Disponibilidade, Acesso Remoto (também possível através de outras técnicas) ou Processamento em Fila.

No local onde trabalho ultimamente que é uma empresa de grande porte todos os sistemas Java utilizam EJB e todos eles estão integrados, funciona bem, mas a manutenção é muito trabalhosa. Acredito que soluções SOAP ou REST resolveriam os problemas de integração da empresa e tornariam o desenvolvimento bem mais simples.

O WebBeans era parecido com o Seam (usava até as mesmas anotações), mas foi mudando com o tempo e ficou mais parecido com o Guice. Em termos gerais, o Web Beans é um container de injeção de dependências (como é o Spring ou o Pico), mas se escora na tecnologia do EJB.

Então, pra responder suas perguntas, é preciso fazer uma pergunta fundamental: por que usar um container de injeção de dependências? É meio complicado pra responder, mas é basado no princípio de aberto-fechado (aberto para extensão, fechado para modificação), ou seja, o ideal é ter classes facilmente configuráveis bastando mudar os objetos de seus atributos. Como isso dá trabalho de configurar (precisa criar factories), o container de DI acaba quebrando um galhão, possibilitando um sistema modular e extensível. (Claro, dá pra criar sistemas engessados mesmo usando Spring ou Guice, mas vamos desconsiderar a burrice humana nesse momento.)

O WebBeans vai estar lá pra preencher a lacuna do container de DI que não havia antes na especificação e de quebra, vai flexibilizar ainda mais o EJB (que mesmo já sendo fácil de usar na versão 3, ainda tinha seus pepinos). E não acho que dá pra gerenciar a transação usando apenas o Jetty. Eu já tentei de tudo, mas sempre acabo misturando lógica de transação com lógica de negócios numa mesma classe. Por isso que não dá pra fugir de um container de DI.

Com relação ao tamanho do sistema, o EJB serve sim pra sistemas pequenos.

Hmm, obrigado pelas respostas. Talvez eu deva estudar um pouco mais EJB e alguns outros conceitos para que eu tenha a minha opinião formada claramente. Mas em fim, Leonardo tu disse que EJB pode ser usado em aplicações pequenas? Pode ser usado e realmente vai melhorar a produtividade? Ou meramente pode ser usado? Faço algumas perguntas em cima disso:

1 - Você usaria EJB para fazer um sistema de gerência de vendas de alguma loja pequena, como uma construtora sei lá.
2 - Faria sentido usar EJB mesmo para o clássico exemplo da “Locadora”?
3 - Usar o Seam sem EJB não seria melhor em ambos os casos a cima?
4 - O GUJ esta usando Jetty, ele foi criado do 0 não foi? Ele está usando EJB? (Afinal o guj recebe vários acessos e tal…)

Bem, não sou tão entendido assim de injeção de dependência mas, então o WebBeans vai s ser um padronização do que temos no Seam hoje (a grosso modo dizendo), para qualquer aplicação Web em java?

Obrigado mais uma vez.

Israel

Eu não acredito que nenhuma tecnologia melhore significativamente a produtividade (no máximo uns 10%), não atribuo a isso nem ao hypado Rails.

Se for um sistema web, sim. (Nunca programei desktop.) Mas tomaria a liberdade de usar o EJB 3.1, cujo deployment pode ser feito dentro de um war. Ou então optaria pelo Spring.

Faz sentido “locadora” em tempos de Netflix e torrents? O que quero dizer é que o sistema Desktop que usa conexão TCP ou escrita em disco é coisa do passado, assim como a própria locadora.

Agora, se eu fizesse um site, e fosse em Java, usaria um container de IoC, seja ele EJB, Web Beans, Guice ou Spring.

Não, sem EJB, o Seam é bastante limitante. Não há controle transacional automático.

Eu não sei, eu nunca participei da construção desse site, e nem nunca fui curioso pra investigar o código-fonte. Não estou dizendo que sem EJB, você não consegue fazer um site com vários acessos. Consegue sim! O problema é a organização do código, pois o trecho de transação se mistura ao trecho de negócio. E isso deixa o código meio ilegível.

Mais ou menos. É so uma fundação sólida para que o Seam funcione sem problemas. O WebBeans é um Seam beeem pelado.

Hmm, mais uma vez não sou um grande intendido mas deixe-me tentar argumentar.

O Seam tem o chamado “Seam managed transactions”, que funciona mesmo num ambiente sem EJB muito bem (até onde eu saiba e tenha usado), amarrando as transações em volta das requisições. E também tem o entity-manger com escopo de conversação que pode ser usado por mais de uma requisição e tal. Então não tem o código sujo de transações apenas o famigerado:

@In
EntityManager em;

Quando você diz que não há controle transacional automático é sobre isso? Ou a mecânica que acontece por trás não funciona tão bem?

Meu grilo não é tanto com EJB em si, é que vejo o pessoal ao meu redor que usa, e a maioria realmente não sabe porque esta usando eles. A melhor aposta é quando falam do controle transacional, mas esse controle não é isso que o Seam pode fazer num tomcat, jetty da vida sem EJB e que o Spring também pode fazer?

Acho que na real MESMO, meu grilo é: Quero usar o servidor mais light-weight possível tipo um jetty, e ter o controle transacional feito de forma simples. Coisa que o EJB além de me fazer ter que ter um pesado Jboss, interfaces, e uma camada extra de código me impõe, além de ter que deployar tudo como EAR. Quem vai me solucionar isso? O EJB 3.1 que citastes?

Mais uma vez obrigado. E não briguem comigo por parecer chato. Só quero conhecimento.

Bom vamos lá, a primeira letra da sigla significa Enterprise. Isso dá a idéia da dimensão e do tipo de atribuições que a tecnologia lida - problemáticas.

Computação distribuída, controle transacional - como citado, serviço de mensageria e por aí vai.

Se o seu modelo de negócios é simples, ou atendido de uma maneira simples, não faz sentido adicionar complicômetros à sua arquitetura.

Por mais que a especificação hoje seja uma maravilha, comparando às versões anteriores, ainda sim exige um esforço maior de desenvolvimento, um bom container, hardware, tunnings, pois não adianta instalar somente o Application Server de forma default.

Lembre-se sempre do Kiss - Keep it Stupid Simple e seja feliz :-).

Um bom desenho possibilitará futuramente você adicionar características à sua aplicação, como EJB, já que hoje é baseada em metadados (annotations), trasnformando aquela sua classe de negócio em um EJB facilmente.

Quanto ao seu maior problema, controle transacional, IoC, existe uma solução muito boa - Spring, que hoje vem com o kit da felicidade - Annotations, tornando as coisas mais simples

Mestre Kenobi, tu saberia dizer um “Caso de Uso “Hello World”” para o uso de um EJB? Porque nem isso eu tenho claro na minha mente. :?

Caso de HelloWorld poderia ser uma Mensagem enviada de forma assícrona para uma fila que possui um processo que ouve a mesma. Este não pode correr o risco de estar fora do ar, e ao processá-la, vai sensibilizar uma base dados de acordo com as informações.

Aqui vc pode desenhar usando MDB + SessionBean em Cluster (FailOver) + EntityBeans com controle transacional.

Hmm, acho que intendi. Mas ainda é muito conteudo para a minha cabeça :). Por isso vou e pergunto, Tomcat/Jetty vão suportar EJB 3.1 lite?

Já me intrometendo, um exemplo: digamos que você precise desenvolver um sistema de gestão para uma pequena rede de supermercados. Seu aplicativo tem de dar suporte a, por exemplo, uma interface desktop para os pontos-de-venda, outra interface desktop para o pessoal administrativo, uma interface web para o serviço delivery, e uma interface PDA/Mobile para a equipe que fica fazendo balanço nos estoques e para controle da equipe que faz delivery.

Nesse exemplo (não tao simples) você pode usar desenvolver o servidor e interligar as diferentes interfaces usando EJB Remote para os desktop, EJB Local para a web, JAX-WS (webservices) para os PDAs, JTA para gerenciar as transações dentro do servidor, JPA para persitência, JMS para garantir a entrega de mensagem entre os supermercados e a central, JAAS para autenticação, alem de serviços acessórios como o Timer e EmailService. E agora IoC com o WebBeans.

Sim, dá para fazer tudo isso usando frameworks mais leves e, muitas vezes de maneira mais simples. Por isso que até a versão 3.0, EJB era uma piada de mal gosto. Isso levou ao surgimento de alternativas como o Spring, Hibernate, Axis, etc. Mas ter uma interface padrão tem suas vantagens e nos ultimos anos o pessoal tem se esforçado para transformar as tecnologias “de facto” em padrões.

Depois desse rodeio todo, estritamente falando EJB é uma tecnologia para acessar objetos de forma remota, tipo XML-RPC, mas de forma nativa, em Java. Se você precisa conectar seu client Swing a um servidor remoto e está disposto a carregar o peso de um container J2EE, EJB é uma excelente opção. Se sua aplicação roda na mesma instancia JVM (web servlets, por exemplo) , você pode usar o EJB usando a interface Local e aproveitar vantagens do container como message queues, transações distribuídas, etc.

Sim. EJB é para sistemas distribuídos, parrudos, de auto-disponibilidade e missão crítica. Se vc quer cluster então EJB pode ser uma boa, se bem que há soluções de cluster muito boas sem EJB: Terracota e JGroups.

Nada, porque sistemas de pequeno porte podem e devem passar longe de EJB. Há séculos que descobriu-se que esse é o maior overkill de todos.

Por que vc usa component-based? Já tentou action-based full-stack? Coloquei um site no ar em menos de 30 dias com o Mentawai, e olha que o sistema do site não é simples não.