Duas novas especificações de Java EE: EJB 3.1 e CDI. Estas tecnologias possuem, por vezes, funcionalidades que se sobrepõem, e parece possível substituir EJBs por CDI. É realmente possível? Como? É vantajoso? Veremos respostas para estas perguntas neste artigo.
Em que situação o tema é útil:
Tanto CDI quanto EJB 3.1 são especificações oficiais Java EE, de modo que é muito positivo conhecê-las. Além disto, e ao contrário de várias especificações, são tecnologias muito simples, práticas, úteis e poderosas. Assim, é conveniente que o desenvolvedor as conheça para saber quando é positivo utilizá-las, como integrá-las ou mesmo como substituir uma por outra.
Resumo DevMan:
O desenvolvedor Java EE pode se sentir confuso diante da versão 6 da plataforma porque algumas tecnologias parecem se sobrepor – notadamente EJB e CDI. Sendo EJB uma tecnologia tradicionalmente complicada e improdutiva, o programador se pergunta se é possível substituir EJB por CDI, e como fazê-lo. Este artigo explorará as duas possibilidades: trocar EJB por CDI ou usar CDI com EJB. Veremos que ambas são viáveis, e que a segunda opção pode ser vantajosa.
Enterprise JavaBeans (EJBs) sempre foram componentes supervalorizados pelas especificações Java EE. Entretanto, sua adoção foi menor do que o esperado de uma tecnologia oficial tão central. A principal razão é a imensa complexidade de desenvolvimento. EJBs exigiam a criação de várias interfaces, frequentemente redundantes; o empacotamento de componentes em intricadas estruturas de pacotes; o uso de servidores de aplicações complexos e pesados etc. Todas estas desvantagens elevavam muito o custo inicial de se usar EJBs, de modo que sua adoção se manteve mais ou menos restrita a grandes organizações. Como alternativa à complexidade, surgiram frameworks leves, como Spring, que proviam várias das vantagens de EJBs com muito menos recursos e complicações.
As especificações da plataforma corporativa de Java, porém, evoluíram para tornar EJBs mais palatáveis. A API Java EE 6 foi o mais recente e significativo passo nesta direção, com a especificação EJB 3.1. Esta versão dispensa muito da complexidade tradicionalmente associada à arquitetura, provendo inclusive um pequeno mas significativo subconjunto da especificação maior, chamado EJB Lite.
Por outro lado, Java EE 6 também provê um novo modelo de gerenciamento de objetos chamado de Contexts and Dependency Injection (CDI). Esta especificação (redigida na JSR 299) acrescenta a Java EE um sistema de injeção de dependências e o conceito de escopos, além de várias funcionalidades como eventos, interceptadores, entre outros. Muito de CDI foi inspirado em alternativas à EJB, como Spring, Guice e Seam. Muitas funcionalidades que eram formalmente suportadas apenas por EJBs podem, agora, ser utilizadas através de CDI. Ademais, CDI é mais simples que EJBs – inclusive a versão 3.1 – e, semanticamente, é mais poderoso e flexível.
A sobreposição de funcionalidades das duas tecnologias levantou suspeitas e gerou boatos sobre o futuro de Java EE e, especialmente, dos EJBs. Por exemplo, vários desenvolvedores já cogitam substituir completamente EJBs por CDI. É bem verdade que a JSR 299 especifica como EJBs devem ser relacionados com a nova arquitetura de injeção de dependências, e a documentação de Weld (a implementação de referência de CDI) recomenda o uso de EJBs “quando se precisa dos serviços que eles provêm.”. Entretanto, muitos se perguntam: por que usar EJBs quando estes mesmos serviços podem ser usados através de CDI, só que de forma muito mais simples? Aliás, pode CDI realmente fornecer todas as funcionalidades providas por EJBs? É o que veremos neste artigo.
Uma breve história dos EJBs
O conceito de EJB surgiu no final dos anos 90 e início da década passada. O propósito principal da arquitetura era prover um meio padronizado de se desenvolver a lógica de negócio de uma aplicação, em oposição à lógica da interface com o usuário. Com EJBs, teoricamente seria possível executar toda a lógica de uma aplicação em um ou mais servidores, utilizando qualquer tipo de interface. Assim, a lógica da aplicação – validação, processamento de dados, persistência etc. – rodaria no servidor, e interfaces dos mais variados tipos – applets, programas em Swing, aplicações web etc. – apenas invocaria os métodos da aplicação. Os diversos EJBs seriam utilizáveis da mesma maneira, independentemente de estarem no mesmo servidor ou não – isto é, seriam distribuídos de maneira transparente ...
