Olá Pessoal,

Hoje nosso post será apenas uma curiosidade.
Segundo a spec da VM, a estrutura de um arquivo .class deve ser:

 ClassFile { u4 magic; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info constant_pool[constant_pool_count-1]; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; } 

Os 4 primeiros bytes desse arquivo, chamado de magic, idenfica que um arquivo é um class (“The magic item supplies the magic number identifying the class file format;”).

Ou seja, qualquer arquivo .class terá esse magic number que, em hexadecimal é nada mais do que 0xCAFEBABE ou simplesmente Cafe Babe.

Faça o teste! abra qualquer .class em um editor hexadecimal e veja o resultado…

Na linha de comando do Linux:

hexdump -C arquivo.class

Saída

00000000 ca fe ba be 00 00 00 32 00 81 0a 00 21 00 4a 0a |Êþº¾...2....!.J.|
00000010 00 0f 00 4b 09 00 0f 00 4c 07 00 4d 0a 00 04 00 |...K....L..M....|
00000020 4a 0a 00 04 00 4e 0a 00 04 00 4f 07 00 50 09 00 |J....N....O..P..|
00000030 0f 00 51 08 00 52 0b 00 53 00 54 07 00 55 0a 00 |..Q..R..S.T..U..|

No emacs:

 emacs -nw arquivo.class

Mudar para modo hexadecimal:

- aperte Esc

- aperte x

- Digite: hexl-mode

Para sair:

- Crtl+X

- Crtl + C

Enviado por: Raoni Fortes Normanton
Desenvolvedor Java, Dextra Sistemas

Olá pessoal!

Este artigo, através de um exemplo simples de código, utiliza JBoss AOP para aprimorar seu comportamento, enquanto demonstra algumas das principais funcionalidades do framework. Vamos encapsular os interesses transversais da aplicação em aspectos, dar uma olhada em advices e nos novos advices leves que acompanham a versão 2.0 do JBoss AOP. Também estudaremos formas de adicionar interfaces às suas classes.

Baseado no texto original de Kabir Khan.

———-

O Servidor de aplicações JBoss possui suporte nativo à programação orientada a aspectos (Aspect-Oriented Programming ou AOP) em sua versão 5. Entretanto, o JBoss AOP também está disponível como um framework independente para uso use em aplicações executadas em JBoss.

Este artigo, aplica os conceitos de programação orientada a aspectos a um exemplo simples de código, aperfeiçoando o comportamento do código e ao mesmo tempo demonstrando algumas das principais funcionalidades do framework. O encapsulamento dos interesses transversais da aplicação em aspectos através de advices e nos novos advices leves que acompanham a versão 2.0 do framework JBoss AOP serãoo foco principal deste estudo.

Aplicação exemplo

O exemplo utilizado para a demonstração dos conceitos básicos de JBoss AOP é um simples aplicativo bancário. Ele possui uma classe BankAccount:

package bank;
public class BankAccount{ private int accountNumber; private int balance; public BankAccount(int accountNumber){ System.out.println("*** Bank Account constructor"); this.accountNumber = accountNumber; } public int getAccountNumber(){ return accountNumber; } public int getBalance(){ return balance; } public void debit(int amount){ System.out.println("*** BankAccount.debit()"); balance -= amount; } public void credit(int amount){ System.out.println("*** BankAccount.credit()"); balance += amount; }
}

E adicionalmente, possui uma classe Bank:

package bank; import java.util.HashMap;
import java.util.Map; public class Bank{ private static Map bankAccounts = new HashMap(); public static void transfer(BankAccount from, BankAccount to, int amount){ from.debit(amount); to.credit(amount); } public static void main(String[] args){ System.out.println("*** Creating account 1"); BankAccount acc1 = new BankAccount(1); acc1.credit(150); bankAccounts.put(acc1.getAccountNumber(), acc1); System.out.println("*** Creating account 2"); BankAccount acc2 = new BankAccount(2); acc2.credit(230); bankAccounts.put(acc2.getAccountNumber(), acc2); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance()); //Transfer some money System.out.println("*** Transfer 50 from account 1 to account 2"); transfer(acc1, acc2, 50); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance()); }
}

Como se observa, foram criadas duas contas de banco com seus números de conta, definidos os saldos iniciais de cada conta, e então foram transfedos $50 da contra 1 para a conta 2.

Quando este código é executado, a saída esperada é a apresentada abaixo:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280

Logging: um interesse transversal à aplicação

Uma das principais motivações para o uso de programação orientada a aspectos é extrair do código de negócio da aplicação interesses transversais, geralmente não-funcionais. Supondo que seja necessário auditar a aplicação através de logging toda vez que um objeto for criado, quando valores forem atribuídos a seus campos, e quando seus métodos forem invocados. A maneira mais óbvia para este fim, e que foi utilizada no exemplo acima, consiste em acrescentar código de logging em diversos pontos do código da aplicação.

