Tópicos

IntroduçãoPara o início da página

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:

Interfaces Locais versus Remotas To top of page

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âmetrosPara o início da página

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.

Transações To top of page

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). 

Segurança

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. 

Serviço de Cronômetro

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 To top of page

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].

Conexões com o Banco de Dados To top of page

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.

Rational Unified Process   2003.06.15