Beans Assíncronos

Um bean assíncrono é um objeto Java™ ou enterprise bean que pode ser executado assincronamente por uma Plataforma Java, aplicativo Enterprise Edition (Java EE), usando o contexto Java EE do criador de bean assíncrono.

Recurso Reprovado Recurso Reprovado: Os Beans assíncronos e o CommonJ Timer e o WorkManager são recursos de planejamento assíncrono descontinuados. O Concurrency Utilities for Java EE substitui esses recursos de planejamento descontinuados. A Versão 9 ainda suporta beans assíncronos e o CommonJ Timer e o WorkManager. No entanto, a documentação da Versão 9 concentra-se no Concurrency Utilities for Java EE. Se não puder localizar as informações sobre beans assíncronos buscadas na documentação da Versão 9, consulte a documentação da Versão 8.5.5.depfeat

Os beans assíncronos podem melhorar o desempenho ativando um programa do Java EE para decompor operações nas tarefas paralelas. Os beans assíncronos suportam a construção de stateful e ativam aplicativos Java EE. Esses aplicativos tratam um segmento do espaço do aplicativo de aplicativos que requerem encadeamento de aplicativos, agentes ativos em um aplicativo do servidor ou recursos de monitoramento distribuído.

Os beans assíncronos podem ser executados usando o contexto de segurança do Java EE do componente Java EE do criador. Esses beans também podem ser executados com cópias de outros contextos do Java EE, como por exemplo:
  • Contexto de Internacionalização
  • Perfis do aplicativo, que não são suportados para aplicativos Java EE 1.4 e que são descontinuados para aplicativos Java EE 1.3
  • Áreas de trabalho

Interfaces do Bean Assíncrono

Existem quatro tipos de beans assíncronos:
Objeto de trabalho
Existem duas interfaces de trabalho que basicamente alcançam o mesmo objetivo. A interface de trabalho de Beans Assíncronos legados é com.ibm.websphere.asynchbeans.Work, e a interface de trabalho CommonJ é commonj.work.Work. Um objeto de trabalho é executado em paralelo a seu responsável pela chamada utilizando o método startWork ou schedule do gerenciador de trabalho (startWork para Beans Assíncronos legados e schedule para CommonJ). Os aplicativos implementam os objetos de trabalho para executar blocos de código de forma assíncrona.
Listener de Cronômetro
Esta interface é um objeto que implementa a interface commonj\timers\TimerListener. Os listeners de cronômetro são chamados quando um cronômetro transitório de alta velocidade expira.
Atendente de alarme
Um atendente de alarme é um objeto que implementa a interface com.ibm.websphere.asynchbeans.AlarmListener. Os atendentes de alarmes são chamados quando um alarme transitório de alta velocidade expira.
Atendente de evento
Um atendente de evento pode implementar qualquer interface. Um listener de eventos é um mecanismo de notificação assíncrona, leve para eventos assíncronos em uma única Java virtual machine (JVM). Tipicamente, um listener de eventos, ativa os componentes do Java EE em um único aplicativo para notificar um ao outro sobre vários eventos assíncronos.

Interfaces Suportadas

