Entendendo propósito JSR 299 : JCDI/Web Beans

Com pouco mais de 6 meses da especificação JSR 299 Web Beans ter sido aprovada, houve uma interessante entrevista com Gavin King, líder da especificação, quanto aos questionamentos levantados pelo pessoal do infoQ. Hoje, a especificação saiu da seção de public review, finalizada em 9 de fevereiro de 2009, conforme consta no site do jcp.

Recentemente, após processo de conclusão da seção pública ainda em versão draft da especificação, Gaving divulgou em seu blog, as mudanças existentes, após pedido de revisão pelo Expert Group, no qual implicaram algumas medidas enérgicas:

  • Qual o nome de batismo?
    • Modelo de componente, deve estar de acordo com outros existente na plataforma Java EE, portanto, nós do expert group te batizamos de JCDI, e não te chamarás mais de Web Beans!
    • Moral para isto eles têm!😀
  • Web Bean Manager ficou por conta do Java EE
    • A implementação deste recurso ficou por conta do Java EE
  • Empacotamento
    • Cada um no seu quadrado, javax.context, javax.inject, javax.event, javax.inject.manager
  • Possibilidade de DI de qualquer recurso Java EE
    • Agora é possível fazer injeção de dependência, desde referência de componentes remotas EJB até Web Services.
  • Melhor definição do uso dos metadados, bem como regras de herança
    • Praticamente um temlapte method para os Web Beans, onde será oferecido a partir de um generic bean, uma classe de template.
    • Segundo Gaving, esta melhoria provavelmente extinguirá o formato existente do deployment descriptor do EJB
  • Notificação de Eventos de forma assíncrona
    • Eventos do tipo Observer agora poderão receber notificação de objetos de forma assíncrona
    • Eles também poderão ser mapeados a partir de um JMS Topic, possibilitando sincronizar o estado de um evento com de outras camadas intermediárias, mesmo que seja em ambiente clusterizado
  • Novo recurso de fluxo por atividades
    • É possível agora, a partir da API, você definir o seu ciclo de atividades através de funcionalidades, de forma a gerenciar o estado inicial e final de seu ciclo, como utilizado em fluxo por processos, entre outros orientados à tarefas.
  • Configuração de DI para resolução de dependência de metadados
    • Adição de nova interface InjectPoint que possibilita fazer DI em casos que antes eram feitos:
      • Logger log = Logger.getLogger(MyClass.class.getName());
    • Agora pode ser escrito assim:
      • @Current Logger log;
  • Uniformalização dos Interceptors
    • Interceptor/Decorators se tornaram uma idéia para uso adjacente em conjunto com a API, tendo consequente remoção da especificação e consequente transformação das idéias motivadas a partir de um apêndice.

Então, teremos pouco mais de um mês se tudo correr bem para liberação do release final desta especificação, e provavelmente algumas semanas para liberação do Seam com implementação após mudanças.

Conforme o próprio Gavin mencionou, esta especificação tem sido fortemente influenciada pelos frameworks Seam e Guice, em que estes foram advindos de tendências interessantes motivadas pelo Spring.

Na verdade o Web Beans agora, se tornou uma especificação maior dentre as alternativas atuais(Spring, Seam e Guice), assim como houve transição similar do Hibernate com o JPA.

Só para entender um pouco das características padrões e fundamentais destes frameworks, a proposta inicial submetida desta JSR tem sido:

  • Changes to EJB 3 that will be needed for EJB’s to act as JSF managed beans
    • Facilitar compatibilidade entre EJB e JSF com recursos de DI. Conforme JSR, o Web Bean pode se tornar um EJB Bean, permitindo uso direto do EJB com qualquer página JSF
    • Para manter isto o Web Bean gerencia esta integração com JSF se beneficiando da própria API JSF
  • Annotations for manipulating contextual variables in a stateful, contextual, component-based architecture
    • Metadados para obtenção de modelos contextuais com estado(statefull), entre outros modelos de componente compatível
  • An enhanced context model including conversational and business process contexts
    • Modelo de componente que possibilite manter o estado conversacional entre contexto de modelo de objetos e o contexto de serviços que necessitam de permissas de regras de negócio, e por este motivo manter o estado conversacional ativo
  • Extension points to allow the integration of business process management engines
    • Modelo de componente para gerenciar escopo de fluxo de atividades, processos de gerenciamento de negócio ou orientados à tarefas
  • Integration of Java Persistence API extended persistence contexts
    • Integração facilitada com o EntityManager JPA com o Web Bean

