Second-generation aspect-oriented programming (2)

转载 2004年10月20日 12:40:00
 

Second-generation aspect-oriented programming

Apply advice dynamically with the new crop of AOP frameworks

rule_ltblue.gif
Printer-friendly versionPrinter-friendly version | Send this article to a friendMail this to a friend


Page 2 of 3

Advertisement
?SIT=jw-BigBox&BA=1

An AOP wish list
As powerful as the AspectJ implementation of AOP is, a demanding developer can always find something new to request. The most obvious is right in front of us: aspects aren't written in Java. That means learning not just a new design, but also new language syntax—and not only does the developer need to understand the AspectJ language, so do the tools that he or she uses. An all-Java way of writing aspects would be welcome.

The way AspectJ ties advice to methods—writing a pointcut expression that matches the names of the methods to be advised—changes the meaning of traditional Java programs in another way. In ordinary Java, a method name is simply an identifier. Far more important than any comment, a well-chosen name is the best way of making a method's purpose obvious to a reader. But in AspectJ, method names (and class, constructor, and field names—although I've given only an example of advising a method, AspectJ can also attach advice to other program constructs) have two purposes: as well as communicating, they must also serve as targets of matching expressions. Changing a method name in a program that includes aspects can cause the method to not be advised when it should be, or to be advised when it shouldn't. Adding and removing methods can cause unexpected effects with aspects as well. Some tools address these issues with AspectJ, but aspects aren't making our life as simple as we had hoped. And even if we manage to keep all of our pointcuts synchronized with our identifiers, we may be tempted to change our identifiers to match existing pointcuts or allow us to write shorter pointcuts, which might compromise our program's readability. Is there another way?

A different issue arises when considering more complex applications than our little example, particularly in distributed, multiuser systems. The advice shown in our example applies to every instance of ContextRetrieverImpl in the virtual machine. Instead, we might want to be able to have some instances of ContextRetrieverImpl that are advised and some that are not. For example, if advice attached to an object consumes significant memory or other resources, we probably don't want it attached to currently unused instances sitting in a cache. Advice with references to unserializable objects might prevent us from serializing an otherwise serializable object. AspectJ does not currently allow us to advise only some instances of a class. There are workarounds, but it would be nice to address the issue directly.

Finally, we might like another kind of flexibility: we might like to be able to add aspects to or subtract aspects from an already-compiled program, or to change the program constructs to which an aspect applies without recompiling. We can't with AspectJ because it weaves advice into advised classes at compile time. (Demonstrate this with the example by deleting the compiled aspect, ContextPasser.class, before running the test.) This behavior violates good object-oriented practices, which strive for designs whose behavior can be changed by configuration, without recompiling. The just-released AspectJ 1.2 does have limited support for weaving advice at load time rather than at compile time, but it addresses only some of the issues discussed here.

The recent trend in the enterprise software world towards lightweight, transparent middleware runs head-on into these issues. In the last year or so, numerous developer groups, looking for a way around the ever-increasing complexity of EJB, have poured their energy into new frameworks aiming to reduce the amount of boilerplate code and configuration that must be written (or generated) when creating a service. High-profile examples in the open source world include JBoss 4.0, Spring, PicoContainer, and HiveMind. Large application server vendors are interested as well, as evidenced, for example, by BEA's support of the Beehive project. Many Web services frameworks, both free and commercial, provide a simplified container as well as or instead of an EJB-based container. And finally, the trend reached a new level of importance in May when Sun's Linda DeMichiel revealed that EJB 3.0 will sweep away much of the old EJB API as well.

All of this activity has energized several interesting areas of investigation in application server design. The facet of interest to our AOP discussion is that middleware has finally been widely recognized as AOP's killer application. Much application-server functionality can be cleanly and logically expressed as aspects. Context-passing, remoting, security, and transactions can all be thought of as add-on functionality that happens "around" (before and/or after) a method call to an ordinary object. Aspect-oriented programming allows an application server designer to provide these features without requiring service developers to extend abstract classes or implement interfaces.

With the spotlight now on AOP in application server environments, AspectJ's restrictions that we discussed above have become important. Flexible, dynamic AOP has been seen as so important to future development that in the last year or so, several new AOP frameworks that address these restrictions have actually been developed. Let's look at our context-passing example reimplemented in one of the new AOP frameworks, JBoss AOP, to see how it stands up to the demands of complex, dynamic applications.

Page 1 Second-generation aspect-oriented programming
Page 2 An AOP wish list
Page 3 Dynamic AOP with JBoss AOP

Second-generation aspect-oriented programming (1)

  Second-generation aspect-oriented programming Apply advice dynamically with the new crop of AOP fr...
  • jgo
  • jgo
  • 2004年10月20日 12:36
  • 1045

Second-generation aspect-oriented programming (3)

  Second-generation aspect-oriented programming Apply advice dynamically with the new crop of AOP fr...
  • jgo
  • jgo
  • 2004年10月20日 12:42
  • 1005

AOP( aspect-oriented programming)面向切面编程

AOP( aspect-oriented programming)面向切面编程 一、什么是AOP? 可以通过预编译方式和运行期动态代理实现在不修改源代码情况下给程序动态统一添加功能的一种技术。 ...
  • ly969434341
  • ly969434341
  • 2016年08月27日 19:45
  • 346

Aspect-oriented programming

我们对面向过程和面向对象的编程语言已经耳熟能详了。 今天来看看Aspect-oriented programming,也就是面向行为的编程。 参考wiki,写的很不错: http://en....
  • OnlyQi
  • OnlyQi
  • 2011年12月31日 12:46
  • 2418

Second-generation aspect-oriented programming By Dave Schweisguth

Dynamic AOP with JBoss AOP JBoss AOP is an AOP implementation developed by JBoss. While it came out ...
  • WonderOne
  • WonderOne
  • 2004年12月21日 12:59
  • 1230

AOP(面向切面编程 Aspect Oriented Programming)

AOP(面向切面编程 Aspect Oriented Programming)概念(百度百科) 通过 预编译方式和运行期动态代理 实现 程序功能 的 统一维护 的一种技术。特点:低耦合,高聚合。 A...
  • daisywangyy
  • daisywangyy
  • 2016年06月12日 10:01
  • 856

Java 面向切面编程(Aspect Oriented Programming,AOP)

本文内容 实例 引入原始方法装饰者模式 JDK 动态代理和 cglib 代理直接使用 AOP 框架——AspectWerkz 新公司使用了 AOP 相关的技术,于是复习一下,没怎么...
  • wah001
  • wah001
  • 2017年07月09日 09:51
  • 129

AspectC++

About the Project The success of Aspect-Oriented Software Development rises and falls with user-fri...
  • gxp
  • gxp
  • 2012年03月13日 14:59
  • 705

AOP-面向切面的编程

课程概要: AOP的简介AOP的示例AOP的术语AOP的实现者 一.AOP的简介 1.AOP的基本概念 AOP即Aspect-Oriented programming的缩写,中文意思是面向...
  • icarus_wang
  • icarus_wang
  • 2016年06月15日 18:33
  • 461

AOP面向切面编程(Aspect Oriented Programming)

AOP为Aspect Oriented Programming的缩写,意为:面向切面编程,通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。AOP是OOP的延续,是软件开发中的一个热点,...
  • sidihuo
  • sidihuo
  • 2016年02月29日 13:50
  • 318
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Second-generation aspect-oriented programming (2)
举报原因:
原因补充:

(最多只允许输入30个字)