Gerenciador de trabalho
Gerenciadores de trabalho são conjuntos de encadeamentos que os administradores criam para os aplicativos Java EE. O administrador especifica as propriedades do conjunto de encadeamentos e uma política que determina quais contextos do Java EE o bean assíncrono herda.
Gerenciador de Trabalho CommonJ
O gerenciador de trabalho CommonJ é semelhante ao gerenciador de trabalho. A diferença entre os dois é que o gerenciador de trabalho CommonJ contém um subconjunto dos métodos do gerenciador de trabalho de beans assíncronos. Embora o gerenciador de trabalho CommonJ funcione em um ambiente Java EE 1.4, cada consulta do JNDI de um gerenciador de trabalho não retorna uma nova instância do WorkManager. Toda a consulta JNDI de gerenciadores de trabalho em um escopo possui a mesma instância.
Gerenciador de Cronômetro
Os gerenciadores do cronômetro implementam a interface commonj.timers.TimerManager, que ativa os aplicativos Java EE, incluindo servlets, os aplicativos EJB e Adaptadores de Recursos JCA, para planejar futuras notificações do cronômetro e receber notificações do cronômetro. O gerenciador de cronômetro para a especificação de Servidores de Aplicativos fornece uma alternativa suportada por um servidor de aplicativos para utilizar a classe de J2SE, java.util.Timer, que não é apropriada para ambientes gerenciados.
Fonte de eventos
Uma fonte de eventos implementa a interface com.ibm.websphere.asynchbeans.EventSource. Uma fonte de eventos é um objeto fornecido pelo sistema que suporta um servidor de notificação assíncrona, seguro e genérico em uma única JVM. A fonte de eventos permite que os objetos listeners de eventos, que implementam qualquer interface, sejam registrados.
Eventos da fonte de eventos
Cada fonte de eventos pode gerar seus próprios eventos, tais como contagem de listeners alterados. Um aplicativo pode registrar um objeto listener de evento que implementa a classe com.ibm.websphere.asynchbeans.EventSourceEvents. Essa ação permite que o aplicativo capture eventos, como listeners sendo adicionados ou removidos ou um listener emitindo uma exceção inesperada.

Interfaces adicionais, incluindo alarmes e monitores de subsistema, são introduzidas no tópico Desenvolvendo Escopos Assíncronos, que discute alguns dos aplicativos avançados de beans assíncronos.

Transações

Todo método de bean assíncrono é chamado utilizando sua própria transação, muito semelhante às transações gerenciadas pelo contêiner em beans corporativo típicos. É muito semelhante à situação quando um método do Enterprise JavaBeans (EJB) é chamado com TX_NOT_SUPPORTED. O tempo de execução inicia uma restrição de transação local antes de chamar o método. O método do bean assíncrono será livre para iniciar sua própria transação global, se essa transação for possível para o componente Java EE de chamada. Por exemplo, se um enterprise bean criar o componente, o método que cria o bean assíncrono deve ser TX_BEAN_MANAGED.

Ao chamar um bean de entidade a partir de um bean assíncrono, por exemplo, você deve ter um contexto transacional global disponível no encadeamento atual. Como os objetos beans assíncronos iniciam contextos transacionais locais, é possível englobar toda a lógica dos beans de entidade em um bean de sessão que tenha um método marcado como X_REQUIRES ou equivalente. Esse processo estabelece um contexto transacional global a partir do qual você pode acessar um ou mais métodos de beans de entidade.

Se o método de beans assíncronos emitir uma exceção, todas as transações locais serão revertidas. Se o método retornar normalmente, todas as transações locais incompletas serão concluídas de acordo com o critério de ação não resolvida configurado para o bean. Os métodos EJB podem configurar esse critério utilizando seu descritor de implementação. Se o método de bean assíncrono iniciar sua própria transação global e não consolidar essa transação global, a transação é revertida quando o método retornar.

Acesso aos Metadados do Componente do Java EE

Se um bean assíncrono for um componente do Java EE, como por exemplo, um bean de sessão, seus próprios metadados estarão ativos quando um método for chamado. Se um bean assíncrono for um simples objeto Java, os metadados do componente do Java EE do componente de criação estarão disponíveis para o bean. Como seu criador, o bean assíncrono pode consultar o espaço de nomes java:comp. Esta consulta permite que o bean acesse os connection factories e enterprise beans, tal como seria se ele fosse qualquer outro componente do Java EE. As propriedades de ambiente do componente de criação também estão disponíveis para o bean assíncrono.