Percebe-se então que o Web Beans procurou atacar mais estratégias de DI para dar suporte à nova especificação do Java EE 6 que está chegando, assim como o gavin mencionou após processo de revisão pelo expert group. Então, além dos propósitos acima mencionados, a especificação contempla outros importantes recursos como:

  • Decorators
    • Segue sua definição vide especificação no item 6.3, apesar de ter sido removido da próxima versão da especificação conforme citei anteriormente:
      • A decorator implements one or more API types and intercepts business method invocations for methods defined by the implemented API types. These API types are called decorated types.
    • Apesar de favorecer o mesmo propósito que o interceptor, a diferença está justamente na sua semântica, ou seja, o objetivo foi desacoplar como por exemplo, o gerenciamento de transação e segurança da lógica de negócio, motivando seu fim.
    • Por padrão, os decorators, são desabilitados, bastando declará-los no arquivo de configuração web-beans.xml, sendo obviamente chamados após interceptors, conforme consta no item 6.3.4.
  • Stereotypes
    • Segue sua definição vide especificação no item 2.7:
      • In many systems, use of architectural patterns produces a set of recurring Web Bean roles. A stereotype allows a framework developer to identify such a role and declare some common metadata for Web Beans with that role in a central place.
    • Interessante recurso que dispõe um meio de efetuar DI em um metadado, personalizando-o com outros metadados, afim de uniformalizar um comportamento padronizado, diminuindo o uso de anotações, necessitando apenas de um único metadado declarado, evitando assim o famoso Mega Zord.
    • Na especificação é existe a definição:
    • Existe um interessante artigo motivando uso de Stereotypes, relatando o fato de não ser um conceito novo e sim, apenas uma forma simples de implementar ao invés de usar herança com o design pattern template method
  • Deployment Types
    • Segue sua definição vide especificação sob o item 2.5:
      • Deployment types allow the Web Bean manager to identify which Web Beans should be enabled for use in a particular deployment of the system. The deployment type also determines the precedence of a Web Bean, used by the resolution algorithms specified in Chapter 4, Lookup, dependency injection and EL resolution.
      • Recurso que possibilita o desenvolvedor configurar um cenário de deployment para uma determinada implementação de uma API qualquer
  • Web Beans Scoped

    • Segue sua definição em especificação sob o item 2.4:
      • All Web Beans have a scope. The scope of a Web Bean determines the lifecycle of its instances, and which instances of the Web Bean are visible to instances of other Web Beans, as defined in Chapter 8, Scopes and contexts. A scope type is represented by an annotation type.
    • Importante recurso do Web Beans, são as definições de escopo e suas restrições, em que diferentemente do JSF, bem como Servlets, EJB e JavaBeans, impossibilita o uso de singletons e objetos stateless, necessitando que seu estado seja compartilhado pelo cliente, executados dentro de um mesmo contexto.
    • Também pode ser definido um escopo personalizado, utilizado pela anotação @ConversationScoped, que se beneficia do gerenciador de contexto, possibilitando também referenciar objetos dependentes deste estado conversacional através da anotação @Dependent
  • Events
    • Segue abaixo breve descrição em especificação no capítulo 7:
      • Web Beans may produce and consume events. This facility allows Web Beans to interact in a completely decoupled fashion, with no compile-time dependency between the two Web Beans. An event comprises:
        • A Java object (the event object)
        • A (possibly empty) set of instances of binding annotation types (the event bindings)
    • Possibilita um Web Bean propagar o estado de um produtor para consumidor, fazendo com que este efetue uma ação ao ser notificado de uma determinada mudança, utilizando a mesma semântica do design pattern Observer
  • Interceptors
    • Os interceptors sofreram alguns ajustes após processo de revisão, porém não custa lembrar de seu propósito, conforme especificação antes da revisão pública segue definição abaixo, apesar de ter sido removido da especificação, conforme citei anteriormente:
      • A Web Beans interceptor is a simple Web Bean with an implementation class that is also an interceptor class as defined by
        the EJB specification. Web Beans interceptors must declare at least one interceptor binding type.
      • A Web Beans interceptor may be either a business method interceptor, a lifecycle callback interceptor or both.
    • Interceptor são usualmente utilizados para resolver problemas de modularização para separação de preocupações, diferentemente dos decorators que são type-safes e que não podem ser utilizados para este caso

Enquanto isto a especificação Java EE 6 encontra-se disponível para revisão pública, e estará passível a mudanças, assim como houve com o JCDI/Web Bean.

Contudo, o processo de revisão do Expert Group me pareceu essencial para definir um modelo de componente e serviços possibilitassem maior integração com o modelo de componentes Java EE ao invés de criar um novo modelo de componente. A partir daí, podemos observar que a implementação nos motiva cada vez menos o uso do xemelê e mais tipagem segura.

Afim de deixar este artigo mais objetivo, disponibilizei um documento com referências e pesquisas que efetuei sobre o assunto, e sempre que possível estarei atualizando-o.

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: