AOP - Livro de Receitas

Transcrição

1 AOP - Livro de Receitas Michel de Montalvão Guedes Abstract Este tutorial visa demonstrar como a AOP (Orientação a Aspectos) pode auxiliar-nos a resolver problemas de complexidade médio-elevada de forma bastante simples. Palavras-Chaves SOA, AOP, IOC, O.O, Framework, Padrões de Projeto, JoinPoint, PointCut, Advice. Introdução Imagino que o leitor deste tutorial, como eu, já deva ter testado um ou vários exemplos de Hello World utilizando AOP. Ou então, tenha lido alguns artigos conceituais sobre: como AOP irá melhorar drasticamente o seu futuro!, porém sem demonstrar nenhum caso prático disto. Por isso, minha abordagem será um pouco mais honesta: tentarei mostrar a AOP limitada à como ela pode melhorar os sistemas que você já desenvolve hoje em dia, deixando os comentários futuristas para os Engenheiros de HollyWood, isto é claro se o leitor também apreciar, como eu, um belo filme de ficção científica. Porém, imagino que vários leitores terão uma primeira impressão sobre AOP com este tutorial, por que quase todo material mais abrangente sobre a mesma encontra-se em língua inglesa. Assim, não furtei-me a grata tarefa de acrescentar à parte inicial deste material uma breve e compacta introdução sobre os principais conceitos relacionados à AOP, e também disponibilizar, sempre que possível, referência à documentação disponível na internet sobre assuntos muito extensos para serem abordados apenas neste papel. Para aqueles que já tiveram uma experiência inicial e dominam conceitos relacionados à AOP como: Aspecto, Pointcut, Advice, etc., podem pular o tópico introdutório e passar direto ao próximo: Definindo Pointcuts em AspectWerkz e JBossAOP que demonstra alguns exemplos práticos de como definir estes elementos na semântica específica destes dois Frameworks. A parte central (e mais extensa do tutorial) é um estudo de caso onde demonstro a construção de um framework que chamei, por motivos implícitos, de MicronContainer. Você encontrará reunidos nele vários exemplos práticos da utilização das técnicas da AOP em problemas do mundo real, ou seja, do cotidiano do desenvolvedor quando deparado com a construção da arquitetura de sistemas de médio e grande porte. Cabe aqui uma ressalva: utilizei a linguagem Java, primeiro: por que tenho mais afinidade com ela (e não sou especialista em linguagens artificiais que produzem exemplos artificiais), segundo: por que as principais implementações de mecanismos de AOP foram escritas para serem utilizadas na plataforma Java (cite-se: AspectJ, AspectWerkz, JBossAOP, SpringAOP, Dynaop, entre outros). Uso nos exemplos dois dos mais populares Framewoks AOP para Java: AspectWerkz e JBossAOP, ambos são muito semelhantes em sua métodologia e sintaxe pois: Utilizam diretamente à linguagem Java para construir todos os elementos necessários à programação para a AOP. É da opinião pessoal do autor deste papel que é muito mais fácil utilizar está abordagem, que aprender uma linguagem exclusiva para criar Aspectos (para uma explicação formal do termo veja o próximo tópico Conceitos A voz Java no Brasil Pág. 1

2 Básicos), pois permite ao leitor que tenha conhecimentos básicos sobre a linguagem Java a possibilidade de trabalhar imediatamente com a AOP. Existem pelo menos duas formas de utilizar AOP em uma aplicação Java, uma mais clássica, que exige um estágio de pós-compilação da aplicação e outra mais simples em que este estágio não é necessário - também conhecida como AOP via Proxy. Por questões relativas ao tamanho deste material, preferi concentrar-me em exemplos utilizando à primeira abordagem, deixando a outra para um material posterior caso surja à oportunidade. Conceitos Básicos Para que tenhamos o entendimento total dos exemplos de código utilizados neste tutorial, faz-se necessário a explanação de alguns conceitos relacionados à Orientação a Aspectos (AOP), e uma rápida explicação entre as diferenças pontuais entre a AOP e a Orientação a Objetos (O.O). Na Análise Orientada a Objetos conseguimos modelar de forma clara e coerente (segundo os princípios de coesão e acoplamento) os requisitos funcionais (de negócios) de um problema. Assim é bastante direta a divisão do problema em partes funcionais (também chamada de decomposição funcional), ou seja, em classes e objetos. O problema aparece quando passamos ao Projeto (também chamado Design, OOD) e nos deparamos com toda uma complexidade de requisitos não-funcionais (dito daqui por diante como n-funcionais), como: Log, persistência, atomicidade, etc., a serem cumpridos. Como estes requisitos (n-funcionais) frequentemente estão Acoplados no código fonte aos requisitos do negócio (funcionais) de forma ad-hoc (não previsível) dizemos que eles estão emaranhados no código (chamado de Tangled Code), aumentado ainda mais: A complexidade de uma tarefa que já era por sua natureza, complexa! (LADDAD [1]). O resultado é que perdemos toda a coesão e o acoplamento obtidos na análise e estamos agora com um modelo que é difícil de representar e de manter. A AOP se propõe a resolver esta questão criando a idéia de divisão ortogonal do problema. Seria algo como modelar os requisitos de negócio (Funcionalmente) e também os n-funcionais (Ortogonalmente) de um sistema. Vamos dar um exemplo. Imagine um gráfico com dois eixos x e y, cada um representando Requisito x Funcionalidades, introduzir um requisito n-funcional seria como introduzir um novo eixo z (ortogonal), dando uma visão 3D ao modelo. Para cada funcionalidade temos uma ou um conjunto de classes. Da mesma forma para cada novo Eixo Ortogonal introduzido ao modelo, temos uma outra unidade fundamental, o Aspecto. O Aspecto é à unidade funcional da AOP. Ele é escrito em uma linguagem particular, ou modernamente, na mesma linguagem utilizada para O.O (veja exemplo na Figura 1). Ainda não existe uma metodologia (como na O.O) que permita modelar um sistema orientado a aspectos desde a análise até sua implementação, em seu estágio atual a AOP pode ser considerada como: "Uma evolução das metodologias de desenvolvimento de software" (KICZALES [2]), até por isso vamos propor um padrão para o desenvolvimento dos exemplos (veja mais no tópico: Padrão JoinPointToken) que estabelecido sobre uma relação de 1-1 (um para um), onde um aspecto representa um requisito (ou interesse) ortogonal do sistema. Nesta abordagem o aspecto nada mais é do que uma funcionalidade de nível do sistema, ou seja, A voz Java no Brasil Pág. 2

3 representa um comportamento esperado para o mesmo (Cross-cut Concern), para isto disponibilizando um conjunto de funções, assemelhando-se (o Aspecto) muito mais a programação procedural do que a programação O.O. Fig.1 Exemplo de um Aspecto. Como não é o objetivo deste ser um tratado sobre AOP, vou-me ater de forma prática há como é feita à implementação da decomposição do sistema, em Objetos e Aspectos: Inicialmente decompomos funcionalmente o sistema utilizando O.O, representando as regras de negócio em uma linguagem O.O e identificando e isolando os requisitos n-funcionais compartilhados entre as classes num módulo (pacote) separado: É também uma boa prática utilizar estereótipos da UML (por exemplo, <<Aspect>>, <<Transaction>>, etc.), para demarcar classes que funcionalmente estão ligadas a várias outras. [Grifos Nossos]. Depois implementamos os requisitos n-funcionais compartilhados entre as classes em um Aspecto (minha preferência é utilizar 1-1, mas não há impedimentos para que sejam utilizados vários Aspectos, conforme surja à necessidade), em uma linguagem específica de Aspectos, ou na mesma Linguagem utilizada para OO com anotações em um arquivo XML ou anotações da própria linguagem, indicando que a classe apresenta as funcionalidades (ou melhor, os interesses) de um Aspecto. (Veja a Figura 2) Utilizamos um combinador de código, chamado Weaver, para montar as duas implementações. Algo muito parecido com a herança múltipla de O.O puro. (Veja a Figura 3.). A voz Java no Brasil Pág. 3

4 Fig.2 Classes Antes do Combinador Weaver. 1 Marcando as Classes - Fig.3 Classes Depois do Combinador Weaver. Para tanto, devemos oferecer uma forma de o compilador weaver juntar os dois códigos de forma a fornecer o comportamento desejado, que normalmente obteríamos com a utilização de O.O e do código emaranhado. Vamos analisar como isto é feito, descrevendo as partes envolvidas nesta combinação: Joinpoints São pontos bem definidos onde podem incidir uma característica ortogonal no Objeto. Por exemplo, se um método de uma classe precisa de um requisito n-funcional (como atomicidade da transação), ele é um provável candidato a ter um (ou mais) Joinpoints. Vejamos um exemplo simples: A voz Java no Brasil Pág. 4

5 public class Banco{ public Dinheiro efetuarsaque(conta contacorrente, double valor){ Dinheiro dinheiro = null; //Obtém se o cliente da conta tem limite para saque boolean temlimite = verificarlimite(contacorrente); if(!temlimite){ dinheiro = new DinheiroNaoLiberado( Não Há Saldo ); return dinheiro; //Interrese Ortogonal: Desfazer tudo se depois ocorrer erro. debitarconta(valor); //JoinPoint dinheiro = new DinheiroLiberado(valor); return dinheiro; Listagem 1.1 Mostrando um JoinPoint Na listagem 1.1 vemos um exemplo de Joinpoint. Caso a operação dinheiro = new DinheiroLiberado(valor) cause uma exceção, a alteração feita pelo método debitarconta(valor) deverá ser desfeita se desejamos manter a Integridade da Transação, isto envolveria misturar aos requisitos de negócios lógica de controle para as seguintes operações: 1) capturar a exceção, 2) desfazer todas as modificações na base de dados e 3) relançar a exceção adiante Pointcuts É uma regra que define um Joinpoint. Está regra inclui: Uma Expressão Regular ou Padrão que descreve que elementos do objeto: (métodos, atributos, construtores ou o próprio objeto) capturar como Joinpoints. Assim o Padrão permite que um Joinpoint: Seja tão genérico quanto se deseje (LADDAD [1]). Sua Definição que recebe a expressão e intercepta a execução do Joinpoint de uma maneira específica. Logicamente, a Definição e o Padrão devem concordar segundo o tipo do elemento que é capturado (método, atributo, etc..), Abaixo alguns exemplos de Pointcuts escritos em AspectWerkz e JBossAOP (Detalharemos a sintaxe de ambos no próximo tópico). Em AspectWerkz: - Captura os Métodos efetuarsaque() e debitarconta(): execution( * Banco.efetuarSaque (..) * *. debitarconta (double)) Definição Padrão Listagem 1.2 Exemplo de Pointcut em AspectWerkz Em JBossAOP: A voz Java no Brasil Pág. 5

6 - Captura os Métodos efetuarsaque() e debitarconta(): execution( * Banco->efetuarSaque (..) * *->debitarconta (double)) Definição Padrão Listagem 1.3 Exemplo de Pointcut em JBossAOP Advices - É onde será implementado o requisito n-funcional que espera-se ser anexado a um Joinpoint. Trazendo para O.O, seria o método de nossa classe (demarcada como um Aspecto) que seria executado quando o Joinpoint (lugar no Objeto) definido pelo Pointcut (Regra) fosse interceptado, até mesmo por isso, é comum que um Advice venha anexado a um Pointcut. Vejamos os exemplos abaixo. Em AspectWerkz: Advice Pointcut Tipo! execution(* *. debitarconta (double)) ) public void persistirnabasedados(joinpoint joinpoint){.. Advice Depois de executar o método Em JBossAOP: Listagem 1.4 Exemplo de Advice em AspectWerkz. Advice Pointcut Tipo! execution(* *->debitarconta (double)) ) public Object persistirnabasedados(invocation invocation){.. Advice Depois de executar o método Listagem 1.5 Exemplo de Advice em JBossAOP. Alguns frameworks (como o AspectWerkz) definem uma semântica mais rica para os Advices (herdada em grande parte do AspectJ), com o objetivo de especificar com mais precisão o momento em que o Adivice deverá ser aplicado ao Joinpoint. (Antes do JoinPoint, Depois do JoinPoint, Após uma exceção no Joinpoint, etc..). Veja um exemplo rápido abaixo: A voz Java no Brasil Pág. 6

7 @afterreturning Depois de executar o método se: terminou normalmente (não levantou exceção) e retornou o parâmetro definido em type= Dinheiro pointcut= execution(* Banco.efetuarSaque (..)) ) public void committransaction(staticjoinpoint - Depois de executar o método se: ele levantou a exceção definida em type= Exception pointcut= execution(* Banco.efetuarSaque(..)) ) public void rollbacktransaction(staticjoinpoint joinpoint){.. Listagem 1.6 Semântica mais rica de Tipos de Advices do AspectWerkz. Todos estes exemplos demonstraram uma complexidade inicial: O Joinpoint é definido através da Regra (Pointcut) que está no Advice, e não, formalmente, no Objeto onde ele ocorre. Visto de uma forma diferente: os Joinpoints não existem fisicamente, eles são trechos demarcados mentalmente (através da decomposição dos interresses ortogonais), onde serão Injetados os Advices no momento da compilação dos aspectos pelo compilador Weaver. Posteriormente será proposto um padrão que visa desmistificar boa parte desta e de outras complexidades, controlando de forma clara a demarcação dos Joinpoints pelo Objeto. Definindo Pointcuts em AspectWerkz e JBossAOP No exemplo anterior mostramos, mais não em detalhes, alguns pointcuts. Neste tópico iremos explicar a sintaxe de como eles são construídos. 1 - Expressão Regular ou Padrão É o nome do elemento (atributo, classe, método ou construtor) definido através da descrição de sua assinatura, ou seja: sua visibilidade, pacote, tipo, classe ou outros atributos que o caracterizem WildCards - São curingas que permitem anexar um pequeno desvio ao comportamentos das assinaturas dos elementos dos Pointcuts. Em AspectWerkz: * - Permite aceitar qualquer assinatura para um elemento do pacote. É aplicável a somente um nível do mesmo. A voz Java no Brasil Pág. 7

8 .. - Para declaração de classes, significa que quaisquer elementos depois dos dois pontos são válidos (Neste caso, só pode ser usado como ultimo elemento da declaração do pacote), para parâmetros de métodos, significa que a quantidade de parâmetros passados pode ser variável. + - Usado para selecionar apenas objetos que são subclasses do valor selecionado ou instâncias do mesmo. Em JBossAOP: * - Para declaração de pacotes, significa que quaisquer elementos depois dos dois pontos são válidos. É aplicável a qualquer nível da declaração do elemento... - Usado para parâmetros de métodos e construtores, significa que a quantidade de parâmetros passados pode ser variável. $instanceof{nomepacote_nomeclasse Usado para selecionar apenas objetos que são subclasses do valor selecionado ou que implementam a interface passada. 1.2 Padrões para Métodos Em AspectWerkz: Assinatura <anotação> <modificador> <tipo_retorno> <pacote.classe.nome_método> (<tipos_parametros>) Veja alguns exemplos no quadro da listagem abaixo: - Padrão: int app.pessoa.teste (..) Método teste de app.pessoa que retorne um inteiro, com qualquer numero de parâmetros. - Padrão: * app.pessoa+.*(..) Qualquer método que pertença a uma Subclasse ou seja instância de app.pessoa e retorne qualquer (ou nenhum) valor. - Padrão: * app.*.teste(java.lang.string) Método teste de qualquer classe de app, que receba uma String. - Padrão: * app..teste(..) Método teste de qualquer classe de app (ou app.subpacotes), que receba e retorne qualquer valor. - * app.*.*(..) Qualquer método de qualquer classe do pacote app, que esteja marcado com a do pacote app. Listagem 1.7 Pointcuts para Métodos em AspectWerkz. A voz Java no Brasil Pág. 8

9 Em JBossAOP: Assinatura <modificador> <tipo_retorno> <pacote.classe -> <anotação> <nome_método> (<tipos_parametros>). - Padrão: int app.pessoa->teste(..) Método teste de app.pessoa que retorne um inteiro, com qualquer numero de parâmetros - Padrão: * $instanceof{app.pessoa -> *(..) Qualquer método que pertença a uma Sub-Classe de app.pessoa. - Padrão: * app.*->teste(java.lang.string) Método teste de qualquer classe de app(ou app.subpacotes), que receba uma String e retorne qualquer valor. - Padrão: * *->@app.transaction(..) Qualquer método de qualquer classe, que esteja marcado com a do pacote app. Listagem Pointcuts para Métodos em JBossAOP. 1.3 Padrões para Atributos Em AspectWerkz: Assinatura <anotação> <modificador> <tipo> <pacote.classe.nome_atributo> - Padrão: int app.*.id Atributo id de qualquer classe do pacote app, que seja do tipo inteiro. - Padrão: java.util.* app..* Qualquer atributo de qualquer classe que pertença ao pacote app e que seja um tipo de java.util (Collection, por exemplo). - * *.Pessoa.* Qualquer atributo de Pessoa que esteja marcado com a do pacote app. Listagem Pointcuts para Atributos em AspectWerkz. Em JBossAOP: Assinatura <modificador> <tipo_retorno> <pacote.classe -> <anotação> <nome_atributo> A voz Java no Brasil Pág. 9

10 - Padrão: int app.*.pessoa->id Atributo id do Objeto Pessoa de qualquer subpacote de app que seja do tipo inteiro. - Padrão: java.util.* app*->* Qualquer atributo de qualquer classe que pertença ao pacote app e que seja um tipo de java.util (Collection, por exemplo). - Padrão: * *.Pessoa->@app.id Qualquer atributo de Pessoa que esteja marcado com a do pacote app. Listagem Pointcuts para Atributos em JBossAOP. 1.4 Padrões para Construtores (capturam o objeto no momento de sua criação) Em AspectWerkz: Assinatura <anotação> <modificador> <pacote.nome_classe>.<new> (<tipos_parametros>). - Padrão: public app.*.pessoa.new(int) Construtor de Pessoa de qualquer subpacote de app que seja público e tenha um parâmetro inteiro. - Padrão: * app.*.new(..) Construtor de qualquer classe do pacote app com qualquer quantidade de parâmetros. - Padrão: public *..Pessoa.new() Construtor de Pessoa que seja público e não tenha argumentos. Listagem Pointcuts para Construtores em AspectWerkz. Em JBossAOP: Assinatura <modificador> <pacote.classe -> <anotação> new> (<tipos_parametros>). A voz Java no Brasil Pág. 10

11 - Padrão: public app.*.pessoa->new(int) Construtor de Pessoa de qualquer subpacote de app (em qualquer nível) que seja publico e tenha um parâmetro inteiro. - Padrão: * app.*->new(..) Construtor de qualquer classe do pacote app (ou app.subpacotes) com qualquer quantidade de parâmetros. - Padrão: public *Pessoa->new() Construtor de Pessoa que seja público e não tenha argumentos. Listagem Pointcuts para Construtores em JBossAOP. 1.5 Padrões para Classes - Em AspectWerkz: Assinatura <anotação> <modificador> <pacote.nome_classe> - Padrão: * * Qualquer classe do sistema. - Padrão: public app..pessoa Classe Pessoa do pacote app (ou app.subpacotes) que seja pública. - * * Qualquer Classe marcada com a Listagem Pointcuts para Classes em AspectWerkz. Em JBossAOP: Assinatura <pacote.classe> ou <anotação> - Padrão: * Qualquer classe do sistema. - Padrão: app.*.pessoa Classe Pessoa do pacote app (ou app.subpacotes). - Qualquer Classe marcada com a Listagem Pointcuts para Classes em JBossAOP. A voz Java no Brasil Pág. 11

12 2 Operadores Permitem unir um ou mais padrões de Pointcuts, criando uma nova regra composta entre os mesmo. 2.1 Tipos Em AspectWerkz:! - Nega um elemento de um Pointcut, realizando a característica contraria a que foi declarada. ou OR Une dois ou mais Pointcuts, permitindo que a regra seja aplicada se qualquer uma das alternativas for verdadeira. Geralmente também é usado para criar Pointcuts Mixados, ou seja, unindo dois Pointcuts de tipos diferentes (Por exemplo, unindo um Pointcut de método e um de atributo). && ou AND - Une dois ou mais Pointcuts, permitindo que a regra seja aplicada somente se todas as alternativas forem verdadeiras. Em JBossAOP:! - Nega um elemento de um Pointcut, realizando a característica contraria a que foi declarada. OR Une dois ou mais Pointcuts, permitindo que a regra seja aplicada se qualquer uma das alternativas for verdadeira. Geralmente também é usado para criar Pointcuts Mixados, ou seja unindo dois Pointcuts de tipos diferentes (Por exemplo unindo um Pointcut de método e um de atributo). AND - Une dois ou mais Pointcuts, permitindo que a regra seja aplicada somente se todas as alternativas forem verdadeiras. 3 Definição do Pointcut Intercepta a execução de um Joinpoint, segundo a regra definida no padrão passado como argumento. (Descrito anteriormente). 3.1 Tipos Abaixo estão os tipos mais utilizados de definições para o AspectWerkz e o JBossAOP (a lista completa pode ser encontrada na documentação dos Frameworks nas referências [10] e [11]). Em AspectWerkz: execution(padrão de método ou construtor) - Intercepta a execução de um Joinpoint definido para um método ou um construtor. - Captura um Método execution(* app.pessoa+.*(..)) Listagem 1.15 Execution() em AspectWerkz. set(padrão de atributos) - Intercepta a execução de um Joinpoint definido para um atributo quando este é modificado. A voz Java no Brasil Pág. 12

13 get(padrão de atributos) - Intercepta a execução de um Joinpoint definido para um atributo quando este é lido. - Captura um Atributo quando é modificado ou lido. set(int app.*.pessoa.id) && get(int app.*.pessoa.id) Listagem 1.16 Pointcut get() e set() e o operador lógico AND. call(padrão de método ou construtor) - Intercepta a chamada de um Joinpoint definido para um método ou um construtor. within(tipo de parâmetro) - Usado para delimitar o scopo de quais tipos podem ser utilizados em Pointcuts do tipo call() ou execution(). Também pode ser utilizado para delimitar as classes que entram em uma operação de mixin. Diferença sutil entre execution() e call() O leitor mais atendo pode ter notado que estes dois tipos de pointcuts capturam métodos. É bem mais fácil notar a diferença entre ambos se pensarmos em pointcuts para construtores. Vejamos um exemplo utilizando a classe Pessoa, definida abaixo: package app; public class Pessoa{ public Pessoa(){ this(1); public Pessoa(int i){ public static void main(string args[]){ new Pessoa(); Listagem 1.17 Definição da classe Pessoa. Se quiséssemos capturar o construtor de Pessoa que recebe um int, no método main() não poderíamos utilizar o pointcut: call(public app.pessoa.new(int)) Listagem 1.18 Pointcut call() para o Construtor de Pessoa Isto por que para este exemplo o comando new() do construtor public Pessoa(int i) não é utilizado diretamente no método main(), ao contrário, é chamado indiretamente através A voz Java no Brasil Pág. 13

14 do construtor sem argumentos public Pessoa(), o que encaixa-se em um pointcut do tipo execution(). O pointcut do exemplo abaixo funciona e consegue capturar a chamada ao construtor com argumentos, pela criação do objeto Pessoa no método main(): execution(public app.pessoa.new(int)) Em JBossAOP: Listagem 1.19 Pointcut execution() para o Construtor de Pessoa execution(regra de método ou construtor) - Intercepta a execução de um Joinpoint definido para um método ou um construtor. - Captura um Construtor (não publico) execution(!public *.Pessoa->new()) Listagem 1.20 Execution() em JBossAOP e o operador lógico!(negação). set(padrão de atributos) - Intercepta a execução de um Joinpoint definido para um atributo quando este é modificado. get(padrão de atributos) - Intercepta a execução de um Joinpoint definido para um atributo quando este é lido. field(padrão de atributos) - Intercepta a execução de um Joinpoint definido para um atributo quando este é modificado ou lido. - Captura um Atributo quando é modificado ou lido. field(int app.*.pessoa.id) Listagem 1.21 Exemplo de Pointcut get() e set() usando somente um field(). call(padrão de método ou construtor) - Intercepta a chamada de um Joinpoint definido para um método ou um construtor. within(tipo do parâmetro) - Usado para delimitar o scopo de quais tipos podem ser utilizados como parâmetros em Pointcuts do tipo call() ou execution() - Captura a chamada a um Método, limitando o tipo dos argumentos call(* $instanceof{app.pessoa -> *(..)) AND within(java.util.*) Listagem 1.22 Call() limitado por um Within() em JBossAOP. A voz Java no Brasil Pág. 14

15 Padrão JoinPointToken Pode parecer muita pretensão querer propor um padrão, porém, isto mais devido à importância e evidência que eles tomaram em O.O (alguns afirmam ser eles a salvação do mundo), do que o modelo de sua proposição em si. Em gênese, padrões são uma maneira formal de se catalogar um comportamento já: repetida e comprovadamente utilizado de forma eficaz, porém não-formal. Seguindo este modelo vamos analisar o padrão proposto abaixo. 1 - Intenção Controlar o fluxo e a granularidade da demarcação dos Joinpoints no Objeto 2 - Problema É uma questão árdua controlar a granularidade dos Advices de um aspecto. Os Pointcuts, que são a regra para demarcar-se os Joinpoints não podem ser genéricos e nem específicos demais, por exemplo, um Pointcut que chama um método não pode ser escrito destas maneiras. 1) Qualquer Objeto, Assinatura e variável de retorno AspectWerkz : * *.. nome_método(..) JBossAOP : * * -> nome_método(..). 2) Método específico de um objeto. AspectWerkz: public nome_classe. nome_método(nome_parameto) JBossAOP: public nome_classe-> nome_método(nome_parameto) No primeiro caso, a granularidade é muito fina no Pointcut, pois não permite um controle mais apurado de quais métodos são desejados para um Advice, já no segundo caso é muito grossa, pois temos um controle alto (porém não portável) dos elementos do advice. Se desejarmos obter uma funcionalidade disponibilizada como um serviço (nos moldes da SOA), deve-se planejar muito bem o tipo de granularidade utilizada em um Pointcut. A solução atual utiliza arquivos de configuração para guardar o elemento que irá receber o Joinpoint, podendo assim variá-lo de forma mais flexível, porém, traz uma série de dificuldades pois tira a visibilidade do desenvolvedor de onde está acontecendo à chamada ao aspecto (mais especificamente ao Interesse Ortogonal), tornando difícil diagnosticar erros na sintaxe do Pointcut; Por exemplo, se for alterado apenas um caractere do nome do método, o Advice não funcionará da forma esperada. A chave para resolver estes problemas de forma flexível e clara é poder marcar (com um Token) os elementos (atributos, métodos, objetos, etc.) do objeto de forma que seja fácil a visualização do interesse que esta sendo aplicado ao elemento do objeto. 3 - Forças Deve ser fácil marcar um elemento como um Joinpoint. As regras do Pointcut devem ser desacopladas do objeto, porém não apresentarem uma granularidade muito fina (problemática). O Objeto e o Aspecto devem poder variar independentemente. A voz Java no Brasil Pág. 15

16 4 - Solução 4.1 Mecanismo A solução encontrada utiliza anotações como Tokens para marcar os Joinpoints nos objetos. Anotações são um mecanismo do Java 5, utilizadas para se demarcar objetos (Atributos, classes, métodos, etc..). 4.2 Tipos Existem 5 tipos diferentes de Tokens, sendo estes: I. TokenField: Token usado para marcar Joinpoints para atributos de um objeto. II. TokenMethod: Token usado para marcar Joinpoints para métodos de um objeto. III. TokenConstructor: Token usado para marcar Joinpoints para construtores, que são acessados quando um objeto é instanciado, por exemplo, com new() em Java. IV. TokenClass: Token usado para marcar Joinpoints para um objeto. Geralmente são usados em casos de Mixin (mistura) entre duas classes, através da introdução dinâmica (Introduce) de uma interface. V. TokenMixed: Token que marca diferentes tipos de Joinpoints, como por exemplo, métodos normais e construtores. 4.3 Dependências Conceitual - Para que um Pointcut possa capturar um Token, ambos precisam combinar quanto ao tipo de elemento do objeto (atributo, método, etc..) a que serão aplicáveis, ou seja, eles devem coincidir quanto ao tipo de Joinpoint (de método, de atributo, etc..) que será utilizado. Física - Da mesma forma: à assinatura do Pointcut (que define a quem o Advice atende) deve fazer referência ao Token (em nosso caso à anotação Java) e não diretamente ao elemento do objeto demarcado, assim, garantimos a indireção entre o Joinpoint e o Pointcut: O objeto não conhece o seu Aspecto, e este também não conhece o seu objeto, ambos estão relacionados (demarcados) apenas pelo token que o objeto externaliza. 5 Padrões Relacionados Builder Memento Interceptor Filter A voz Java no Brasil Pág. 16

17 O Framework MícronContainer Neste tópico, será apresentado um exemplo prático da utilização da AOP e do padrão JoinPointToken (citado no tópico anterior), para a solução de problemas de média complexidade. Construiremos um Framework SOA (Orientado a Serviço) mínimo, porém que nos proveja transparência na solução de alguns requisitos de sistema bem comuns, a saber: Inversão de Controle com um cache dinâmico, controle transparente da Transação e uma Fábrica Genérica para o padrão Dao (j2ee), que nós abstraí-a da complexidade de um mecanismo de persistência específico. Parece uma tarefa desafiadora a principio e o seria mesmo, quando comparada à complexidade dos frameworks que foram projetadas para solucionar estes problemas. Até este ponto a escolha do nome para este pequeno (em hipótese), porém funcional Framework de apoio seria até fantasioso: MícronContainer. Mas o nome, justamente, pretende demonstrar o quanto a AOP, verdadeiramente, pode nos ajudar a domar as redias do problema e desmistificar o monstro escondido por detrás das nuances da orientação a objetos e dos padrões de projeto. A primeira solução é um exemplo de injeção de dependência nos moldes do EJB3. A segunda e terceira são simplificações de padrões de projetos. Para os exemplos 2 e 3 apenas mostro as interfaces de um mecanismo de persistência, suponho que esteja sendo utilizado um mapeamento objeto/relacional (como hibernate), para controle da transação e persistência. Faço isto para que a solução seja genérica e possa ser portada a qualquer tipo de framework ou tecnologia (dou referência de um exemplo prático do mesmo), sem afetar de maneira nenhuma o objeto que requer o serviço. 1 IOC com Cache descomplicado, o pacote: org.javafree.microncontainer.ioc Quando a OO surgiu uma de suas principais promessas era o reaproveitamento de código, neste cenário, a partir da utilização de mecanismos como um encapsulamento rígido, herança e polimorfismo, uma classe seria distribuída como um componente de software portável. Modernamente ouve houve uma expansão deste conceito (na verdade uma adequação ao SOA), onde um componente abriga um conjunto de classes, sendo projetado para disponibilizar um serviço que, peculiarmente, pode ser consumido sem que haja a necessidade de nenhuma alteração por qualquer aplicação fora do contexto de sua criação". (FOWLER[2]) Por outro lado, vimos que na maioria dos sistemas os requisitos são naturalmente ortogonais, ou seja, apresentam várias dimensões: geralmente uma dimensão para cada requisito básico e uma para cada requisito de nível do sistema (LADDAD [1]), portanto quando tentamos planificar esta ortogonalidade em apenas uma dimensão (Funcional) aparecem efeitos contrários como o Tangled Code, amontoando uma porção de código burocrático em um ponto esparso do sistema onde só deveria haver a implementação de uma função necessária ao requisito básico. Como descrito por LADDAD [1], o Tangled Code frustra a premissa da reutilização de código por que causa os seguintes efeitos indesejados: 1 Difícil de rastrear A dependência de uma classe a vários outras, causa um efeito cascata que torna difícil a legibilidade do código. 2 Difícil de evoluir - Muitas vezes a hierarquia de dependências é cíclica pois as classes estão fortemente acopladas umas nas outras, causando a impossibilidade de evolução de todo o sistema pela não evolução de uma de suas partes, fazendo com este venha em certos casos até a estagnar,. A voz Java no Brasil Pág. 17

18 Vejamos um exemplo de dependência cíclica: Se para executar uma função, uma classe A possui dependência explicita (->) de B (ou seja, A->B), e desejamos executar está função numa classe C, significa que a mesma será explicitamente: C->A e C->B, se multiplicarmos por n, significa que C->n, ou seja, a classe C está tão amarrada às classes n, que não pode ser alterada sob a penalidade de não ser compatível com a interface das outras n, em contrapartida nenhuma classe n poderá evoluir sem que C também seja alterado, sob a penalidade de uma parte do programa não funcionar. Veja que utilizamos para este exemplo apenas uma classe, pensando num sistema com milhares destas é fácil entender por que a implementação do sistema afasta-se tão abruptamente da sua modelagem inicial: Por certo, que em certas situações é difícil até mesmo haver a reutilização de parte de um programa dentro dele mesmo. [Grifos Nossos]. A IOC inversão de controle veio tentar solucionar parte deste problema do acúmulo de dependências entre os módulos de um programa. Em linhas gerais, ao utilizar um framework de IOC para a inicialização de um atributo, o controle do fluxo principal do programa e repassado ao framework que dinamicamente injeta as dependências no mesmo, de acordo com a configuração previa de um alvo (target), até por isso autores como Fowler[2], preferem chamar este recurso de Injeção de Dependência (Dependency Injection, no original). Para mais detalhes sobre inversão de controle leia o artigo do referido autor. Dito de outra forma, injeção de dependência significa trocar as várias dependências explicitas pela dependência configurável ao Framework IOC. Em nosso miniframework vamos trocar está dependência ao framework IOC pelo acoplamento a um elemento de marcação de código (o token), delegando a injeção da dependência a um Aspecto em tempo de execução. Para isto utilizaremos um TokenField (veja o tópico anterior sobre o padrão JoinPointToken) chamado para anotar os atributos que serão instanciados por IOC. Como descrito anteriormente, criaremos uma anotação Java para isto. Nosso Token ficaria então assim: package org.javafree.microncontainer.ioc; import java.lang.annotation.elementtype; import java.lang.annotation.retention; import java.lang.annotation.retentionpolicy; Inject { Listagem 1.23 Definição do Token Inject. O ponto principal a ser citado é a anotação pois ela define a que tipo de elemento a será aplicada. Como estamos definindo um TokenField (marcador de atributos), devemos definir seu valor com a enumeração {ElementType.FIELD (o colchete significa que poderíamos anotar mais de um tipo de A voz Java no Brasil Pág. 18

19 elemento caso fosse necessário). Para mais detalhes sobre o recurso de anotações em Java, veja ARNOLD et al. [5]. Também desejamos que os objetos que forem injetados, fiquem por um tempo armazenados em um cache, evitando suas constantes criações, pois por padrão: Estes objetos irão implementar um serviço e serão repetidamente criados e invocados pelos consumidores do mesmo. Logo, se não utilizarmos algum mecanismo que nos permita guardar a instância do objeto que é consumido, obteremos que para cada 1000 requisições de um serviço serão criadas 1000 instancias do referido objeto. Segundo BOCH[5]: Como Java torna transparente o mecanismo de criação e desalocação de objetos na memória através da Máquina Virtual, este processo (a alocação de objetos na memória) é relativamente caro para a mesma (VM). Seguindo os exemplos do referido autor, criamos a implementação de uma Fábrica seguindo o padrão de projeto Factory e Singleton do GoF (veja mais sobre padrões de projeto GoF nas referências [4] e [14]), como mostra o exemplo da listagem abaixo. package org.javafree.microncontainer.ioc; import java.util.map; import java.util.weakhashmap; public class CachedFactory { //Instancia do Factory private static CachedFactory instance; //Objeto Map(Genérico) usado como Cache private static final Map<Class, Object> cache; static { //Cria o Cache Anexando-a a classe cache = new WeakHashMap<Class, Object>(); //Implementada como Singleton(Padrão GoF) private CachedFactory() { //Cria uma Instância Única public static final CachedFactory getinstance() { if (instance == null) { instance = new CachedFactory(); return instance; A voz Java no Brasil Pág. 19

20 //Método que busca uma Classe pelo Nome private Class find(string name) throws Throwable { //Busca a Classe Class c = Class.forName(name); //Não pode ser uma Interface if (c.isinterface()) { throw new Exception( "MicroContainer não Suporta Interface Injection"); return c; //Método que cria a instância de uma classe public Object create(string classe) throws Throwable { //A classe é a chave de busca no Map Class key = find(classe); //Busca se a classe já foi criada Object retorno = cache.get(key); //Testa se o objeto não foi criado if (retorno == null) { //Log da Criação System.out.println("Criou o Objeto " + key.getname()); //Cria o objeto retorno = key.newinstance(); //Adiciona ao cache cache.put(key, retorno); return retorno; Os pontos mais importantes são: Listagem 1.24 Definição da Fabrica dos Objetos. 1 O cache é guardado num Map, que é instanciado como um WeakHashMap (que libera o objeto se este não for usado continuamente depois de um tempo). O atributo cache é static, logo, pertence à classe e não a uma instância do objeto, pois é criado apenas uma vez na inicialização da classe pela JVM (no bloco static{). 2 O método find(string) busca a classe que é passada pela sua assinatura (como uma String). Ela não pode ser uma interface (testado com c.isinterface()), pois implementaremos a injeção de dependência através de Setter Injection e não sobre Interface Injection. Para mais detalhes ver Fowler[3]. 3 O método create() busca se o objeto já está armazenado no cache usando como chave a sua classe (key). Se estiver retorna o objeto, senão, cria o objeto pela sua classe usando reflection (retorno = key.newinstance()) e o armazena no cache (cache.put(key, retorno)). Mais detalhes sobre reflection na referência [12]. Note que até aqui só usamos O.O. Agora vamos ver os detalhes específicos da implementação da AOP, e como nosso aspecto irá capturar o atributo referenciado A voz Java no Brasil Pág. 20

21 pelo Antes porém, vamos pensar num pequeno algoritmo que solucionaria nosso problema, assim teríamos que: I. Capturar em tempo de execução a utilização do atributo. (geralmente fazendo nosso atributo descender de algum tipo específico). II. III. Desviar o fluxo do programa para uma classe que nos retorne o objeto instanciado. Retornar o objeto (como Object em Java) e preencher o atributo, fazendo o cast e a verificação de erro para a conversão. Um Pointcut nos permite capturar um Joinpoint para um atributo (usando get()), resolvendo assim o passo I de nosso algoritmo Para nosso caso, como queremos capturar qualquer atributo que esteja marcado com a então teríamos como Pointcut: Em AspectWerkz: get(@org.javafree.microncontainer.ioc.inject * *). Em JBossAOP: get(* *->@org.javafree.microncontainer.ioc.inject). O passo II é imediato. Ao anexar-mos o Pointcut a um Advice o combinador Weaver marca o ponto em nosso objeto em que o fluxo do programa será redirecionado para o nosso Aspecto. (O momento da redireção depende da semântica do advice de cada framework). Já para o passo III, temos a garantia de que o objeto será do tipo retornado, pois passaremos via reflection à assinatura do atributo (com a sintaxe pacote.nome_classe) anexado à anotação. Veja os exemplos abaixo, para cada framework: package org.javafree.microncontainer.ioc; import org.codehaus.aspectwerkz.annotation.around; import org.codehaus.aspectwerkz.annotation.aspect; import org.codehaus.aspectwerkz.annotation.expression; import org.codehaus.aspectwerkz.definition.pointcut; import org.codehaus.aspectwerkz.joinpoint.fieldsignature; import public class InjectionAspect * *)") public Object injectionadvice(staticjoinpoint joinpoint) throws Throwable { // Retorna o atributo instanciado return CachedFactory.getInstance().create( ((FieldSignature) joinpoint.getsignature()).getfield().gettype().getname()); Listagem 1.25 Aspecto que implementa IOC em AspectWerkz. A voz Java no Brasil Pág. 21

22 package org.javafree.microncontainer.ioc; import org.jboss.aop.aspect; import org.jboss.aop.bind; import public class InjectionAspect = "get(* public Object injectionadvice(fieldreadinvocation invocation) throws Throwable { //Retorna o atributo instanciado return CachedFactory.getInstance().create( invocation.getfield().gettype().getname()); Listagem 1.26 Aspecto que implementa IOC em JBossAOP. Vamos entender rapidamente os detalhes comuns a ambos os Frameworks: Os dois definem uma anotação para referenciar métodos que retornam valores como advices (@Around em AspectWerkz em JBossAOP). Os nomes dos advices podem ter qualquer sintaxe permitida para nomes de métodos em Java. O tipo do tributo de retorno é obrigatoriamente Object. Trazem o elemento invocado no Joinpoint (recebem-no como parâmetro do advice). Agora os detalhes de cada Framework: AspectWerkz define dois tipos de Joinpoints que o Advice pode receber: JoinPoint e StaticJoinPoint (ou opcionalmente não utilizar nenhum). Use JoinPoint quando necessitar acessar os valores contidos no atributo que foi passado e StaticJoinPoint quando necessitar somente as assinaturas dos mesmos (pois este tem melhor performance). JBossAOP define 4 quatro tipos de Joinpoints como parâmetro de um advice (chamando-o de Invocation) FieldReadInvocation (leitura de atributos), FieldWriteInvocation (escrita de atributos), MethodInvocation (invocação de métodos), ConstructorInvocation (Idem para Construtores) e Invocation o mais genérico, que pode ser qualquer um dos anteriores. Note que os dois Frameworks tornam acessíveis informações sobre o JoinPoint (para mais detalhes veja a documentação de ambos) nos possibilitando a invocação do atributo que está anexado à (getfield()), de seu tipo (gettype(), via reflection) e do seu nome (getname(), também via reflection). Assim, e só chamar nossa Factory passando o nome da classe (método create()). Note que, passar atributos de tipos primitivos e classes que não tem um construtor default sem argumentos ocasionará um erro de tempo de execução. A voz Java no Brasil Pág. 22

23 2 Controle Transparente da Transação, o pacote: org.javafree.microncontainer.atomic Uma preocupação natural de programas que utilizam algum mecanismo de persistência é o controle da transação (ACID). O termo transação pode ser entendido como o mecanismo que nos dê garantia de que uma operação persistente tenha quatro propriedades fundamentais: Atomicidade (operações commit e rollback), Consistência (nos dados persistidos), Isolamento (não influenciada por resultados externos) e durabilidade. Vejamos um exemplo de uma classe Util, que nos provê um mecanismos de persistência como descrito acima: package org.javafree.microncontainer.util; public class PersistenciaUtil { //Aqui se implementaria o inicio da transação public static void begintransaction(){ System.out.println("Iniciando a Transacao:"); //Grava a transação no mecanismo de persistência public static void committransaction(){ System.out.println("Transacao Efetuada com Sucesso!"); //Desfaz a transação no mecanismo de persistência public static void rollbacktransaction(){ System.out.println("Desfazendo Todas as Transacoes!"); Listagem 1.27 Classe Utilitária que controla a transação. Veja que meu exemplo não faz nada, pois para este caso apenas quero demonstrar que o método está sendo chamado. Você poderia colocar em cada método a implementação correspondente a de um mecanismos de persistência especifico como o Hibernate: O hibernate é um framework ORM (objeto/relacional) que nos provê mecanismos para controle de transação a partir das Interfaces Session e Transaction. (veja referência [14]). No artigo citado, encontra-se uma implementação de nossa classe Util (com o nome HibernateHelper) caso você deseje utilizar um exemplo concreto (note que v.c terá que configurar o hibernate e a base de dados). Neste exemplo, trabalho com idéia de que a transação é feita num método de um objeto de negócios específico que atua com controlador da mesma. Por isso, o token será definido como sendo do tipo MethodToken. Vamos então criar uma anotação com a qual marcaremos os métodos de nosso objeto controlador, que efetuem operações transacionais. Veja a anotação na listagem abaixo: A voz Java no Brasil Pág. 23

24 package org.javafree.microncontainer.atomic; import java.lang.annotation.elementtype; import java.lang.annotation.retention; import java.lang.annotation.retentionpolicy; Transaction { Listagem 1.28 Definição da anotação Transaction. Novamente, o principal ponto a se notar é a anotação que define a quais elementos do objeto controlador a será aplicável. Como em nosso caso desejamos marcar métodos, definimo-la com a enumeração {ElementType.METHOD. Até aqui, a forma como era construído o Aspecto era muito semelhantes em ambos os frameworks. Neste exemplo porém, apesar de a definição do Pointcut variar pouco (para métodos usamos execution()), a semântica para definição do advice pode ser definida de forma mais elaborada quando utilizado o AspectWerkz. Irei primeiro explicar o exemplo utilizando este e depois como simular o mesmo comportamento em JBossAOP. Faremos então um breve comparativo entre a utilização de cada sintaxe. Vamos antes, pensar em um algoritmo mínimo que nosso objeto controlador deverá implementar para solucionar o problema: I. Iniciar a transação, ou melhor o contexto transacional, ao iniciar o método transacional no objeto controler. II. Controlar o lançamento de exceções por parte dos objetos de negócio, e desfazer todas as operações realizadas durante a transação caso ocorra algum erro. Isto implicaria geramente em vários blocos aninhados para tratamento de erros (ou um bloco global compartilhado). III. Executar o commit atualizando os dados no mecanismo de persistência caso o método termine normalmente. Como devemos garantir a durabilidade da transação, devemos programar o commit como a última operação executada no método transacional. (lembre-se que utilizar blocos finally{ não é recomendável neste caso). Definido nosso algoritmo, vamos aprender a utilizar a rica semântica do AspectWerkz para solucionar o problema acima demonstrado: Para o primeiro passo, utilizaremos à anexado ao advice begintansactionadivice(), onde é iniciado o contexto transacional de nosso Joinpoint. Esta anotação executa um Advice antes que um Joinpoint aconteça A voz Java no Brasil Pág. 24

25 Já para o segundo passo, utilizaremos à anexada ao advice rollbacktransactionadivice() responsável por: desfazer todos as operações com a camada de persistência caso ocorra qualquer exceção (no caso java.lang.exception). Está anotação captura as várias exceções definidas em Type, que venham a ocorrer em um Joinpoint. Finalizando nosso algoritmo, utilizaremos à para definir o advice committransactionadivice(), que grava todas as operações realizadas com o mecanismo de persistência. Está anotação executará o advice caso o Joinpoint execute normalmente, ou seja, sem ocorrer nenhum erro e retornando um valor. (Poderíamos também definir o tipo do valor retornado pelo Joinpoint com o parâmetro Type da anotação). Vejamos o exemplo completo abaixo: package org.javafree.microncontainer.atomic; import org.codehaus.aspectwerkz.annotation.afterreturning; import org.codehaus.aspectwerkz.annotation.afterthrowing; import org.codehaus.aspectwerkz.annotation.aspect; import org.codehaus.aspectwerkz.annotation.before; import org.codehaus.aspectwerkz.annotation.expression; import org.codehaus.aspectwerkz.definition.pointcut; import public class TrasanctionAspect * *.*(..))") Pointcut public void begintansactionadivice() throws Throwable { // Inicializa a Transação type = "java.lang.exception", pointcut = "pointcut") public void rollbacktransactionadivice() throws Throwable { // Aconteceu um erro. Desfaz Transação public void committransactionadivice() throws Throwable { // Tudo Ok. Comita a transação PersistenciaUtil.commitTransaction(); A voz Java no Brasil Pág. 25

26 Listagem 1.29 Controle da Transação em AspectWerkz. Note que o AspectWerkz também define a que pode ser usada como um alías, evitando a redefinição de um mesmo Pointcut em diversos advices. Neste exemplo, simplesmente utilizamos para cada advice os serviços de nossa classe utilitária PersistenciaUtil que são correspondentes às operações transacionais definidas para o nosso aspecto. Usando o JBossAOP: A única sintaxe definida para anotar advices em JBossAOP Assim para obtermos o mesmo comportamento definido no outro framework devemos: chamar, controlar e finalizar a execução do Joinpoint dentro do nosso Advice. Isto é obtido usando o método invokenext() de Invocation. Veja o exemplo abaixo: package org.javafree.microncontainer.atomic; import org.jboss.aop.aspect; import org.jboss.aop.bind; import org.jboss.aop.joinpoint.methodinvocation; import public class TransactionAspect = "execution(* public Object transactionadvice(methodinvocation invocation) throws Throwable { Object retorno; try { //Antes de chamar o método transacional PersistenciaUtil.beginTransaction(); //Chama o método transacional retorno = invocation.invokenext(); //Depois de executar o método transacional PersistenciaUtil.commitTransaction(); return retorno; catch (Exception e) { //Aconteceu um erro PersistenciaUtil.rollbackTransaction(); throw e; Listagem 1.30 Controle da Transação em JBossAOP. Assim ao executar nosso Joinpoint o fluxo do programa é automaticamente desviado para o Advice transactionadvice() (semelhante à do AspectWerkz). Iniciamos com a abertura do contexto transacional e então chamamos invocation.invokenext(); que nos redireciona ao Joinpoint. Se a execução do Joinpoint terminar normalmente, o fluxo é novamente desviado para o Advice que controla a transação, quando então executamos a operação de commit com o mecanismo de persistência. Note que também temos que controlar o lançamento de qualquer A voz Java no Brasil Pág. 26