O problema desta abordagem é que pode ser necessário editar muitos pontos do código da aplicação, espalhados por todo o sistema, os quais deveria ser identificados, modificados para o acréscimo do código de logging, e posteriormente uma recompilação da aplicação seria necessária. Além disso, para este comportamento seja desligado, pode ser necessário remover todo o código de logging novamente e recompilar a aplicação uma vez mais. Assim, a maneira óbvia também é tediosa e difícil de ser mantida.

Utilizando AOP, é possível encapsular este interesse transversal no código de um aspecto. O aspecto em si é apenas mais uma classe Java, que pode manter estado, estender outras classes e tudo o que se pode fazer com uma classe Java.

package bank; import org.jboss.aop.joinpoint.ConstructorInvocation;
import org.jboss.aop.joinpoint.FieldWriteInvocation;
import org.jboss.aop.joinpoint.MethodInvocation; public class LoggingAspect{ public Object log(ConstructorInvocation invocation) throws Throwable{ try System.out.println("C: Creating BankAccount using constructor " + invocation.getConstructor()); System.out.println("C: Account number: " + invocation.getArguments()[0]); return invocation.invokeNext(); finally System.out.println("C: Done"); } public Object log(MethodInvocation invocation) throws Throwable{ try System.out.println("M: Calling method " + invocation.getMethod().getName()); System.out.println("M: Amount " + invocation.getArguments()[0]); return invocation.invokeNext(); finally System.out.println("M: Done"); } public Object log(FieldWriteInvocation invocation) throws Throwable{ BankAccount account = (BankAccount)invocation.getTargetObject(); System.out.println("F: setting field " + invocation.getField().getName() + " for BankAccount " + account.getAccountNumber()); System.out.println("F: Field old value " + account.getBalance()); System.out.println("F: New value will be " + invocation.getValue()); try return invocation.invokeNext(); finally System.out.println("F: Field new value " + account.getBalance()); System.out.println("F: Done"); }
}

O código que implementa os interesses transversais é encapsulado em métodos do aspecto denominados advice. Os advice apresentados nesta sessão são do tipo around advice, e sua assinatura e formato são os seguintes:

