EJB 3.1, preparem-se

É, Bill Burke bem que tentou, mas ainda não será dessa vez que teremos “EJBs POJO”. Sim, estou falando do draft da JSR 318 que saiu no último dia de Fevereiro e que deve fazer parte da Umbrella JSR 316.

EJBs POJO podems ser vistos como classes Java normais, as quais simplesmente estão marcadas com @Stateless ou @Stateful e não precisam implementar nem estender nada. Seria algo como:

@Stateles class Clientes {

public double getSaldoConsolidado(Cliente c) {

// código EJB

}

Para os menos atentos, observem que um código do lado cliente seria algo como:

Clientes clientes = ServiceLocator.getInstance().lookup(Clientes.class);

double saldo = clientes.getSaldoConsolidado( new Cliente(1234));

System.out.println(saldo);

Sacaram? Pois bem, é justamente essa a discussão que o tio Bill puxou no seu site. Muita gente discordou, porque agumenta que o cliente teria acesso ao código da implementação do EJB (visto que não existe mais uma interface client para eles) ou que existiria um alto acoplamento entre lado cliente e lado servidor, ou...bem, vários argumentos!

Tio Bill enfatiza que isso seria um improvement, mas mesmo assim não pegou e, pelo menos nessa versão 3.1, ainda não teremos Enterprise POJOs...

O que teremos, então?

Mesmo não tendo EJBs realmente planos, teremos uma série de outras features, há muito aguardadas. Para ser enxuto, replico aqui o que diz a seção 1.2 da nova especificação (ainda em draft até o próximo dia 30):

• Acesso direto de EJBs pela camada web dentro do mesmo EAR: A anotação @EJB já é uma commoditie (mesmo que sistemas homéricos tendem a subestimá-la) e é uma mão na roda para chamadas entre serviços dentro do container EJB. Ela encarrega-se de propagar o principal da chamada e todos os trâmites para gerenciamento das transações na aplicação. Porém, a boa nova é que agora ela pode ser usada diretamente pelo container web. Assim, um código de servlet pode injetar EJBs sem se preocupar com lookups por classes utilitárias. Claro, um certo overhead (?) de configuração pode ser necessário, a fim de garantir que as roles na web e nos EJBs sejam compatíveis. Também, devemos ter o cuidado disso tudo estar no mesmo Application Unit e temos o inconveniente de ter que usar (sempre) referencias locais e não podemos distribuir a aplicação em JVMs e containers separados (exceto ativando Trusted Connections). Mesmo assim, é uma benévola para os desenvolvedores web e, claro, essas limitações que eu comentei são coisas intrínsicas ao padrão atual e, com sorte, em um Java EE 7 ou 8 isso deve ser eliminado.

• Empacotamento de EJBs dentro de arquivos WAR: Para mim, isso não é um grande benefício. Quem usa ANT ou Maven (ou qualquer outra ferramenta do gênero) não se preocupa muito nesse tipo de picuínha. Porém, pode ser uma diferença grande no ambiente de execução. Se o container for Java EE certificado, ele devera colocar para funcionar o .WAR integralmente, com as JSPs e também com os EJBs. Isso me lembra muito o Tomcat com o EJB Embedded e parece que os caras estão começando a misturar as coisas. A palavra Web ARchive deveria exprimir a função do pacote, mas pelo jeito ela também agora é outra commoditie. Não li muito sobre as entranhas disso ainda mas, enfim, essa tendência de reduzir artefatos está mesmo em voga.

• EJBs Singleton: Isso me deixa feliz. Mas em parte. Primeiro, feliz por ter singletons em EJBs. Aos puristas, vão reclamar que isso pode ser pesado e que pode trazer outros malefícios, como afunilamento de chamadas de clientes e tal. Mas isso é um engano. Quem nunca tentou fazer um código maluco para simular (sim, simular) singletons em EJBs que atire a primeira pedra! Se não tentou ainda, é porque não teve que passar por mal bocados. Singletons em containers é uma tarefa difícil, e em ambientes de alta concorrência a coisa pode render boas noites de pizza e coca-cola. Poder anotar um EJB com @Singleton, e indicar ainda se ele vai ter dependências de inicialização, comportamentos @ReadOnly, @ReadWrite ou ainda se vai ser gerenciado manualmente (tal como os famigerados modelos BMP para os Entity Beans) é, sem dúvida alguma, um ponto positivo nesse release da especificação. Porém, fico triste de os caras não terem ido além (sim, talvez eu seja muito perfeccionista mesmo). Singletons são garantidos por container e, assim, em ambientes clusterizados cai novamente para o desenvolvedor a tarefa de comer pizzas nas madrugadas.

• Timers criados automaticamente: Isso é outra coisa que eu aprovo. Até a versão 3, tínhamos que explicitamente ativar um EJB de timer para, somente então, ele começar a trabalhar. Agora, com as features de @Startup, as coisas mudam de figura. Em tempo de deployment o container já se encarrega de localizar e ativer os timers conforme nossa necessidade. Nada mais de consoles com métodos admistrativos (muitas vezes operando com sistema de autenticação diferenciados e avessos aos interceptadores padrões do sistema) para ativar essas pecinhas!

• EJBs Assíncronos: Isso só pode ser herança do AJAX. Mas é uma herança boa, ao meu ver. Também, até a versão 3, toda chamada para um EJB é síncrona, o que implica que o cliente (ou melhor, a thread chamadora deste) deve ficar parado até que o retorno do método de EJB ocorra. E isso pode ser um tempo perdido muito grande. Soluções seriam usar AJAX (e fazer uma sincronização manual no lado cliente) ou lançar mão de JMS para esses métodos mais demorados. Agora, poderemos usar em tranquilamente a API java.util.concurrent.Interface Future, que já existe no Tiger há muito tempo... Com isso, o cliente deixa de ficar ocioso e pode trabalhar tranquilamente até que sua requisição EJB tenha uma resposta. Como Future é um objeto criado pelo servidor e retornado para o cliente, o cliente tem um link do servidor para, tanto monitorar o momento em que uma reposta ocorra, tanto para...cancelar sua requisição. Isso mesmo, diferente de AJAX, que o cliente deveria lançar outra requisição de EJB (e fazer uma lógica maluca para garantir o funcionamento de requisições Stateless no pool do servidor) para efetuar o cancelamento da chamada original, agora Future encapsula tudo para nós e deixa tudo transparente. Imaginem as possibilidade, meninos...

• Profiles: Lembram do Java ME e seus profiles? Pois bem, agora a Java EE está nessa onda também. A idéia é que, como a tecnologia Enterprise do Java está crescendo muito e, por isso ela pode facilmente se tornar um canhão para matar moscas, a própria especificação já cuide para criar subconjuntos de componentes para os containers. Seria como ter um container Web, um container Web com EJB Light, um container WebService com EJB, etc. Na prática, isso já vem sendo implementado pelos containers atuais, como o JBoss, que traz seus diretórios minimal, default e all. A diferença é que agora a Umbrella estaria ditando quais são esses profiles e o que deveria existir dentro deles. As picuinhas entre os prós e contras é grande, sendo que uns argumentam que isso não deve ser preocupação do JCP ou que abriria brechas para meias-certificações, algo como um provider certificar somente parte do seu servidor e o restante deixar numa versão mais antiga, ainda não homologada pelo TCK. Na minha opinião, tanto faz.

Conclusões

Conheço muita gente que ainda nem usa o JDK 5. Muitos também são avessos às anotações, tipos genéricos e conceitos um pouco mais avançados, como Resources, Múltiplos Classloaders, WebServices, etc. Para todos eu digo: corram (bastante), rapazes!

Java evolui a passos largos, e se a tendência é seguir novidades oriundas do pessoal do Spring, Ruby, Smalltalk, Groovy e outros. Assim, um ajuste pequeno como esse na especificação EJB deveria se passar como manteiga sobre o pão.

Para mim, todas as features são bem vindas e, para ser sincero, espero muito mais para os próximos releases. Se a idéia do tio Bill de usar EJBs POJO não vingar, quiçá me deixem usar a mesma anotação para EJBs locais e remotos. Só isso já seria uma mão na roda.