-
1. Re: aop: one-way events ?
rmcdonough Aug 12, 2005 10:21 AM (in response to eti_antoniutti)It sounds like you want to use an Introduction + a Mixin. Have a look at the docs for more information on the topic. Do you have a specific example in mind for what you want to do?
Ryan- -
2. Re: aop: one-way events ?
eti_antoniutti Aug 17, 2005 1:28 AM (in response to eti_antoniutti)Hi Ryan, tnx for your post. Sorry for delay, but in Italy we had a short mid-summer holiday :)
Had a look to Introductions+Mixins, it might be what I am looking for.
The idea is to use AOP to build a set of "sensors" and "actuators" to observe and control application behaviour. Instead of re-write legacy application code or hard code this feature in new apps, AOP is the right solution, because:
- it is a separate concern
- avoids adding complexity to code.
What I am doing right now, is designing a control-theoretic model of a middleware layer. I need to observe the classes I have, i.e. throughput between classes, latency, resource allocation ... , and modify some internal parameters in order to control behaviour at system level. It is a closed loop.
Briefly, the structure i'd like to adopt is the following:-------> control logic ---------- | | | V AOP { sensor actuator ^ | | V -------------------------------------------------- APPLICATION
An AOP layer is built on top of the application and a contol layer is built on top of it.
The "sensors" are the easiest part: at runtime the application generates events, that the AOP layer interceps, and the control layer processes.
"Actuators" are tricky: the control layer generates 'control events' that the actuators should route back to the application.
Still a question: even if I create a mixin class, and transparently add the features I need to access its inner data, I need a reference of my class into the AOP layer, otherwise how do I enable it to consume events?
etienne -
3. Re: aop: one-way events ?
rmcdonough Aug 17, 2005 8:25 AM (in response to eti_antoniutti)I wrote an aspect recently that gives a POJO bound property support. I used an introduction+mixin to add the property change support to the POJO. A second aspect is used to monitor the fields of the POJO for any changes. If a change occurs, the aspect then fires a property change event to all registered listeners. I have a typo-ladden page up here:
http://www.damnhandy.com/?page_id=17
You can read more about it there. Without knowing anything inparticular about the POJO I'm advising, I'm able to be notified whenever a field value changes. I think what I'm doing here might be similar to what you are trying to do. Let me know if this helps any.This stuff is way cool!
Ryan-