public Object (org.jboss.aop.joinpoint.Invocation invocation) throws Throwable{ //Faça alguma coisa antes try return invocation.invokeNext(); finally //Faça alguma coisa depois }

O parâmetro invocation pode ser do tipo org.jboss.aop.joinpoint.Invocation, ou alguma de suas subclasses. Algumas destas subclasses são apresentadas no aspecto LoggingAspect, e o método log sobrecarregado a ser chamado depende do que estiver sendo chamado no código de negócio quando o aspecto for aplicado. Em LoggingAspect é possível tratar chamadas a um construtor de objeto, (como é feito pelo primeiro método log() do aspecto), chamadas a um método de objeto (como é feito pelo segundo método log() do aspecto), e chamadas a métodos setXX() de um campo de objeto (como é feito pelo terceiro método log() do aspecto).

Estes eventos, ou pontos de entrada para a aplicação do aspecto, são chamados joinpoints na terminologia AOP. O parâmetro invocation contém informação sobre qual campo/método/construtor sendo invocado. Métodos advice do tipo around também devem conter uma chamada a Invocation.invokeNext(), que realiza a propagação da cadeia de chamadas. Se houver diversos métodos advice aplicados a um mesmo joinpoint, esta chamada invoca o próximo advice da cadeia. Se este for o último advice a cadeia, ou como no exemplo acima, se houver apenas um advice na cadeia, o código do joinpoint (ou seja o código executado no objeto de negócio) é chamado quando Invocation.invokeNext() é executado.

Para aplicar o aspecto de logging ao código de negócio, é preciso definir alguma configuração para declarar o aspecto, e selecionar os joinpoints na aplicação de exemplo, a partir de onde os métodos advice serão invocados. No JBoss AOP, ma maneira mais simples de se fazer esta configuração é através de um arquivo XML, tipicamente chamado jboss-aop.xml. Em primeiro lugar, o aspecto é declarado:

<aop>
<aspect class="bank.LoggingAspect"/>

Em uma tag bind é definida uma amarração, utilizando o atributo pointcut da tag para selecionar os métodos de negócio aos quais um dos métodos advice do aspecto devem ser aplicados. Neste caso, tem-se uma expressão de construtor, que seleciona o construtor da classe bank.BankAccount que possua um parâmetro int. É importante notar que todos os nomes de classes utilizados em uma expressão de pointcut devem ser completamente qualificados.

A palavra new é um identificador especial dentro da linguagem de definição de pointcuts, utilizada para selecionar um construtor. Em seguida, a parte around da amarração indica que o advice log do aspecto bank.LoggingAspect deve ser aplicado a todos os joinpoints do código de negócio aos quais a definição deste pointcut se aplica. Em outras palavras, quando o construtor da classe BankAccount for invocado, o primeiro método LoggingAspect.log(), que recebe como parâmetro um ConstructorInvocation, é invocado.

 <bind pointcut="execution(bank.BankAccount->new(int))"> <around aspect="bank.LoggingAspect" name="log"> </bind>

A amarração de pointcut anterior captura apenas um joinpoint. A próxima utiliza um coringa no lugar do nome do método, de forma que selecionamos todos os métodos que retornem void e que recebem um int como parâmetro, não obstante seu nome. Ela se parece muito com a expressão de construtor da amarração anterior, mas inclui o tipo de retorno dos métodos de interesse para logging. Este pointcut seleciona BankAccount.debit() e BankAccount.credit(), e invoca o segundo método LoginAspect.log() passando um MethodInvocation como parâmetro quando esses métodos são chamados.

<bind pointcut="execution(void bank.BankAccount->*(int))"> <around aspect="bank.LoggingAspect" name="log"/>
</bind>

Finalmente, há uma amarração que captura as atribuições feitas ao campo de saldo (balance) da classe BankAccount. Neste caso, utiliza-se um coringa no lugar no nome do tipo, e o terceiro método LoggingAspect.log(), que recebe um FieldWriteInvocation, será invocado quando o campo tiver seu valor modificado.

<bind pointcut="set(* bank.BankAccount->balance)"> <around aspect="bank.LoggingAspect" name="log"/>
</bind>

Além de coringas, também é possível capturar hierarquias de herança inteiras de classes, utilizando typedefs para expressões de classe complexas, capturar todas as classes pertencentes a um determinado pacote, e como será apresentado posteriormente, utilizar anotações para capturar uma ampla gama de joinpoints.

Para executar esta aplicação com AOP habilitada, é necessário passar alguns parâmetros extras para a JVM quando a aplicação for iniciada, como pode ser visto no build.xml do exemplo.

 <target name="run-load-time" depends="compile"> <java fork="yes" failOnError="true" className="bank.Bank"> <sysproperty key="jboss.aop.path" value="jboss-aop.xml"/> <jvmarg value="-javaagent:../libraries/jboss-aop-jdk50-single.jar"/> <classpath refid="classpath"/> </java> </target>

O parâmetro jboss.aop.path contém o caminho do arquivo jboss-aop.xml que declara os aspectos e amarra os métodos advice aos joinpoints. O argumento –javaagent aponta para a biblioteca do JBoss AOP, que liga o processo de weaving em tempo de carga (load-time weaving). Quando uma classe é carregada pela primeira vez, o JBoss AOP intercepta este evento e modifica o bytecode da classe para acrescentar os pontos de chamada requeridos à invocação dos aspectos relacionados aos joipoints selecionados.

Além de realizar o processo combinação (weaving) de código em tempo de carga das classes, você também pode combinar o código dos aspectos utilizando aopc post-processor. Um exemplo disso é mostrado no build.xml da aplicação exemplo. Ao executar o exemplo com load-time weaving, a seguinte saída é produzida, agora com muita informação extra vinda do aspecto de logging:

*** Creating account 1
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 1
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 150
*** BankAccount.credit()
F: setting field balance for BankAccount 1
F: Field old value 0
F: New value will be 150
F: Field new value 150
F: Done
M: Done
*** Creating account 2
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 2
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 230
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 0
F: New value will be 230
F: Field new value 230
F: Done
M: Done
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
M: Calling method debit
M: Amount 50
*** BankAccount.debit()
F: setting field balance for BankAccount 1
F: Field old value 150
F: New value will be 100
F: Field new value 100
F: Done
M: Done
M: Calling method credit
M: Amount 50
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 230
F: New value will be 280
F: Field new value 280
F: Done
M: Done
*** Balance acount 1: 100
*** Balance acount 2: 280

Externalizando Verificações de Segurança

Logging é o exemplo mais comumente utilizado para uma introdução a AOP, mas é possível fazer algo mais interessante. Supondo que seja necessário ter certeza de que apenas usuários com determinadas permissões possam chamar um método. Seria necessário anotar os métodos de BankAccount da seguinte maneira:

package bank; public class BankAccount{ private int accountNumber; private int balance; @Roles(roles= "admin") public BankAccount(int accountNumber){ System.out.println("*** Bank Account constructor"); this.accountNumber = accountNumber; } ... @Roles(roles= "admin") public void debit(int amount){ System.out.println("*** BankAccount.debit()"); balance -= amount; } @Roles(roles= "admin", "user") public void credit(int amount){ System.out.println("*** BankAccount.credit()"); balance += amount; }
}

De forma que apenas usuários com o perfil admin possam criar instâncias de BankAccount e debitar contas, enquanto que tanto o perfil admin quando o perfil user possam creditar contas. Para simular usuários com acesso ao sistema, suponha a existência de um arquivo security.properties contendo tais informações:

admin=password;admin,user
guest=password;user

Há um usuário chamado admin cuja senha é password e que tem os perfis admim e user, e um usuário chamado guest cuja senha é password e que possui apenas o perfil user.

É possível então aplicar um SecurityAspect aos métodos anotados com a anotação @Roles. Assim como tudo o mais na linguagem de pointcut, as anotações precisam ser completamente qualificadas. O símbolo “..” no lugar dos parâmetros na expressão de pointcut significa que se deseja que este aspecto seja aplicado a todos os construtores e métodos anotados com @Roles, a despeito dos parâmetros que recebam.

<aop> <aspect class="bank.SecurityAspect"/> <bind pointcut="execution(bank.BankAccount->@bank.Roles(..))"> <around aspect="bank.SecurityAspect" name="checkSecurity"/> </bind> <bind pointcut="execution(* bank.BankAccount->@bank.Roles(..))"> <around aspect="bank.SecurityAspect" name="checkSecurity"/> </bind>
</aop>

O aspecto SecurityAspect verifica que o usuário correto esteja sendo utilizado:

package bank;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.util.Arrays;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties; import org.jboss.aop.joinpoint.Invocation; public class SecurityAspect{ private Map<String, String> usernamePassword = new HashMap<String, String>(); private Map<String, List<String>> userRoles = new HashMap<String, List<String>>(); public SecurityAspect() throws FileNotFoundException, IOException, URISyntaxException{ //Inicializa o usernamePassword e o mapa userRoles //com informação do security.properties } public Object checkSecurity(Invocation invocation) throws Throwable{ String username = LoginInfo.getUsername(); String password = usernamePassword.get(username); if (password == null) throw new SecurityException("Unknown user"); if (!password.equals(LoginInfo.getPassword())) throw new SecurityException("Wrong password"); Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class); List<String> hasRoles = userRoles.get(username); boolean hasRole = false; if (hasRoles != null) for (String role : rolesAnnotaton.roles()) if (hasRoles.contains(role)) hasRole = true; break; if (!hasRole) throw new SecurityException("Wrong roles for user"); return invocation.invokeNext(); }

Os perfis necessários para a invocação do joinpoint alvo são obtidas do parâmetro invocation utilizando esta chamada:

Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class);

Este código tem o mesmo efeito que a chamada java.lang.reflect.Method.getAnnotation() ou java.lang.reflect.Constructor.getAnnotation() para um método ou construtor, mas também permite redefinição de anotações como parte da configuração AOP, que está além do escopo deste artigo. Apesar do tipo de invocação utilizada neste exemplo ser Invocation, o tipo específico criado pelo JBoss AOP será ConstructorInvocation ou MethodInvocation, dependendo do que estiver sendo chamando. A classe LoginInfo é apenas um wrapper para alguns campos estáticos contendo username e senha.

package bank; public class LoginInfo{ private static String username; private static String password; public static void setUsernameAndPassword(String username, String password){ LoginInfo.username = username; LoginInfo.password = password; } public static String getUsername(){ return username; } public static String getPassword(){ return password; }
}

Agora, o método Bank.main() será modificado para popular os campos de LoginInfo:

public static void main(String[] args){ System.out.println("*** Log in as 'guest' - it does not have the correct roles to create an account"); LoginInfo.setUsernameAndPassword("guest", "password"); System.out.println("*** Attempting to create account 1"); try BankAccount acc1 = new BankAccount(1); acc1.credit(150); bankAccounts.put(acc1.getAccountNumber(), acc1); catch(SecurityException e) System.out.println("!!! Expected SecurityException " + e.getMessage()); System.out.println("*** Log in as 'admin' - the roles are fine for the rest now"); LoginInfo.setUsernameAndPassword("admin", "password"); System.out.println("*** Creating account 1"); BankAccount acc1 = new BankAccount(1); acc1.credit(150); bankAccounts.put(acc1.getAccountNumber(), acc1); System.out.println("*** Creating account 2"); BankAccount acc2 = new BankAccount(2); acc2.credit(230); bankAccounts.put(acc2.getAccountNumber(), acc2); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance()); //Transfer some money System.out.println("*** Transfer 50 from account 1 to account 2"); transfer(acc1, acc2, 50); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance());
}

Primeiro o método tenta criar uma BankAccount com um usuário que não possui o perfil admim requerido, e então o processo é repetido com um usuário que possui o perfil requerido. Quando a aplicação é executada, a seguinte saída é apresentada:

*** Log in as 'guest' - it does not have the correct roles to create an account
*** Attempting to create account 1
!!! Expected SecurityException Wrong roles for user
*** Log in as 'admin' - the roles are fine for the rest now
*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280

Ao utilizar AOP para controle de segurança, as verificações de segurança foram extraídas para um local centralizado na aplicação e foram utilizadas anotações para configurar sinalizar os aspectos sobre onde aplicar a segurança. Se for desejável utilizar um mecanismo diferente de configuração de usuários, é possível manter o núcleo de negócio da aplicação intacto, escrever um outro aspecto e modificar facilmente a maneira como a segurança é aplicada em toda a parte do sistema modificando o arquivo jboss-aop.xml.

Métodos Advice Leves

Os méodos advice vistos até o momento são do tipo around, que tem sido parte do framework JBoss AOP desde seu início. Eles permitem adicionar comportamento antes e depois da invocação do joinpoint alvo. Como visto, estes advice recebem como argumento um parâmetro do tipo Invocation, ou uma subclasse desta. Em uma aplicação com muitos pontos de aplicação de aspectos, toda vez que for necessário invocar um joinpoint que possua métodos advice aplicados a ele, o framework AOP precisará instanciar o objeto Invocation, e isto pode causar algum reflexo no desempenho da aplicação.

Para alinhar o framework ao que é oferecido por outros frameworks de AOP, foi introduzido o conceito de métodos advice leves, que não requerem a instanciação de um objeto Invocation. O objeto Invocation contém muita informação conceitual a respeito do que está sendo chamado, mas ainda é possível obter boa parte desta informação por outros meios. De volta a exemplo de logging, pode-se reescrever LoggingAspect sobre o que fazer quando campos são modificados:

package bank; import org.jboss.aop.advice.annotation.Arg;
import org.jboss.aop.advice.annotation.JoinPoint;
import org.jboss.aop.advice.annotation.Target;
import org.jboss.aop.joinpoint.FieldAccess; public class LoggingAspect{ public void logBefore(@JoinPoint FieldAccess fieldAccess, @Target BankAccount account, @Arg int value){ System.out.println("F: setting field " + fieldAccess.getField().getName() + " for BankAccount " + account.getAccountNumber()); System.out.println("F: Field old value " + account.getBalance()); System.out.println("F: New value will be " + value); } public void logAfter(@Target BankAccount account)[ System.out.println("F: Field new value " + account.getBalance()); System.out.println("F: Done"); }
}

O método log original foi dividido em dois métodos. Um advice do tipo before, logBefore(), que será disparado ates do campo ser modificado, e um advice do tipo after, logAfter(), que será disparado após o campo ser modificado. Para o método logBefore(), o parâmetro fieldAccess, anotado com @JoinPoint?, contém informação sobre o campo a ser modificado, o parâmetro account, anotado com @Target, recebe o objeto cujo campo será modificado, e o parâmetro value, anotado com @Arg, recebe o novo valor que será atribuído ao campo.

De maneira análoga, para o método logAfter(), o parâmetro account, anotado com @Target, recebe o objeto cujo campo foi modificado. É importante notar que como os métodos advice leves nunca recebem um parâmetro Invocation, não há necessidade de se chamar Invocation.invokeNext(). O framework JBoss AOP sabe quais advices chamar antes e após uma chamada ao joinpoint alvo. Para amarrar estes advices, é utilizado o seguinte xml:

<aop> <aspect class="bank.LoggingAspect"/> <bind pointcut="set(* bank.BankAccount->balance)"> <before aspect="bank.LoggingAspect" name="logBefore"/> <after aspect="bank.LoggingAspect" name="logAfter"/> </bind>
</aop>

Esta declaração é similar ao exemplo de logging anterior, mas ao invés de utilizar around nesta amarração, foi utilizada uma entrada before e uma entrada after, especificando que logBefore() deve ser chamado antes do campo ser modificado e logAfter() deve ser chamado após o campo ser modificado. Ao executar este exemplo temos a seguinte saída:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
F: setting field balance for BankAccount 1
F: Field old value 0
F: New value will be 150
F: Field new value 150
F: Done
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 0
F: New value will be 230
F: Field new value 230
F: Done
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
F: setting field balance for BankAccount 1
F: Field old value 150
F: New value will be 100
F: Field new value 100
F: Done
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 230
F: New value will be 280
F: Field new value 280
F: Done
*** Balance acount 1: 100
*** Balance acount 2: 280

Além dos tipos before e after, também é possível utilizar advices do tipo throwing, que são chamados quando o joinpoint alvo lança uma exceção, e advices do tipo finally, que são chamados após o joinpoint alvo, não obstante uma exceção ter sido ou não lançada pelo joinpoint. Como vimos, advices do tipo after são chamados após a execução o joinpoint alvo, desde que nenhuma exceção tenha sido lançada por ele.

Observer com introduções de interfaces e mixins

Supondo que fosse necessário enviar uma notificação de alguma maneira quando o saldo da conta bancária for modificado. Uma opção para implementar este comportamento seria implementar o padrão de projeto Observer, mas é indesejável incluir todo o código de infra-estrutura deste padrão na classe BankAccount. Primeiramente, considere uma anotação ao campo balance, que será monitorado.

package bank; public class BankAccount{ int accountNumber; @Observed int balance; ...
}

Em seguida, uma implementação de Observable:

package bank; import java.util.ArrayList;
import java.util.List; public class ObservableMixin implements Observable{ private List observers = new ArrayList (); public void addObserver(Observer listener){ observers.add(listener); } public void removeObserver(Observer listener){ observers.remove(listener); } public void notifyObservers(Object event){ for (Observer observer : observers){ observer.update(event); } }
}

Esta é uma classe mixin, que implementa a interface Observable. Ela contém todo o código de infra-estrutura necessário para a parte Observable do padrão. E pode ser introduzida em POJOs utilizando o seguinte xml:

<aop> <introduction expr="hasfield(* *->@bank.Observed)"> <mixin> <interfaces> bank.Observable </interfaces> <class>bank.ObservableMixin</class> </mixin> </introduction> ...

Este xml faz duas coisas. Primeiramente, faz com que todas as classes que tenham um campo anotado com @Observed implemente a interface Observable e seus méodos. Em segundo lugar, quando alguém tenta chamar os métodos da interface Observable, as chamadas são delegadas para uma instância da interface ObservableMixin.

A seguir, um aspecto é declarado para monitorar campos anotados com @Observed quando estes são modificados, conforme mostra o seguinte xml:

... <aspect class="bank.ObserverAspect"/> <bind pointcut="set(* bank.BankAccount->@bank.Observed)"> <around aspect="bank.ObserverAspect" name="fieldChanged"/> </bind>
</aop>

O aspecto é um advice do tipo around que captura os valores antes e depois da modificação do campo.

package bank; import java.lang.reflect.Field; import org.jboss.aop.joinpoint.FieldWriteInvocation; public class ObserverAspect{ public Object fieldChanged(FieldWriteInvocation invocation) throws Throwable{ Observable tgt = (Observable)invocation.getTargetObject(); Field fld = invocation.getField(); String fieldName = fld.getName(); fld.setAccessible(true); Object oldVal = invocation.getField().get(tgt); Object result = invocation.invokeNext(); Object newVal = invocation.getField().get(tgt); tgt.notifyObservers("Changed " + fieldName + " from " + oldVal + " to " + newVal); return result; }
}

Como as classes capturadas pelo pointcut são classes que implementam a interface Observable, é seguro realizar um casting para esta interface. Então, os valores antes e depois da modificação do campo são registrados e a interface Observable é utilizada para notificar os observadores a respeito da modificação. Conforme mencionado, a chamada a Observable.notifyObservers() acabará sendo respondida pela classe ObservableMixin.

Finalmente, o método Bank.main() será modificado para registrar um Observer com uma instância de BankAccount.

 public static void main(String[] args){ System.out.println("*** Creating account 1"); BankAccount acc1 = new BankAccount(1); acc1.credit(150); bankAccounts.put(acc1.getAccountNumber(), acc1); System.out.println("*** Creating account 2"); BankAccount acc2 = new BankAccount(2); acc2.credit(230); bankAccounts.put(acc2.getAccountNumber(), acc2); System.out.println("Installing observer"); ((Observable)acc2).addObserver(new Observer() public void update(Object evt) System.out.println("!!! Observer: " + evt); ); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance()); //Transfer some money System.out.println("*** Transfer 50 from account 1 to account 2"); transfer(acc1, acc2, 50); System.out.println("*** Balance acount 1: " + acc1.getBalance()); System.out.println("*** Balance acount 2: " + acc2.getBalance()); }

Apesar de a classe BankAccount não implementar a interface Observable até que o processo de weaving tenha ocorrido, o compilador Java não realiza nenhuma verificação quando o casting para uma interface é realizado (apenas para uma superclasse), portanto, o casting de BankAccount para Observable irá compilar. (Se o exemplo for executado sem weaving, um ClassCastException será disparado pois BankAccount não implementará a interface Observable). Quando este exemplo é executado, pode-se ver quando o Observer registrado é notificado:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
Installing observer
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
!!! Observer: Changed balance from 230 to 280
*** Balance acount 1: 100
*** Balance acount 2: 280

Conclusão

Partindo de uma aplicação simples e adicionando comportamento extra a ela usando JBoss AOP, algumas das características oferecidas pelo framework foram exploradas. Além de adicionar algumas anotações para auxiliar expressões de pointcut, (e ainda há maneiras menos intrusivas, se bem que mais inconvenientes, de se obter um efeito similar), o núcleo da aplicação foi mantido intacto, e comportamento transversal extra foi adicionado, tal como logging e segurança, com a aplicação de aspectos, bem como pela combinação de aspectos, introdução de interface e mixins para implementar o padrão Observer.

Enviado por: Paulo Crestani
Desenvolvedor Java, Dextra Sistemas

Olá pessoal,

Está disponível para download a versão 8.4 do PostgreSQL.

Após 16 meses de desenvolvimento, foram adicionadas quase 300 melhorias em todos os aspectos do SGBD, para mais detalhes clique aqui.

A atualização para a versão 8.4 é altamente recomendada.

• Foram desenvolvidas e aperfeiçoadas ferramentas de administração e monitoramento.
• Novos comandos foram adicionados para tornar a programação em banco de dados mais simples e compacta.
• Características avançadas do padrão SQL ANSI 2003 de windowing functions, common table expressions e consultas recursivas permitem a elaboração de relatório complexos em uma única consulta.
• Melhorias de performance em todos os aspectos. Destaque para otimização do tempo de restauração do banco e tempo de execução de consultas (semi-join e anti-join).

O grupo de desenvolvedores do PostgreSQL visa a cada versão tornar a administração e desenvolvimento nesse banco de dados mais fácil e produtivo, sem deixar de lado as características de robustez e performance que consagraram o SGBD livre mais avançado do mundo.

Confira a lista completa de cursos e consultoria PostgreSQL oferecida pela Dextra.

Enviado por: Matheus Ricardo Espanhol
Administrador de Banco de Dados, Dextra Sistemas

Os benefícios dessa replicação são muitos, fato que levou o grupo de desenvolvedores do PostgreSQL a se dedicar na criação e aperfeiçoamento de suas funcionalidades, o que antes ocorria com a ferramenta de replicação Slony-l. Como resultado dessa dedicação pode-se esperar o aumento constante do uso do Warm Standby para prover alta disponibilidade no PostgreSQL.

A partir da versão 8.2 do PostgreSQL, foi incorporada uma contrib chamada pg_standby. Este utilitário é responsável pelo gerenciamento da réplica que permanecerá em constante restauração dos logs de transação recebidos pelo servidor de produção até o momento da falha (crash) do mesmo, ocorrendo então o failover.
Com o pg_standby é possível uma replicação consistente sem ocasionar relevantes impactos à performance do sistema. Esta relação desempenho e consistência é um desafio para as soluções de replicação de banco de dados, sendo essa característica o maior benefício da replicação Warm Standby. Mas as vantagens não param por aí, o pg_standby permite também a recuperação imediata do servidor Standby, tornando-o disponível para acesso segundos após o crash do servidor de produção. Configuração de limpeza dos logs já restaurados ou armazenamento dos mesmos para backup e restauração PITR (Point in Time Recovery) também oferecem grande vantagem.

Para melhor compreender as vantagens do Warm Standby, basta analisar o funcionamento interno do PostgreSQL em relação a utilização dos logs de transação.
SGDBs avançados utilizam intensamente a memória principal para obter desempenho no gerenciamento dos dados. Por outro lado, dados em memória são perdidos na ocasião de uma falha inesperada no servidor. Surge então, a necessidade de um armazenamento intermediário no próprio disco, porém com uma característica que permita o acesso rápido na leitura e escrita. Para suprir essa necessidade são utilizados os logs transacionais, que possuem estrutura seqüencial para facilitar o acesso ao disco. No PostgreSQL esses logs são denominados WAL (Write Ahead Logs), estão presentes no diretório $PGDATA/pg_xlog e possuem por padrão 16MB (Ver figura 1). Em um intervalo de tempo configurado ou através de comando SQL, as transações que sofreram COMMIT são transferidas do WAL para o arquivo de dados e os logs são reciclados, essa operação é conhecida como CHECKPOINT.

Figura 1 – Diretório do WAL

De tempos em tempos, as transações em memória são gravadas no WAL. As que sofreram COMMIT em memória podem ser gravadas de forma síncrona nos logs. A partir do momento que as transações estão nos logs, elas já podem ser recuperadas em caso de crash no banco de dados. Mas, e as transações que não sofreram COMMIT antes do crash? Foram perdidas, pois estavam totalmente em memória ou desfeitas se parcialmente gravadas no WAL. Observando a figura 2, pode-se entender o que acontece com as transações, nos seus possíveis estados, em caso de crash no banco de dados:

Figura 2 – Gerenciamento de transações

O PostgreSQL utiliza um método conhecido como REDO para recuperar transações presentes no WAL. O REDO consiste em refazer toda a transação através das informações contidas no WAL. Sendo assim, em caso de falha, a transação TR1 da figura acima, estaria no arquivo de dados após o CHECKPOINT, portanto não necessitaria de recuperação. A TR2 e a TR3 estariam completamente no WAL, sendo necessário o REDO para refazê-las totalmente. A TR4 sofreria o ROLLBACK do sistema e para TR5 nada precisaria ser feito, pois foi eliminada na memória.

Mas e a replicação, como acontece? Com a cópia base do banco principal no servidor Standby, após o CHECKPOINT e antes da reciclagem, os arquivos WAL podem ser transferidos para um diretório do servidor Standby. O pg_standby é responsável pela aplicação dos logs no arquivo de dados do servidor Standby, aguardar o sinal para finalizar a restauração e disponibilizar o acesso imediato ao banco recuperado.

Reforçando tecnicamente as vantagens, o arquivamento do WAL ocorre em paralelo e de forma assíncrona, portanto não interfere no desempenho do banco de dados. A constante restauração do servidor Standby, permite o início imediato do mesmo após o crash do servidor principal. Os logs podem permanecer para backup, tanto no servidor principal, quanto no servidor Standby ou podem ser eliminados após a restauração. Todo o processo de sincronização entre memória e WAL, WAL e arquivo de dados, arquivamento, transferência e restauração dos logs podem ser configurados baseados no ambiente em que está inserido. Esta técnica pode ser combinada com técnicas de identificação de indisponibilidade do servidor, podendo todo o processo ser automatizado ou monitorado.

Melhorias para essa técnica de replicação são esperadas para a versão 8.5 do PostgreSQL. Dentre elas destacam-se a implementação da replicação síncrona, conhecida como Hot Standby, o arquivamento de transações que ainda estão em memória e a disponibilização do servidor Standby para leitura.

Concluindo, esta é uma técnica de replicação que pode ser ideal para vários ambientes, porém existem várias técnicas para implementação de alta disponibilidade em ambientes críticos. A Dextra possui grande experiência na implementação de alta disponibilidade no PostgreSQL, disponibilizando esse conhecimento no treinamento de Alta disponibilidade, onde o aluno será habilitado a configurar alta disponibilidade através do PostgreSQL Warm Standby e ferramentas como SLony-I, Pgpool, entre outras.

Enviado por: Matheus Ricardo Espanhol
Administrador de Banco de Dados, Dextra Sistemas

Como o intuito de disseminar conhecimento, a Dextra Sistemas lançou este espaço para que nós, Administradores de Banco de Dados, possamos compartilhar nossas experiências diárias sobre o tema.

Neste primeiro post falaremos sobre o PostgreSQL, apresentando de forma resumida, duas funcionalidades que estarão disponíveis na versão 8.4, com lançamento previsto para maio ou junho deste ano. Uma versão beta da versão 8.4 já está disponível no site www.postgresql.org.

Um problema recorrente que os administradores de bancos de dados encontram é em relação à configuração da codificação (conhecida como charset ou encoding) e localização (conhecida como locales) em aplicações de ambientes que possuem regras heterogêneas de linguagens e países distintos. Localização são regras que definem parâmetros de ordenação, classificação e agrupamento da informação de acordo com a localidade e a linguagem de cada região.

Em aplicações onde se tenha o requisito de suporte a múltiplas regras de localidade, precisamos que o servidor de banco de dados possua suporte, e a boa notícia é que o PostgreSQL, a partir da versão 8.4 terá esse suporte. Na nova versão, o PostgreSQL se desprende da codificação e da localização do sistema operacional e permite que em um mesmo cluster seja possível trabalhar com distintas codificações e localizações.

Após uma contextualização e a importância de se possuir uma flexibilidade e adaptação a qualquer conjunto de regras (locales), é apresentado como implementar esta funcionalidade no PostgreSQL.

Primeiro é necessário realizar a conexão a um banco de dados, e em seguida executar o comando create database.

A conexão com o PostgreSQL pode ser realizada a partir da seguinte linha:

psql postgres -U postgres

O próximo passo é a criação do banco de dados na codificação e localização desejada.

CREATE DATABASE dextra ENCODING='Latin1' COLLATE='pt_BR' CTYPE='pt_BR' TEMPLATE=template0;

Um detalhe é importante: Ao criar um banco de dados e especificar um locale diferente do padrão do cluster é necessário usar o template0 como template.

Uma forma de visualizar o banco, sua respectiva codificação e localização é:

SELECT datname,pg_encoding_to_char(encoding),datcollate,datctype FROM pg_database;

Um outro problema enfrentado pelos administradores de banco de dados é o momento de realizar um processo de restore, quando este é relativamente grande. Como uma solução de minimizar este problema, a partir da versão 8.4 será possível paralelizar o processo de restauração. Isso poderá ser feito através do parâmetro -m (multi-thread) do utilitário pg_restore.

Enviado por: João Paulo Müller da Silva
Administrador de Banco de Dados, Dextra Sistemas

Como dissemos no primeiro post, a equipe de desenvolvedores Java da Dextra irá postar uma série de artigos e dicas sobre desenvolvimento neste Blog, e como primeiro post, iremos apresentar uma dica sobre Regex (expressões regulares).

Várias vezes precisamos utilizar expressões regulares para validar algum campo ou para extrair partes dele.

Normalmente, quando queremos dizer que há caracteres alfanuméricos em uma expressão, utilizamos o \w. Porém ele se limita à classe [a-zA-Z_0-9], não incluindo os caracteres acentuados. O que fazíamos era adicionar nesta classe estes caracteres um a um, mais ou menos assim: [\wÁáÉé].

Para facilitar nossa vida, há um range que inclui todos estes caracteres: À-ú, deixando nossa classe bem mais simples:

[\wÀ-ú]
ou a String em java: “[\\wÀ-ú]”

Esperamos que esta dica tenha sido útil para você

Enviado por: Raoni Fortes Normanton
Desenvolvedor Java, Dextra Sistemas

Como um meio de compartilhar experiências de desenvolvimento Java com a comunidade, a Dextra abriu este canal pelo qual a equipe de desenvolvedores irá postar uma série de artigos e dicas sobre a tecnologia. Serão abordados assuntos que exponham experiências e reflexões sobre o dia-a-dia do desenvolvimento de aplicações.

Sejam todos bem vindos!

Equipe de Desenvolvimento Java - Dextra Sistemas