Current MS Students/Gail Casburn
From CSWiki
Use of AOP in Distributed Control
Contents |
[edit] What I am planning to accomplish
In distributed computing, the need for dynamic software is a challenging task that can be addressed utilizing AOP. Aspect-Oriented Programming (AOP) allows the developer to dynamically modify the static Object-Oriented (OO) model. An AOP application adopts new characteristics as it develops, enables a dynamic modification to a static model to include the required code without having resort to the original code. Like classes, aspects have internal state and behavior, can extend other aspects and classes, and can implement interfaces. An aspect is just a plain Java class that has methods in it that define the behavior you want to attach to your object model. But, you can often keep this additional code in a single location rather than having to scatter it across the original model, as you will have to when using OO on its own.
The concept behind distributed computing is that a problem, which we could write a regular old function to compute, can be solved by many computers instead of one, with the idea being that the computers split up the process. However, there's a challenge to this, which is that you need to handle some annoying details in order to make the move from
for(i=0;i<max;i++)
{
doWork(i);
}
to a version that will be run efficiently by multiple nodes (computers). You need to worry about
- Information transmission (getting data from one node to another when they need the info).
- Task splitting (each node getting the code to run and figuring out what part of the work they are doing)
- Synchronization (making sure that the nodes don't step on each others' toes, and wait for the information they need to proceed)
This makes it far more difficult to write simple code to do the work, because in the course of modification snippets like the one above become monstrosities like the one below:
if(nodeid > 0) getDataSetFromNode(0);
for(i=nodeid;i<max/2;i+=nodecount)
{
doWork(i);
}
if(nodeid > 0)
{
passLeftsideInfoToNode(nodeid-1);
getLeftsideInfoFromNode(nodeid-1);
}
if(nodeid < (nodecount-1))
{
getRightsideInfoFromNode(nodeid+1);
passRightsideInfoToNode(nodeid+1);
}
for(i=nodeid+(max/2);i<max;i+=nodecount)
{
doWork(i);
}
if(nodeid > 0) passDataSetToNode(0);
All of this additional code stems simply from having to choose at runtime which nodes do what work, and stopping halfway into the process to pass information between adjacent nodes. Wouldn't it be better if you could just take the simple, starting code, and then say in a different place how to break up the work, how to pass around information, and so forth?
I believe that's what Aspects are for: separating information about how the code is to be used from the algorithms themselves. In theory - as this is the kind of thing for which AOP was created - all three of the distributed computing problems (information transmission, task splitting, and synchronization) should be solvable by the aspect, such that the parallel code is identical to the simple, linear code, and an equally simple aspect handles the how and by whom. It's modularity, it's separation of features, and it’s MVC all over again.
An AOP implementation that calls doWork( ) to handle synchronization issues might look like this:
public aspect HandleWork {
pointcut doWork( )
call (* WorkClass.do* (...) );
before( ) : doWork( ) {
// any
...doWork() is called: if this is node 0, pass information to the other nodes.
otherwise, get information from node 0.
}
around ( ) : doWork ( ) {
// any of the second half of doWork() is called:
...exchange data with the node on your left if such a node exists
//any of the second half of doWork() is called:
... exchange data with the node on your right if such a node exists
}
after ( ) : doWork ( ){
//but, before printing out the results:
... if this is node 0, get information from the other nodes. otherwise,
get information from node 0.
}
- Can Aspects handle the complexities of distributing a process as efficiently as inline code does?
- Does this create aspects that are just as convoluted as the original code, or can AOP manage this while still adhering to its guiding principle of "keeping things simple"?
[edit] Issues to be investigated
- Demonstrate AOP technologies in distributed systems in which the optimal solutions to sub-problems are in general held locally in autonomous components (agents). In such environments this information is treated as a local resource that needs to be located and fetched in order to obtain the global optimal solution. Consequently, an efficient AOP implementation would require the establishment of trade-offs between communication/brokering costs and the cost of maintaining multiple replicas of the same piece of information (the presence of redundant information in the system is on the one hand a waste of resources but, on the other hand, it helps reduce the communication overhead to locate it and convey it). I am going to study existing aggregation methods in distributed environments in connection with the definition of appropriate aspects.
- Investigate synchronization and security issues that deal with remote access of sensitive information: communication issues, component autonomy, information integrity, fault tolerance, etc.
- Provide examples and case studies starting from problems that have been approached successfully with traditional methods that apply to centralized environments.
[edit] Why this is academically interesting
[edit] Intended audience
My intended audience is the AOP research community
[edit] Why this is MS-level work
This thesis topic involves detailed research in an area that is relatively unknown to the computing world. This work will extend research in AOP and will provide a new techniques to control problems in distributed environments.
[edit] Previous work
[edit] Brief literature review
- Lesiecki, Nicholas. “Improve Modularity with Aspect-Oriented Programming.” developerWorks: The Rational Edge. 1 Jan 2002. eBlox, Inc. 31 Jan 2007. [1]
- Eaddy, Marc et al. “Debugging Aspect-Composed Programs.” New York: Columbia University, Draft conference submission for 14 Dec 2007. [2]
- Stoerzer, Maximilian et al. “Detecting Precedence-Related Advice Interference.” Jul 2006. University of Passau, Germany. 21 Feb 2007. [3]
- Ceccato, Tonella et al. "Is AOP easier or harder to test than OOP code?" 2005. http://star.itc.it/tonella/papers/wtaop2005.pdf]
This paper describes some of the technical issues that can arise when testing aspects. As aspects are not part of the base code, and they intercept the execution of that base code at given pointcuts which can modify or alter the behavior of the program, it can make testing more difficult. The adoption of traditional AOP testing methods produces more complex test cases. Aspects can regulate the execution order of statements, and hence, possibly violate the original intent of the program which may prevent it from working properly. These dynamic modifications can create unforeseen problems. The paper focuses on explaining the following categorization AOP fault types:- Incorrect strength in pointcuts
- Incorrect aspect precedence
- Failure to establish expected postconditions
- Failure to preserve state variants
- Incorrect focus of control flow
- Incorrect changes in control dependencies
- Incorrect changes in exceptional control flow
- Failures due to inter-type declarations
- Incorrect changes in polymorphic calls
- Charfi, Riveill et al. "Transparent and Dynamic Aspect Composition." 2006 [4]
- Engel, Freisleben. "Supporting Autonomic Computing Functionality via Dynamic Operating System Kernel Aspects". 2005. University of Marburg. [5]
[edit] Anticipated challenge(s)
[edit] Challenges
Challenges can be anticipated in incorporating aspects into Distributed Environments and Multiagent Systems that help detect, diagnose and repair failures in a complex system. Details of aspect-orientation will also need to be ironed out, such as, which AOP framework will be best to use.
[edit] Anticipated approach to each challenge
Reading and researching about the complexities of creating and monitoring a self-configuring system in a Distributed Computing Environment. Distributed Computing Environment (DCE) is an integrated distributed environment which incorporates technology from industry. The DCE is a set of integrated system services that provide an interoperable and flexible distributed environment with the primary goal of solving interoperability problems in heterogeneous, networked environments.
[edit] What I bring to this work
[edit] My relevant background and experience (CS 590)
Over the past several weeks, I have been researching AOP frameworks that provide an insight into aspects that can be applied to solve complex problems in need of self-configuration solutions. In addition, my Mathematical background provides an analytical forum for the dissection of programming problems.
[edit] What I find interesting about this work
I find this topic very interesting because it will extend my knowledge in an area of software development where little research has been done. I will have a chance to make a contribution to the AOSD research community.
[edit] How this work goes beyond my experience and course work
Since this is a relatively unknown area of research, there are very few quality papers published in the world pertaining to Aspect-Oriented Software Development (AOSD). In addition, very few research facilities and universities offer academic programs in the area of AOSD. Hence, this thesis topic goes beyond my previous course work because no courses were offered in this area.
