incubator-imperius-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reza Asadollahi" <rasad...@uwaterloo.ca>
Subject RE: Autonomic Computing with Imperius
Date Mon, 12 May 2008 16:56:32 GMT
Hi,

Thank you very much for your response.

 

The solution for the 1st problem is reasonable, but I have some concerns
about the second one. 

 

In an autonomic computing environment, system attributes are monitored
periodically and some actions are executed as the result. In other words,
the policies are evaluated at different intervals (e.g. every second). So,
it would be so expensive and repetitive to parse/validate the policy for
every evaluation, and it degrades the system performance. 

 

Another approach could be just to check the policy syntactically at parsing
phase (not semantically) and assume that the referenced attributes and
methods exist at evaluation time (i.e. semantically is fine), and if the
mentioned attributes are not found at that time, an exception can be thrown.
So the only difference with the existing approach is that the developer gets
the exception at evaluation time rather than parsing time, and it is not a
big deal. 

 

However, we would like to participate in resolving these issues and please
let us know how we can contribute to the project.

 

Thanks again,

Best regards,

 

Reza

 

  _____  

From: Prashant B Baliga [mailto:prabalig@in.ibm.com] 
Sent: May 12, 2008 8:27 AM
To: Reza Asadollahi; imperius-dev@incubator.apache.org;
imperius-user@incubator.apache.org
Cc: David L Kaminsky
Subject: Fw: Autonomic Computing with Imperius

 


Hi, 
I propose adding a new method to the Java-SPL as below to extend the policy
infrastructure for dynamically generated classes/objects/beans. 

We could add a method that takes in the java object/bean and the policy
string. 
This method would use string manipulation to add the import statement which
it would get from the object. 
The parsing/validation and evaluation could become a single flow here to
accommodate dynamic evaluation. 

Let me know if you have any suggestions. 


Thanks & Regards,

Prashant Baliga

Autonomic Computing Policy Development, 
India Software Labs, IBM Software Group
Tivoli, IBM.

http://incubator.apache.org/imperius/ 
----- Forwarded by Prashant B Baliga/India/IBM on 05/12/2008 17:44 ----- 


Neeraj Joshi/Durham/IBM@IBMUS 

05/08/2008 18:30 


To

Prashant B Baliga/India/IBM@IBMIN 


cc

 


Subject

Re: Autonomic Computing with ImperiusLink
<Notes://d23ml170/652571910080569B/38D46BF5E8F08834852564B500129B2C/3959D6A5
61B9427A652574390041D355> 

 


 

 



My comments in red 
Sorry was on vacation hence the delay in replying 
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 




Prashant B Baliga/India/IBM@IBMIN 

04/29/2008 01:32 AM 


To

Neeraj Joshi/Durham/IBM@IBMUS 


cc

 


Subject

Re: Autonomic Computing with ImperiusLink
<Notes://D03NM118/87256CAF007435F0/38D46BF5E8F08834852564B500129B2C/FABA6323
36E67F3165257433004A8EB2> 

 


 

 



Hi Neeraj, 
My comments are in blue below. 



Thanks & Regards,

Prashant Baliga

Autonomic Computing Policy Development, 
India Software Labs, IBM Software Group
Tivoli, IBM.

http://incubator.apache.org/imperius/ 




Neeraj Joshi <jneeraj@us.ibm.com> 

04/22/2008 18:54 


Please respond to
imperius-dev@incubator.apache.org


To

"Reza Asadollahi" <rasadoll@uwaterloo.ca>,
imperius-dev@incubator.apache.org, imperius-user@incubator.apache.org 


cc

David L Kaminsky <dlk@us.ibm.com> 


Subject

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. 
Getters and Setters are not mandatory in Java. 
We would need some logic to see if the method exists etc. Is this how we
should implement it? 
We currently allow access to private variables through getters and setters
right? 
and it can be used outside the condition block. attr1=bean.getAttr1(); 

What we could do is first check if bean.attr1 is accessible (ie is public)
if not we can try doing 
getAttr1() that way we remain flexible

>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 could add a method that takes in the java object/bean and the policy
string. 
This method would use string manipulation to add the import statement which
it would get from the object. 
The parsing/validation and evaluation could become a single flow here to
accommodate dynamic evaluation. 

Yeah thats a good idea

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" <rasadoll@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







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message