EJB ainda tem vez no Java EE 6? Fernando Lozano Consultor 4Linux lozano@4linux.com.br
Você Gosta do EJB? O EJB esteve por muito tempo na berlinda do mundo Java É pesado... É complicado... Código muito verboso Não aguento mais aqueles XMLs! É mais moderno usar IoC com Spring ou Guice!
Você gosta do EJB 3? O EJB 3, apesar de todas as melhorias e simplificações, foi ignorado por muitos desenvolvedores JSF + JPA fazem tudo o que eu preciso (CRUD) Spring já faz tudo o que eu preciso (apesar dos XMLs) Eu uso Guice! Eu uso Seam!
A Grande Novidade do Java EE 6 CDI Contexts and Dependency Injection Generaliza injeção de dependências e gerenciamento de contextos (ciclo de vida) para beans gerenciados Quase tudo é um managed bean do CDI Quase tudo pode ser injetado em um managed bean Tem @PreDestroy, interceptadores, decoradores e eventos Então pra que EJB?
Cadê a Camada de Negócios? Há muito se estabeleceu que uma boa aplicação separa responsabilidades em três camadas: Apresentação / Negócios / Persistência JSF: camada de apresentação JPA: camada de persistência Spring, Guice, Seam, CDI: cola entre as camadas Será que você não está misturando a lógica de negócios com as lógicas de apresentação e persistência, gerando código espaguetti em vez de três camadas ou MVC?
EJB == Camada de Negócios EJB é a única tecnologia do Java EE que foi criada para atender as necessidades da camada de negócios EJBs remotos formam uma implementação perfeitamente válida (e leve!) para uma arquitetura SOA É melhor criar Web Services usando EJB do que POJOs Extensões SOAP (WS-Transactions e WS-Security) se integram naturamente às capacidades do EJB Por que não REST com EJB?
Benefícios do EJB Deixando de lado o JPA, que deveria ser desde o início uma especificação à parte: Independência de localização ou remoting (distribuição / escalabilidade horizontal) Gerência de transações automática Reversão (programática) do estado em memória após um roolback Segurança declarativa baseada em roles Thread-safe sem sincronização Instâncias em pool
Mais Benefícios do EJB EJBs ainda oferecem integração facilitada com outros serviços do servidor de aplicação: Integração com JMS (MDBs) Agendamento (Timers) Gerenciabilidade (JMX) Alta disponibilidade / Clusterização
Extensões portáveis do CDI Vários recursos do EJB, por exemplo transações, poderão virar, em futuras versões do Java EE, extensões do CDI [Reza Rahman, CDI JSR member] Injected Beans do CDI == acesso via proxies Client view do EJB == acesso via proxies A implementação de EJB 2 e 3 em alguns servidores já era feita via proxies e em alguns casos até mesmo usando frameworks de AOP Então se o EJB for re-especificado em termos de CDI, ainda continua sendo o velho EJB ;-)
EJB + CDI == Evolução!= Revolução EJB 2: InitialContext + lookups EJB 3: @EJB, @Resource, @PersistenceContext Mas apenas em componentes Servlets, EJBs e às vezes Managed Beans JSF JSF Converters, Actions Struts, Helpers Classes, etc continuam usando InitialContext + lookup :-( Frameworks como Seam fazem sua própria injeção CDI: @EJB, @Resource, @PersistenceContext Funciona em qualquer POJO! Os frameworks não precisam mais reinventar a injeção! JNDI continua sendo usado por baixo dos panos
@Inject x @EJB, @etc CDI @Inject Type-safe Estereótipos Mesmo Classloader (mesmo pacote, mesma JVM) @EJB, @Resource, @PersistenceContext Strings (nomes JNDI) Compartilham recursos com outros pacotes dentro da mesma JVM Podem acessar componentes / serviços (EJB) em outras JVMs (outros app servers)
@Inject + @EJB, @etc Type safe + independente de localização Defina recursos JNDI como Producer Fields Injete os Managed Beans resultantes Use @Alternative para múltiplas implementações Se seus EJBs forem sempre locais, você pode usar @Inject em vez de @EJB, mas aí perde a independência de localização
CDI e EJB se complementam O CDI olha para dentro da aplicação Para que ficar mapeando um monte de <ejb-ref> entre componentes que nunca foram criados para reuso fora da sua aplicação de origem? O EJB olha para fora da aplicação Por que não reusar serviços oferecidos por outras aplicações Por que não aproveitar serviços de outros servidores de aplicações? Nenhuma aplicação verdadeiramente enterprise é isolada!
Uma Arquitetura com EJB + CDI Facelets Visão #{EL} POJO Controlador @EJB Fila JMS @Resource EJB Negócios @EJB @Inject JPA EntityManager @Persistence Context EJB ou POJO DAO Persistência Outro EJB
Programação x Configuração Algumas coisas ficam melhor gerenciadas pelo servidor de aplicações (e pelo administrador do servidor) Qual Datasource / Servidor de BD / Dimensionamento de pool para cada aplicação e cada ambiente? Onde está o EJB que fornece o serviço XPTO? Onde está o Web Service que fornece o serviço XPTO? Se tudo for feito via CDI puro, tudo é programação e recompilação (gerenciado pela aplicação)
Um pouco de XML faz bem Configurações devem ser externalizadas, portanto não deveriam ser anotações em código Java CDI beans.xml para implementações alternativas de um Managed Bean Descritor proprietário para linkar referências JNDI no ambiente local (java:comp/env) aos recursos globais ou remotos Mapeamentos completos JPA para facilitar a intervenção do DBA e otimizações do modelo físico
Conclusão EJB continuará sendo parte das próximas versões do Java EE... e não será como legado! Há vários benefícios em se usar também EJB nas suas aplicações O CDI não substitui o EJB O CDI torna o EJB mais fácil e mais acessível
Obrigado lozano@4linux.com.br www.4linux.com.br twitter.com/4linuxbr Tel: 55-11-2125-4747