[MJ46 - Aspectos] Alguém aí usa aspectos?

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Olá pessoal!

Tentei nessa edição da revista mostrar uma introdução mais "palatável" sobre aspectos, de forma a incentivar o uso desse paradigma.

Tive uma experiência recente em um projeto muito boa com o uso de aspectos com Spring.

Como é a experiência de vocês com aspectos? Alguém já usou? Pretende usar?

[]s

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Opa,

Eu ainda não lí o artigo, quando ler darei um feedback mais preciso.

Atualmente eu utilizo Spring com aspectJ com compile time weaving. É uma mão na roda! Você ganha muito mais controle do que utilizando EJB3, podendo fazer injeção de dependências em qualquer lugar, controle de transação em qualquer lugar etc

Decidi por essa abordagem pois "herdei" um sistema que fazia tudo na mão... controle de transações, segurança etc. Havia muito código duplicado e ocorriam alguns bugs devido a esquecimento de fechar transação, fechar conexão, executar um rollback em caso de exception etc.

Como não haviam testes e o sistema não era bem projetado, optei por utilizar Spring com aspecto para poder interceptar qualquer ponto do código para demarcação de transações. Foi bem simples, em cerca de 2 dias consegui migrar o sistema de 70k linhas de código para o controle do Spring.

[]s

Um dia desses, pra brincar, usei o aspectj com o spring pra interceptor toda chamada
de método (com alguns filtros) e então extrair um report de tempos por método, média,
quantidade de chamadas, etc. Tudo aquilo que o profile do netbeans faz.

Aop para isso é uma mão na roda.

Guerr@ wrote:
Como é a experiência de vocês com aspectos? Alguém já usou? Pretende usar?

Estamos tendo uma boa experiencia com aspectos, usamos em um de nossos projeto para fazer auditoria de acoes como update/delete.

Valeu!

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Utilizar aspectos é mais comum do que se imagina. O próprio EJB 3 vem com o que ele chama de Interceptor, mas que na verdade é uma adaptação do JBoss AOP. E o legal é que você pode aproveitar os recursos do CDI, por exemplo, e de uma maneira mais clara do que utilizando aspectJ. No livro "Real World Java EE Patterns" tem uns exemplos bacanas, como esse que segue:

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

fabiocsilva wrote:Utilizar aspectos é mais comum do que se imagina. O próprio EJB 3 vem com o que ele chama de Interceptor, mas que na verdade é uma adaptação do JBoss AOP. E o legal é que você pode aproveitar os recursos do CDI, por exemplo, e de uma maneira mais clara do que utilizando aspectJ.

Na verdade os interceptors não são bem uma implementação de AOP, apesar de várias vezes poderem ser utilizados com o mesmo propósito. A grande diferença está na existência do "pointcut" que é uma expressão do aspecto que diz onde ele irá interceptar a aplicação. Com o uso de interceptors muitas vezes isso precisa ser configurado individualmente em cada classe. Quanto mais ricas as expressões para pointcut, mais poderosa é a implementação de aspectos.

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Os Interceptors do EJB são sim uma implementação de AOP. Tudo bem que não suportam pointcuts como o JBoss AOP, no qual ele se baseia, mas você deve pensar do ponto de vista de crosscutting concerns. Você também pode incluir Default Interceptors, que interceptam qualquer classe na aplicação. Mas sim, com certeza o AspectJ ou outro framework AOP "completo" é mais poderoso...

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

fabiocsilva wrote:Os Interceptors do EJB são sim uma implementação de AOP.

Eu discordo pela definição que foi dada a AOP. AOP sem pontos de junção é como OO sem herança.

Existem diversas outras formas de separar os crosscutting concerns sem ser usando aspectos. Os traits do Scala são um exemplo (um link interessante http://blog.objectmentor.com/articles/2008/09/27/traits-vs-aspects-in-scala).

Talvez você esteja se perguntando "mas qual a diferença, dá para implementar com os dois!". Desculpe o preciosismo, mas como pesquisador da área as vezes a gente tem que ser meio chato com as definições...

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Aí é questão de ponto de vista. Como falei, com EJB 3.0 é possível definir Default Interceptors, que atingirão todas as classes da aplicação. Além disso, definir quais classes serão afetadas por um aspecto, mesmo que explicitamente no caso de anotar uma classe, é uma forma de pointcut, na minha opinião. E ali onde você viu o @AroundInvoke no código anterior seria o advice. Eu não vejo porque não considerar isso um aspecto, inclusive não acho que essa implementação contrasta com a definição formal de aspecto, mas como já falei antes, é apenas minha opinião.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

fabiocsilva wrote:Aí é questão de ponto de vista. Como falei, com EJB 3.0 é possível definir Default Interceptors, que atingirão todas as classes da aplicação. Além disso, definir quais classes serão afetadas por um aspecto, mesmo que explicitamente no caso de anotar uma classe, é uma forma de pointcut, na minha opinião. E ali onde você viu o @AroundInvoke no código anterior seria o advice. Eu não vejo porque não considerar isso um aspecto, inclusive não acho que essa implementação contrasta com a definição formal de aspecto, mas como já falei antes, é apenas minha opinião.

Na verdade ao anotar a classe, a classe tem conhecimento de que está a interceptando. Uma característica impotante da AOP é a "ignorância" (obliviousness) da classe em relação aos aspectos que a estão modificando. Seria em OO algo próximo ao desacoplamento.

Para tirar a dúvida, sugiro a leitura do artigo original sobre o assunto: Aspect-oriented Programming (http://www.springerlink.com/content/x535m642082k783r/)

Outra leitura interessante é: Aspect-oriented programming is quantification and obliviousness (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.417&rep=rep1&type=pdf)

Na verdade essa não é apenas minha opinião, mas de toda comunidade acadêmica da área!

Me desculpe estar sendo meio chato e insistente, mas é que muita gente tem essa mesma concepção sobre AOP. Quando se percebe que a AOP é muito maior do que um simples uso de interceptors, que existem muitas outras possibilidades, um novo universo se abre!

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Essa rigidez formal não vai levar a projetos melhores. Não sei exatamente o motivo, mas certamente o JCP considerou o uso de pointcuts(ou o JBoss AOP completo) como ferramenta de AOP para o EJB. Devem ter tido bons motivos para rejeitar. Pointcuts são apenas um conceito, a forma de implementar é aberta. Esqueça a palavra chave pointcut do AspectJ e pense como um conceito. Ainda no EJB 3.0, por exemplo, você não precisa marcar um método como transacional para que ele seja transacional num servidor de aplicação. Transação é um dos requisitos ortogonais mais batidos de todos. Além disso, você não precisa "desanexar" um objeto e transformá-lo num DTO, como se fazia antes. Isso é obliviousness, isso é AOP. Default Interceptor é obliviousness, é AOP. E demarcação de classes pode não ser obliviousness mas endereça o objetivo da AOP que é modelar um requisito ortogonal.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

fabiocsilva wrote:Essa rigidez formal não vai levar a projetos melhores. Não sei exatamente o motivo, mas certamente o JCP considerou o uso de pointcuts(ou o JBoss AOP completo) como ferramenta de AOP para o EJB. Devem ter tido bons motivos para rejeitar. Pointcuts são apenas um conceito, a forma de implementar é aberta. Esqueça a palavra chave pointcut do AspectJ e pense como um conceito. Ainda no EJB 3.0, por exemplo, você não precisa marcar um método como transacional para que ele seja transacional num servidor de aplicação. Transação é um dos requisitos ortogonais mais batidos de todos. Além disso, você não precisa "desanexar" um objeto e transformá-lo num DTO, como se fazia antes. Isso é obliviousness, isso é AOP. Default Interceptor é obliviousness, é AOP. E demarcação de classes pode não ser obliviousness mas endereça o objetivo da AOP que é modelar um requisito ortogonal.

Concordo que pointcuts são um conceito, mas discordo que a especificação EJB 3 a implemente. Discordo também que Default Interceptors seja parecido com obliviousness. Os pointcuts são feitos para selecionar os pontos interceptados e a única implementação possível dos default interceptors todos os EJBs.

Na verdade o que estou falando não é sobre rigidez formal, e sim sobre um conceito importante que não está sendo bem interpretado. O entendimento desse conceito e sua utilização pode levar sim a projetos melhores! Por exemplo, ao invés de ter que configurar um interceptor em várias classes (vamos supor que não são todas, mas um subconjunto delas), você poderia configurar isso uma vez só em uma definição de pointcut. Essa solução tornam as classes desacopladas dos aspectos! Essa solução permite que esse subconjunto seja modificado mais facilmente!

Discordo mais uma vez quando assume que a JCP sempre escolhe as melhores soluções. O JPA 1.0, por exemplo, não incluiu Criteria que já tinha no Hibernate. Foi adicionado na JPA 2.0. Já vi várias vezes coisas desse tipo! As especificação do EJB vive aprendendo novas lições com o Spring que ele já implementa a um bom tempo... Então acho errado assumir que se não foi incluído na especificação, então não é uma boa solução ou a melhor solução.

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Esse é o ponto, cara. Você acha que pra criar um aspecto é necessário um pointcut que defina uma expressão regular. Isso não é regra. Um Default Interceptor seria um pointcut com um *, fazendo um paralelo do seu ponto de vista com o do AspectJ. Entenda que aspecto é apenas uma unidade funcional, assim como uma classe, que encapsula um requisito transversal. Isso é um aspecto. A forma como ele vai encapsular não importa. Claro que os interceptadores do EJB 3 não se propõem a ser algo tão poderoso como o AspectJ, claro que Aspectj suporta muito mais formas de "corte" que o EJB. Acontece que as funcionalidades que mencionei anteriormente são uma forma de modelar um requisito transversal. Bastante simples, talvez você diga bastante limitadas ou rudimentares, mas ainda assim úteis. Só pra terminar essa questão do "obliviouness", em qualquer documentação de qualquer framework AOP você vai encontrar pointcuts que interceptam uma única classe ou um único método de uma única classe, só pra você entender que isso de ter um "intervalo de interceptação" nem sempre é verdadeiro e esse não é o problema.
O engraçado é que o post era sobre um artigo e o incentivo do uso de aspectos e eu tirei um exemplo justamente de um livro chamado Real World Java EE Patterns, o cara usando no "mundo real". Ele usa claramente a palavra aspectos, mas nem queria entrar nesse mérito afinal ele não é "acadêmico". E aí você se deixa levar por uma questão menor de expressões regulares quem fundamentam obliviousness. Eu suspeito que o problema é que o artigo seria sobre o uso de AspectJ.
Quanto a JCP, eu me lembrei de uma entrevista com um dos projetistas do Java em que ele comentou sobre a inclusão de suporte a aspectos diretamente na linguagem Java, e ele disse que isso não será feito para que a linguagem não se torne complexa demais.
Enfim, acho melhor terminarmos essa discussão por aqui, porque notadamente temos pontos de vista diferentes. Você acha imprescindível uma expressão pointcut e eu defendo que aspecto é apenas uma unidade funcional para modelar crosscut concerns.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Vamos terminar a discussão por aqui sim... Já colocamos nosso ponto de vista para que cada um possa ler e tirar suas próprias conclusões. Deixei os links dos artigos que citei para os que quiserem se aprofundar. De qualquer forma, agradeço por debater comigo esse tema que considero relevante e mantendo o foco no aspecto técnico da questão.

Termino por aqui deixando claro que não sou contra o uso de interceptors e apenas afirmo que eles são uma abordagem diferente de AOP para modularizar interesses transversais. Ao perceberem que são coisas diferentes, os desenvolvedores podem entender melhor o potencial do uso de AOP em um projeto e se aprofundar nesses conceitos.

Na orientação a aspectos, é responsabilidade do aspecto saber onde ele deve atuar. No uso de interceptors, essa definição não é responsabilidade do interceptor. Essa é a diferença chave entre as duas abordagens. Por mais que pareça boba, pode ter um grande impacto em desacoplamento e manutenibilidade. Essa é uma característica de toda abordagem que se chama de orientada a aspecto, não exclusiva do AspectJ, mas de outras implementações como o JBoss AOP.

Gostaria que os desenvolvedores que conhecem apenas interceptors não pensassem "isso é AOP". AOP é muito mais do que isso! Leiam o meu artigo dessa edição da MundoJ que acho que ficará claro!

Em relação a entrevista que citou, fui eu quem fez essa entrevista! Um de meus objetivos nesse artigo foi justamente desmistificar os aspectos, mostrando que eles não são assim tão complicados como se pensa!

Legal a discussão. Sou um iniciante em aspectos e vou ler o artigo em breve.
Continuem, pois são nessas listas de fóruns onde se refina mais o conhecimento. Pelo menos comigo, funciona bastante ler os "aspectos" diferentes hahaha.

Notícias, artigos e o maior fórum brasileiro sobre Java