Diretrizes: Projetando EJBs (Enterprise JavaBeans)
Tópicos
Introdução
Essa diretriz focaliza o design de EJBs. Orientação adicional sobre EJBs, tal como
identificá-las e modelá-las, é fornecida por Diretrizes:
EJBs.
Orientação específica sobre o design de tipos específicos de EJBs é fornecida nas diretrizes
a seguir:
As interfaces locais e remotas são descritas em Conceitos:
Visão Geral do J2EE: Enterprise JavaBeans.
As interfaces locais são mais eficientes do que as remotas. Elas deverão ser
fornecidas se houver clientes específicos funcionando sempre como locais para o
EJB.
Orientação mais específica sobre esse tópico é fornecida nas diretrizes para os
tipos específicos de EJBs.
Transmissão de Parâmetros
O desempenho pode ser muito afetado pelo número de chamadas remotas e
quantidade de dados transferidos em cada chamada. Isso pode ser tratado fornecendo-se
chamadas específicas que retornem todos os dados requeridos pelo cliente remoto. Por
exemplo, um bean de sessão agindo como fachada para um conjunto de beans de entidade relacionados
pode copiar dados de vários beans de entidade para os objetos de valores serializáveis e
retornar esses dados em uma única chamada remota. Isso é descrito em detalhes em Padrões Núcleo
de J2EE - Padrão do Objeto de Valor ([ALU01].
Isso deve ser compensado pela preocupação de manter as interfaces as mais gerais possíveis
e evitando o envio de dados desnecessários excessivos.
Demarcar transações significa iniciar, consolidar e abortar transações.
Um designer EJB deve decidir se implementará a demarcação de transação gerenciada por bean
ou a demarcação de transação gerenciada por contêiner. Você deve decidir sobre os locais
dos limites de transação nas seqüências de lógica de negócios executadas por
seu aplicativo. Para obter informações adicionais, consulte Atividade: Design de Casos de Uso, Modelando Transações
e a seção intitulada Gerenciamento de Transações
em Conceitos: Visão Geral do J2EE.
Utilize as transações gerenciadas por contêiner onde possível. Isso manterá seu código
simples e permitirá que os desenvolvedores focalizem a lógica de negócios do aplicativo.
Em geral, transações de granularidade maior resultarão em um melhor desempenho
geral. Suponha que você faça uma seqüência de chamadas de método para um EJB (por exemplo,
getX, getY e setZ). Por padrão, cada método será executado em uma nova transação,
resultando em redução de desempenho. Para chamá-los na mesma transação,
crie outro método, por exemplo, o método processXYZ de uma sessão EJB e defina
os atributos de transação dos métodos chamados como Obrigatórios, para que
utilizem a transação existente (por exemplo, a transação do método de chamada
no bean de sessão).
Os conceitos básicos de segurança do EJB são descritos em Conceitos:
Visão Geral da Plataforma J2EE - Segurança.
Os requisitos de segurança dos EJBs são definidos definindo-se as funções de segurança
e as permissões de métodos. As funções de segurança e as permissões de métodos são
definidas no descritor de implementação do EJB. É responsabilidade do servidor (utilizando
as ferramentas de administração) mapear as funções de segurança para usuários ou grupos de usuários.
Uma função de segurança define um conjunto de tipos de atividades semelhantes que são agrupadas
com um único nome. Uma permissão de método concede a uma determinada função de segurança o
direito de chamar o método. Por exemplo, considere um EJB de entidade Funcionário,
com os métodos setAddress, setSalary etc. Uma função de segurança de gerenciador
pode receber a permissão de método para os métodos setAddress e setSalary, enquanto que
uma função de segurança de funcionário só pode receber a permissão de método para
o método setAddress.
Em algumas situações, é impossível suportar os requisitos de segurança de
um aplicativo utilizando permissões de métodos declarativas no descritor de implementação.
Nesse caso, utilize os métodos getCallerPrincipal e isCallerInRole da
interface javax.ejb.EJBContext.
Desde o J2EE 1.4 (mais exatamente o EJB 2.1), os beans de sessão sem preservação de
estado e os beans orientados a mensagens podem utilizar cronômetros para planejar processos em batch por meio
do Serviço de Cronômetro do EJB.
O Serviço de Cronômetro do EJB que fornece métodos para permitir que os
retornos de chamadas sejam planejados para eventos com base no tempo. O contêiner fornece um serviço
de notificação confiável e transacional para eventos programados. As notificações de cronômetro
podem ser planejadas para ocorrerem em um horário específico, após uma duração específica decorrida
ou em intervalos recorrentes específicos.
O Serviço de Cronômetro é implementado pelo contêiner EJB
e um bean corporativo pode acessar esse serviço por meio da interface EJBContext.
O Serviço de Cronômetro do EJB é um serviço de notificação grosseiro
projetado para ser utilizado na modelagem de processos no nível do aplicativo
e não destinado para modelagem de eventos em tempo real.
Acesso Direto versus Beans de Entidade 
A utilização de beans de entidade para dados persistentes fornece um mecanismo padrão rico em recursos
para o acesso a dados persistentes. A decisão de utilizar a persistência gerenciada por bean
ou gerenciada por contêiner pode ser ocultada dos clientes, fornecendo ao design
alguma flexibilidade. Os EJBs podem obter benefícios com as transações, gerenciamento de recursos,
equilíbrio de carga e outros recursos fornecidos pelo ambiente J2EE.
Entretanto, pode haver situações em que você deseje acessar o banco de dados
diretamente e evitar a utilização de beans de entidade. Por exemplo, se os dados forem sempre acessados
como de leitura por um único cliente, o acesso direto ao banco de dados seria mais
eficiente.
Se você for acessar o banco de dados diretamente (por exemplo, de um bean de sessão sem preservação
de estado), encapsule todo o acesso ao banco de dados em uma classe de Objeto de Acesso a Dados. Isso é
apenas uma classe Java que oculta e encapsula o mecanismo de armazenamento subjacente
e isola as mudanças quando e se a interface à origem de dados for alterada.
Consulte Padrões Núcleo de J2EE - Padrão do Objeto de Acesso a Dados ([ALU01].
Virtualmente, todos os contêineres EJB fornecem suporte para o pool de conexão compartilhando
um conjunto de conexões já criadas entre os clientes. Essas conexões são
designadas aos EJBs, conforme necessário. O EJB se beneficia, obtendo uma conexão sem
a despesa de criá-la e inicializá-la. Quando a conexão é retornada
para o conjunto, ela é reciclada. O tamanho do conjunto deve ter conexões suficientemente prontas
disponíveis para reciclar as já utilizadas.
Para beans de entidade com persistência gerenciada por contêiner, o contêiner gerencia
a conexão com o banco de dados e o acesso ao pool de conexão com o banco de dados.
Para beans de entidade com persistência gerenciada por bean (ou para EJBs de sessão ou orientados
a mensagens que acessam um banco de dados), o desenvolvedor é responsável pela codificação da rotina de
conexão. As seguintes diretrizes se aplicam:
- Isole seu código de acesso ao banco de dados em uma classe DAO.
- Não codifique permanentemente o URL real do banco de dados; em vez disso, utilize um nome
lógico que possa ser recuperado utilizando a consulta JNDI (Java Naming and Directory
Interface). Isso permite a reutilização do EJB em vários aplicativos, possivelmente
com nomes de bancos de dados diferentes.
- Em geral, utilize conjuntos de conexões e mantenha a conexão apenas enquanto
for necessária. Por exemplo, um bean de entidade pode conectar-se, atualizar uma linha em
uma tabela e, em seguida, desconectar-se. Isso permitirá que vários EJBs compartilhem a mesma
conexão. A especificação JDBC inclui suporte para o pool de conexão.
|