Artigo Java Magazine 49 - EJB 3.0: Aplicando Interceptors

apa_java49_G.gif" border=0>

ns = "urn:schemas-microsoft-com:office:office" />

Interceptação nativa de métodos e princípios

Entre os muitos novos recursos da especificação Enterprise Java Beans 3.0 estão os Interceptors, que chamam a atenção por ser um início do amadurecimento da utilização da Programação Orientada a Aspectos (AOP) dentro de containers EJB. O uso de Interceptors possibilita lidar melhor com tarefas “cross-cutting” como auditoria, logging, segurança e outras, sem a dependência de frameworks de AOP como AspectJ ou JBoss-AOP. Neste artigo veremos os conceitos básicos dos Interceptors e apresentaremos como usar esse recurso em dois exemplos práticos.

Visão e aplicabilidade

À medida que os sistemas orientados a objetos (OO) evoluíram e cresceram em complexidade, tornou-se mais difícil entender o real propósito de suas estruturas. Isto ocorre porque o paradigma OO possui certas limitações; por exemplo, alguns requisitos não se decompõem claramente em comportamentos centrados Os Interceptors seguem a mesma linha da AOP, permitindo a Separação de Interesses1. Segundo esse princípio, a lógica de negócio é estritamente separada da lógica de infra-estrutura, como auditoria, logging, segurança etc. O código se torna mais limpo e mais fácil de ser entendido, pois cada componente pode focar no seu interesse específico.

Primeiro exemplo: conceitos básicos

Para facilitar o entendimento dos conceitos fundamentais, vamos usar um exemplo centrado na classe ContaBean, mostrada na Listagem 1. Esta classe é um Stateless Session Bean e possui métodos para obtenção do número da conta e para creditar, debitar e obter o saldo. O método debitar() lança a exceção SaldoInsuficienteException caso o valor passado como parâmetro seja menor que o valor do saldo existente. Além disso, para que a lógica de negócio contida nos métodos possa ser executada, é necessária antes uma verificação de permissões de acesso. Somente de posse da permissão necessáriaserá possível a execução de cada um dosmétodos. ContaLocal é a interface local doEJB e é mostrada na Listagem 2.

Listagem 1. Stateless Session Bean ContaBean com verificação de permissão de acesso e “código emaranhado”.

package jm.banco.ejb;

//...imports

@Stateless

     public class ContaBean {

private static final String OPERACAO_CONTA = “OPERACAO_CONTA”;

private float saldo;

     public void credita(float valor) {

            ControleAcesso.verificaPermissao(

              new PermissaoBancaria(OPERACAO_CONTA));

           this.saldo = this.saldo + valor;

}

    public void debita(float valor) throws SaldoInsuficienteException {

          ControleAcesso.verificaPermissao(

              new PermissaoBancaria(OPERACAO_CONTA));

          if (this.saldo < valor) throw new SaldoInsuficienteException();

             else this.saldo = this.saldo - valor;

}

         public float getSaldo() {

               ControleAcesso.verificaPermissao(

          new PermissaoBancaria(OPERACAO_CONTA));

              return this.saldo;

       }

}

Listagem 2. Interface local para o EJB ContaBean.

package jm.banco.ejb;

//...imports

@Local

public interface ContaLocal {

public void credita(float valor);

public void debita(float valor) throws SaldoInsuficienteException;

public float getSaldo();

}

Listagem 3. Classe “mock” para controle de acesso.

package jm.banco.seguranca;

    public class ControleAcesso {

       public static void verificaPermissao(PermissaoBancaria permissao) {

          if (permissao.getPermissao().equals(“accountOperation”)) {

              System.out.println(“Permissao ok”);

         }

     }

}

Listagem 4. Classe ”mock” para permissão de acesso. ...