Sexta-feira, Março 23, 2007

Pequena Introdução ao EJB 3.0

Enterprise beans podem ser descritos como componentes reutilizáveis que executam rotinas relacionadas à lógica de negócios de um aplicativo, sozinhos ou em conjunto, num ou mais Application Servers. Implementam a tecnologia EJB, que faz parte de um quadro maior chamado Java EE e, na versão 3.0, consiste em duas partes:

  • A especificação JSR-220, que define as regras para a implementação do suporte a enterprise beans pelos fornecedores de servidores Java EE, de forma a tornar viável o "write once, run anywhere"
  • Conjunto de interfaces e suas respectivas implementações. Ambos devem seguir os contratos entre componentes e o servidor do aplicativo, definidos pela JSR-220.
Na JSR-220 existem dois tipos de EJB's: session beans e message-driven beans. Session beans executam tarefas para um cliente; podem implementar um web service. Message-drive beans fornecem suporte para processamento assíncrono de requisições de serviços, além das funcionalidades dos sessions beans.

CMP beans foram substituídos pelos JPA entity beans. A JSR-220, no entanto, é compatível com as especificações anteriores, portanto CMP's podem ser utilizados em containeres EJB 3.0, assim como é possível todas as diversas combinações de interações entre cliente, EJB 2.1 e EJB 3.0.

A excitação em torno do EJB 3.0 é motivada graças à simplificação de sua API, se comparado às especificações anteriores:
  • Interface de objetos e interface home não são mais necessárias
  • Interfaces para componentes (javax.ejb.SessionBean e javax.ejb.MessageDrivenBean) não são mais necessárias
  • Utilização de annotations como metadados
  • Simplificação de API's para acessar o ambiente do bean
  • Coding-by-exception.
Coding-by-exception é a capacidade dos enterprise e entity beans de assumir um valor padrão para cada metadado. Dessa forma, só é preciso codificar annotations quando seu valor padrão não for apropriado.

Os enterprise beans, na especificação EJB 3.0, são POJO's que, no caso dos session beans, implementam métodos definidos numa business interface local ou remota. A business interface é uma POJI que define os métodos expostos pelo session bean.

Esse conjunto de simplificações, mais a adição dos JPA entity beans, visam facilitar e aumentar a produtividade do desenvolvimento de sistemas distribuídos que utilizam componentes EJB no seu middleware.

Vantagens na utilização de EJB's

Sistemas de informação computacionais distribuídos precisam de uma série de serviços de infra-estrutura (system-level services) para serem viáveis. Entre os também chamados middleware services, porque são comumente requisitados e presentes na camanda do meio, estão:
  • Invocação Remota de Métodos (RMI). Serviço responsável por conectar uma camada a outra remota, via rede. A requisição de serviço numa camada (e.g. apresentação) é processadas em outra (e.g. negócio)
  • Balanceamento de Carga. Requisições de clientes por serviços são redirecionadas para servidores com menor carga [de trabalho]
  • Transparent failover. Se um servidor cair ou ficar indisponível na rede, os clientes são redirecionados de forma transparente para outro servidor em operação
  • Integração com o back-end. Suporte para persistência de dados em banco de dados e integração com sistemas legados
  • Gerenciamento de Transações. Proteção à integridade de dados com controle de acesso concorrente e mecanismos para tratamento de excessões (e.g. interrupção brusca em meio a uma transação)
  • Clustering. O estado de um servidor é replicado para que o cliente possa utilizar outro servidor em caso de queda
  • Redeployment dinâmico. Capacidade de atualizar um aplicativo, ou seja, realizar um deployment de um ou mais de seus componente, sem precisar reiniciar o servidor
  • Logging e auditoria. Registro das atividades no servidor de aplicativos, possibilitando a auditoria de eventuais problemas para descobrir a sua causa
  • Gerenciamento do sistema. Monitoramento do sistema para o caso de falhas graves (fatal errors)
  • Suporte para múltiplas requisições. Disponibilidade e gerenciamento de múltiplos threads para possibilitar acesso simultâneo dos clientes aos enterprise beans
  • Processamento assíncrono de requisições (messaging). Maior desacoplamento entre clientes e servidor através de requisições baseadas em mensagens
  • Gerenciamento do ciclo de vida dos enterprise beans. Componentes são criados e destruídos conforme necessário
  • Resource pooling. Criação de pool de recursos, como conexões JDBC, e de enterprise beans para fins de reutilização por diversos clientes
  • Segurança. O acesso aos serviços disponibilizados pelos beans é controlado por metadados específicos
  • Caching. Armazenamento temporário de dados comumente requisitados por clientes de modo a otimizar a performance do aplicativo
  • Outros...
O container EJB provê a infra-estrutura necessária para aplicativos distribuídos, liberando o desenvolvedor dessa árdua tarefa para que se concentre na implementação da lógica de negócios, encapsulada em componentes reutilizáveis.

Quando utilizar EJB 3.0 ?

Se entre os requisitos não-funcionais de um aplicativo estiverem escalabilidade, integridade de dados e numerosos clientes, considere utilizar EJB 3.0.

Geralmente, um aplicativo precisa acomodar número crescente de usuários. Nesses casos, os enterpise beans poderão ser distribuídos em diversos servidores, aumentando o desempenho do sistema.

O container EJB tem mecanismos de gerenciamento de transações para preservar a integridade dos dados durante o acesso simultâneo à objetos compartilhados.

Clientes de aplicativos Java EE podem concentrar-se nas rotinas de apresentação, deixando a implementação da lógica de negócio encapsulada nos EJB's. Cliente pode ser JSP, Servlet, rich client (desktop), applet, outro enterprise bean.

Leitura Recomendada:
Fontes Utilizadas: