You are viewing a plain text version of this content. The canonical link for it is here.
Posted to imperius-dev@incubator.apache.org by Neeraj Joshi <jn...@us.ibm.com> on 2008/04/22 13:24:21 UTC
Re: Autonomic Computing with Imperius
Hi Reza,
Thank you for your interest in trying out SPL your comments are greatly
appreciated.
> For example bean.attr1 should be translated internally to
bean.getAttr1().
I think this is a good idea and do not think it will be very hard to
implement.
>anchor classes are kind of dynamically generated classes, and I can not
specify their class names
This one is a bit tricky because a policy has a 2 phase life-cycle in
phase 1 the policy is validated syntatically and semantically and an
*executable* is generated and cached.
In phase 2 the policy is evaluated using the input parameters.
Not knowing the class name in phase 1 will naturally be a problem so we
would have to be able to support a way to evaluate on the fly...this may
require some fundamental changes.
We are always looking for folks to participate in our project so if you
have the cycles you could just provide us with a patch for #1 and I can
check it in.
I have cc'ed this email to the community for others to comment
Thanks!
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The light at the end of the tunnel...may be you"
Neeraj Joshi
WebSphere XD - Compute Grid
AIM, IBM
Apache Imperius - http://incubator.apache.org/imperius
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Reza Asadollahi" <ra...@uwaterloo.ca>
04/21/2008 04:07 PM
To
David L Kaminsky/Raleigh/IBM@IBMUS, Neeraj Joshi/Durham/IBM@IBMUS
cc
Subject
Autonomic Computing with Imperius
Hi,
I am doing research in the area of autonomic computing in the University
of Waterloo Canada. As part of my research, I was intending to develop an
implementation of CIM-SPL, and hopefully, I found that you did it. Thank
you so much. You did a great job, and I guess Imperius can be the leader
of policy engines in this area.
I used the current version of Imperius in my project and I found a few
limitations in the application. I would like to share them with you and
get your suggestions about them.
1. A policy can not access the anchor class private attributes via
their getter and setter methods, and the attributes should be defined
“public” instead. Yes, I found that it is possible to call a getter method
in the “condition” section but it is more interesting to read and write
attributes in an expression-like language. For example bean.attr1 should
be translated internally to bean.getAttr1(). The idea of Java EE
Expression Language in terms of using high-level expressions instead of
java-like code could be helpful in this context as well.
2. The objects that I pass to the policies as anchor classes are
kind of dynamically generated classes, and I can not specify their class
names in the policy file (they don’t extend a specific super class or
interface). Hence, it is not possible to work with the anchor objects in
the policies as sensors and effectors. For example, I have a
dynamically-generated java bean and I know that it would have have an
attribute named “attr1”, but I don’t know its class (and it is not
important at all); however, I would like to able to use that java bean in
the policy. To overcome this problem, I guess it would be enough for
Imperius to work with the passed java beans by reflection.
I believe that addressing the mentioned concerns in Imperius will
significantly improve its feature set and facilitate its usage in
different adaptation environments.
I would like to thank you for your attention to my points, and I am
looking forward to hearing from you soon.
Best Regards,
Reza Asadollahi