O espaço de nomes java:comp é idêntico ao disponível para o componente de criação; as mesmas restrições se aplicam. Por exemplo, se o enterprise bean ou o servlet tiver uma referência EJB igual a java:comp/env/ejb/MyEJB, essa referência EJB estará disponível para o bean assíncrono. Além disso, todas as fábricas de conexões utilizam o mesmo escopo de compartilhamento de recursos que o componente de criação.

Gerenciamento de conexões

Um método de bean assíncrono pode usar as conexões que seu componente do Java EE de criação obteve usando as referências de recursos java:comp. (Para obter informações adicionais sobre referências de recursos, consulte o tópico Referências). No entanto, o método do bean deve acessar estas conexões utilizando um padrão obter, usar ou fechar. Não há nenhum armazenamento em cache entre as chamadas de métodos em um bean assíncrono. As connection factories ou as origens de dados em si podem ser armazenadas em cache, mas as conexões devem ser recuperadas a cada chamada do método, utilizadas e, em seguida, fechadas. Embora o método de bean assíncrono possa consultar as connection factories utilizando um nome JNDI (Java Naming and Directory Interface) global, isso não é recomendado pelos seguintes motivos:

  • O nome JNDI está protegido por código permanente no aplicativo (por exemplo, como uma propriedade ou literal de cadeia).
  • As connection factories não são compartilhadas, porque não há como especificar um escopo de compartilhamento.

Para obter exemplos de código que demonstrem as maneiras corretas e incorretas de acessar conexões a partir de métodos de beans assíncronos, consulte o tópico Exemplo: Gerenciamento de Conexões de Beans Assíncronos.

Início adiado de beans assíncronos

Os beans assíncronos suportam o início adiado, permitindo a serialização de informações de contexto do serviço do Java EE. O método WorkWithExecutionContext createWorkWithExecutionContext(Work r) na interface do WorkManager criará uma captura instantânea dos contextos de serviço do Java EE ativado no WorkManager. O objeto resultante WorkWithExecutionContext pode então ser serializado e armazenado em um banco de dados ou arquivo. Isso será útil quando for necessário armazenar contextos do serviço do Java EE, como por exemplo, a identidade de segurança atual ou o Código de Idioma e, posteriormente, aumentá-los e executar algum trabalho dentro deste contexto. O objeto WorkWithExecutionContext pode ser executado utilizando os métodos startWork() e doWork() na interface WorkManager.

Todos os objetos WorkWithExecutionContext devem ser desserializados pelo mesmo aplicativo que os serializou. Todos os EJBs e classes devem estar presentes para que o Java aumente com êxito os objetos contidos neles.

Início Adiado e Segurança

O contexto do serviço de segurança dos beans assíncronos podem requerer que a asserção da identidade do CSIv@ (Common Secure Interoperability Versão 2) seja ativada. A asserção de identidade será necessária quando um objeto WorkWithExecutionContext for desserializado e executado para a designação de credencial de identidade do assunto do Java Authentication and Authorization Service (JAAS). Revise os seguintes tópicos para melhor entender se você precisa ativar a asserção de identidade, ao utilizar um objeto WorkWithExecutionContext:
  • Configurando o tópico Common Secure Interoperability Versão 2 e Security Authentication Service
  • Asserção de Identidade

Há também questões de interoperação com objetos WorkWithExecutionContext de diferentes versões do produto. Consulte o tópico Interoperando com Beans Assíncronos.

Limitações Relacionadas ao JPA

O uso de beans assíncronos em um contexto de persistência estendido pelo JPA não é suportado.

Um contexto de persistência estendido pelo JPA é inconsistente com os recursos de planejamento e multiencadeamento de beans assíncronos e não estará acessível a partir de um encadeamento de bean assíncrono.

Da mesma forma, um bean assíncrono não deve ser criado de forma que ele utilize javax.persistence.EntityManager (ou uma subclasse) como um parâmetro, uma vez que as instâncias EntityManager não foram projetadas para encadeamento seguro.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=casb_asbover
Nome do arquivo: casb_asbover.html