Resolvendo dependências com CDI

Java EE, a plataforma mais usada para desenvolvimento de soluções server-side em todo o mundo, encontra-se atualmente em sua sexta edição e presenteará, em breve, toda a comunidade com um conjunto de melhorias e algumas novidades bem interessantes a partir do Java EE 7. Dentre estas novidades, encontra-se a aguardada API para Web Sockets, um grande salto evolutivo no paradigma de comunicação web, hoje essencialmente orientado a requisições e respostas formatadas de acordo com o HTTP(S).

Um dos mais notáveis recursos incorporados no Java EE 6, e que receberá uma atualização com o Java EE 7, é o da expansão do conceito de inversão de controle, conhecido publicamente na plataforma como CDI.

CDI é um acrônimo para Context and Dependency Injection, ou Injeção de Contextos e Dependências, e é o resultado de um árduo trabalho que surgiu a partir da JSR-299, originalmente conhecida como Web Beans. Com CDI, um dos problemas mais críticos da plataforma Java EE passou a ser gradativamente resolvido: a integração entre as diversas tecnologias que a compõem.

Quando falamos em inversão de controle no universo Java, a grande maioria da comunidade terá como primeira lembrança um dos mais populares projetos que atacam com bastante qualidade esta questão: o Spring. Esta reação é perfeitamente natural, pois a plataforma Java ficou, por muito tempo, sem uma resposta para este problema, embora a demanda estivesse sempre em uma ascendente. O projeto Spring, que pode ser compreendido como um framework, é modular, muito poderoso e mantido por uma divisão da VMware conhecida como SpringSource. A partir de seus inúmeros módulos, oferece abordagens bastante maduras para atacar problemas e necessidades corriqueiras no dia a dia do desenvolvimento de soluções computacionais, por meio de templates e APIs relativamente simples de usar, acelerando muito o processo de desenvolvimento de software. Algumas dessas necessidades estão listadas a seguir:

· Integração entre sistemas, atacada com o Spring Integration (que, em muitos casos, possui recursos suficientes para, por exemplo, substituir soluções mais completas como o Apache Camel);

· Injeção de dependências, atacada com o Spring DI;

· Segurança, atacada com o Spring Security;

· Integração facilitada com redes sociais, atacada com o Spring Social.

Por se tratar de um projeto open source, acaba atendendo em uma velocidade significativamente maior as principais demandas do mercado. Entretanto, é importante perceber que, ainda assim, não é parte constituinte da plataforma Java propriamente dita. Embora seja uma solução que apresente estabilidade e seja conduzida por uma empresa que sempre manteve uma postura confiável em relação ao rumo da tecnologia, não apresenta as garantias definitivas de que estarão ali suportando o desenvolvimento de nossas soluções Java para sempre.

As especificações Java, por sua vez, são o resultado de um processo bastante rígido e cauteloso de estudo, que envolve um grande número de membros que, reunidos na forma de grupos de experts, trabalham na definição de especificações de tecnologias e funcionalidades que o Java suportará ao longo do tempo. Isto envolve toda a comunidade, constituída de participantes dos mais variados tipos e, principalmente, com os mais variados níveis de influência no mundo da tecnologia. Profissionais de empresas de todos os portes estão trabalhando, unidos, na definição de rumos que atendam de maneira satisfatória todo o ecossistema que depende da plataforma Java, o que atribui a cada especificação aprovada uma solidez muito grande, uma força incomparável a qualquer outra abordagem que, eventualmente, ataque os mesmos requisitos. Trata-se de padrões de facto, um novo conjunto de features e melhorias da plataforma Java propriamente dita.

E foi isto que aconteceu com o CDI, que será nosso foco de estudo ao longo deste artigo. Recomendamos, inclusive, que o leitor fique bem atento à evolução do Java EE 7 até seu lançamento, pois contaremos com uma revisão desta especificação, passando do atual CDI 1.0 para o CDI 1.1. O tempo não para!

Motivação

Toda especificação é seguida, normalmente, de uma implementação de referência. No caso específico de CDI, esta implementação atende pelo nome de Weld, mantida pela mesma comunidade que desenvolve o framework Seam. A partir desta implementação de referência, é possível que surjam outras, como aconteceu com o JavaServer Faces. Neste último caso, a implementação de referência (Mojarra) foi seguida de outras opções, mais ou menos poderosas e interessantes, dentre as quais podemos citar o PrimeFaces, RichFaces e ICEfaces. O mesmo acontece com basicamente todas as outras especificações que compõem a plataforma Java EE.

CDI atende, como já sabemos, por Context and Dependency Injection, ou “Injeção de Contextos e Dependências”. É o resultado do trabalho em torno dos requisitos que compõem a JSR-299, originalmente intitulada Web Beans. Entretanto, é importante destacar mais duas JSRs que colaboraram para o estabelecimento dos conceitos atacados pela especificação do CDI, a saber:

· JSR-330: “Injeção de dependências para Java”;

· JSR-316: especificação da plataforma Java EE, e o que tange CDI está detalhado em uma ramificação desta JSR que enuncia o conceito de beans gerenciados.

Em poucas palavras, CDI engloba uma estratégia pensada no sentido de tirar do desenvolvedor a responsabilidade de trabalhar diretamente com a criação de objetos e o estabelecimento das relações entre eles. A consequência direta disso é que, não mais trabalhando diretamente na criação desses objetos, deixamos por conta de um agente intermediário sua manipulação. Logo, passamos a não ser mais responsáveis, também, pelo gerenciamento do ciclo de vida desses objetos, função que este agente, que chamaremos de container (e que, em última instância, pode ser entendido como um dos serviços prestados às nossas soluções pelo servidor de aplicações), passará a exercer por nós.

Fazendo uso desta “máquina de gerenciamento de objetos”, o container, somos agora capazes de solicitar que ele estabeleça os relacionamentos entre objetos por nós, através de muita configuração e alguma implementação. Veremos que os recursos que englobam a especificação CDI nos permitem desenvolver sistemas com baixíssimo grau de acoplamento entre os componentes, gerenciados em boa parte pelo próprio container, através de estratégias muito simples e eficientes.

O CDI não possui um modelo próprio de componentes. Consiste em um conjunto de serviços que pode ser consumido por componentes de todas as especificações que integram o Java EE, como: JSF, JPA, EJB, JSP, JMS, dentre outras. Desta maneira, resolveu-se um problema que há muito tempo assolava a plataforma, permitindo-se, agora, uma integração simples e direta entre elementos de especificações diversas entre si, empregando-se um conjunto bastante reduzido (mas extremamente poderoso) de anotações, um maravilhoso presente do Java 5 para todos nós.

Com CDI, podemos transformar um objeto qualquer (POJO) em um bean e delegar o gerenciamento de seu ciclo de vida ao servidor de aplicações. Além disso, permite que indiquemos os pontos, dentro de outros beans, em que uma referência a um objeto deve ser incluída.

Ao longo do artigo, exploraremos o CDI exemplificando seus inúmeros atributos, conceitos e serviços a partir de um projeto web, que estará disponível para download a partir do site da Java Magazine.

Introdução ao CDI

Para entender bem CDI, acreditamos que seja importante analisar com cuidado os termos que o constituem e, também, aqueles que estão implicitamente relacionados à especificação.

O primeiro conceito relevante aqui é o de bean. Afinal, o que é um bean? ...