An Aspect-Oriented Programming Model for Bag-of-Tasks Grid Applications Marcio E. F. Maia1∗, Paulo H. M. Maia2, Nabor C. Mendonça3, Rossana M. C. Andrade1 1

Department of Computing Federal University of Ceará Fortaleza, Ceará, Brazil [email protected] [email protected]

2

Department of Computing Imperial College London London, U.K. [email protected]

Abstract This paper presents a novel programming model for explicitly separating parallelization and middlewarespecific concerns in Bag-of-Tasks (BoT) grid applications. The model uses Java threads for application decomposition, and aspect-oriented programming to dynamically (and transparently) convert the application’s thread objects into independent grid tasks, using the services of a specific grid middleware API. This paper also describes early experimental results showing the model’s modularity gains and performance overhead, when applied to implement BoT grid applications using OurGrid.

1. Introduction Grids are gaining popularity as a promising middleware platform for parallel computing [6]. Their open and distributed architecture allows easy sharing of a large number of (potentially heterogeneous) resources, offering a cost-effective alternative to multicore supercomputers [7]. Like any distributed application that relies on specific middleware services, grid applications must be implemented carefully, in order to avoid being dependent on any specific middleware API. Such dependency is undesirable because it makes it difficult to maintain the application, for instance, to cope with the evolution of the middleware API, or during migration to a different grid platform. On the other hand, separating middleware-specific concerns from decomposition concerns when implementing a grid application, using traditional grid platforms, is not a trivial task. This happens because the parallel programming model adopted by most grid ∗

3

Mestrado em Informática Aplicada, Universidade de Fortaleza Fortaleza, Ceará, Brazil [email protected]

platforms leads application developers to rely exclusively on the platform-provided grid programming abstractions (i.e., interfaces, classes, methods, etc) as the mechanisms for application decomposition. Consequently, decomposition and gridspecific concerns become tangled in the application source code, with the latter usually being scattered across several source code modules. As the application evolves, its source code becomes exceedingly more difficult to understand and maintain [16]. This paper presents a novel programming model for explicitly separating parallelization and middlewarespecific concerns in Bag-of-Tasks (BoT) grid applications. The model, called GridAspecting, uses Java threads as the mechanism for application decomposition, and AspectJ [2], an aspect-oriented extension of Java, to dynamically (and transparently) convert the application’s thread objects into independent grid tasks, using the services of a specific grid middleware API. The main benefit of the model is to completely encapsulate all grid-related code in aspects, thus improving the grid application’s modularity. In addition, the model fosters an incremental development approach, in which developers first implement and functionally test their application locally, using threads, thus avoiding the need to have a distributed grid environment available throughout the whole development process. An earlier version of the model was described in [10]. That first version served primarily as a proofof-concept realization of our ideas, and did not explore the full potential of AspectJ in terms of code reuse and extensibility. Compared to our previous work, this paper makes two contributions: (1) it presents an improved version of the model, which not only promotes code reuse but also reduces its required

Supported by CNPq/RHAE Scholarship process number 552190/2005-5.

programming effort; and (2) it describes preliminary experimental results showing the model’s modularity gains and performance overhead, when applied to implement BoT grid applications using the OurGrid grid computing middleware [5].

2. AOP and the GridAspecting Model A software system can be seen as a set of structured modules, each module representing a design concern, i.e., a system functionality or requirement. Current abstractions offered by the object-oriented paradigm (classes, objects, methods, and attributes) are insufficient to fully express all the concerns of a software system. For example, non-functional concerns such as logging, tracing, or data persistence tend to be scattered and tangled all across the classes of the system. These concerns are known as crosscutting concerns because they cut across other functionalities of the code. Consequently, pieces of software implemented with the object-oriented paradigm tend to have reduced comprehensibility, maintainability, and reusability [15]. Aspect-oriented programming (AOP) [9] arises as a solution to address problems related to crosscutting concerns and introduces a new abstraction, called aspect (which encapsulates typical AOP structures, i.e. joinpoints, pointcuts, advices and intertype declaraions), as well as a flexible mechanism to compose aspects with object-oriented components, such as classes, methods and attributes, in a variety of ways. Therefore, this new paradigm offers means to separate concerns and, consequently, to ensure better modularization. One of the first and most commonly used AOP languages is AspectJ [2], which, as we have mentioned previously, is a direct extension of the Java programming language. For a more in-depth discussion about AspectJ, and AOP in general, the reader can refer to [2]. GridAspecting consists of a set of implementation guidelines to assist grid application programmers, familiar with Java’s threads model, to develop middleware-independent BoT parallel applications through the use of AOP. The model emerged from our experience in applying AspectJ to separate gridspecific concerns in parallel Java applications from different problem domains [10]. The model encompasses four main steps, which are summarized below. The first step, named Tasks Identification and Separation of Grid Concerns, consists of identifying the pieces of code candidate for parallelization, which henceforth will be referred to as tasks, along with any explicit reference to the underlying grid middleware.

The model offers no guidelines to help in the identification of these concerns, which is left up to the programmer. In the second step, named Tasks Implementation, the programmer (re)implements the application’s tasks identified in step 1 as subclasses of Thread, allowing the application to be executed concurrently, regardless the presence of any grid platform. The run method of each Thread subclass will contain only the functional code identified for each task, without making any direct reference to the grid API. In the third step, named Tasks Execution and Coordination, the application tasks must be properly initialized and executed by instantiating objects of the task classes implemented in step 2, and by calling their start method. As required by the BoT parallelization model, once all tasks have started their execution, the main application must block and wait for their conclusion before proceeding to collect their results. To do this, the main application must call the join method of each task object that has been initialized, which suspends the application’s main thread until all tasks have finished their execution. The last step, Tasks Parallelization Using Aspects, consists in aspect-enabling the concurrent application, so that its task objects can be parallelized using a given grid middleware. To carry out this step, GridAspecting provides five programming constructs: one Java interface, GridTask, and four AspectJ aspects, namely GridTaskEnable, initialization, abstract execution and concrete execution. All Thread subclasses that represent task objects in the application source code must implement the GridTask interface, defining the initialization and execution aspects with application-independent joinpoints (which are well-defined points in the execution of an application). These joinpoints are expressed in terms of the GridTask interface start and join methods, instead of application-specific start and join methods from the Thread subclasses. Since making each application task class implement GridTask explicitly is itself a crosscutting concern, the model uses the GridTaskEnable aspect to apply this and other modifications to task class declarations implicitly. The GridTaskEnable aspect uses AspectJ’s intertype declaration constructs to change the application’s task class hierarchy, making each task class implement two interfaces: the model’s own GridTask and the Java API’s Serializable. The former is used to indicate which Thread subclasses actually implement grid tasks. The latter in turn is required for allowing serialization of task objects into separate files, so that they can be submitted to the grid for remote

execution. This aspect also introduces a main method to the task class declaration, which allows each task object to be executed remotely by the grid middleware. That main method is responsible for de-serializing the task object in the remote machine and then calling its run method. The abstract execution aspect generalizes code required in other aspects, such as declarations of instance variables, pointcuts (which are triggered when its specified joinpoints are matched), joinpoints and advices (which contain code to be executed when a certain joinpoint or pointcut is reached). The abstract execution aspect also defines three advices (see Figure 1): one for the start pointcut, of type around (lines 1-7), and two for the join pointcut, of types before (lines 9-12) and around (lines 14-16). The around advice defined for the start pointcut will replace the threads’ original start method, serializing the thread class to a file (line 5) and creating a task to be sent to the grid using the abstract method deployTask (line 6). The before advice defined for the join pointcut will intercept calls to the threads’ join method, before the method is executed, and, if the method is being called for the first time (line 9), it will send the serialized thread objects to the grid in a single job, using the abstract method sendJob (line 10), blocking the application until the job has finished its execution and the application can safely collect the job results back from the grid. Finally, the around advice defined for the join pointcut will replace the threads’ original join method, de-serializing the remote thread object (line 17) and calling copyProperties to copy all attributes of the remote object into the corresponding attributes of the application’s original thread object (line 18). The copyProperties method is implemented using Java’s reflection mechanism, which makes the 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:

aspect independent from any application-specific class type, method or internal attribute. The concrete execution aspect extends the abstract execution aspect just described. It provides the gridspecific implementation for the two abstract methods called by the abstract execution aspect: deployTask, which is responsible for preparing task objects to be sent to the grid, and sendJob, which will send all task objects of a job to the grid and then block until the job is done. Since these two methods are both applicationindependent, they only need to be implemented once for each new grid platform used. As we have mentioned before, GridAspecting requires that grid applications follow the BoT parallelization model (otherwise their concurrent tasks objects could not be executed in parallel as independent grid tasks). For this reason, the model defines very strict implementation rules which application programmers must strictly adhered to. The rules are as follows: (i) a task class must not define a main method, as this will be introduced later by the initialization aspect; (ii) a task object must not access any static variable of its own class or of any of its ancestors, since the tasks will be executed independently by the grid in potentially distributed machines; (iii) a task class must store its results in its own instance attributes or in a single external file, since those are the only means allowed for communication between the tasks submitted to the Grid and the main application; (iv) finally, a task object must not access any other external file unless its absolute path name has been specified as an invocation parameter to the object constructor.

void around(GridTask taskObject): start(taskObject){ idInput++; String inputFileNameTemp = inputFileName + thisAspectId + idInput + ".file"; String outputFileNameTemp = outputFileName + thisAspectId + idInput + ".file"; serializer.execute(taskObject,inputFileNameTemp); tasks.add(this.deployTask(inputFileNameTemp,outputFileNameTemp)); } void before(GridTask taskObject): join(taskObject){ if(!jobSent) { sendJob(tasks); jobSent = true; } } void around(GridTask taskObject ): join(taskObject){ idOutput++; outputFileNameTemp = outputFileName + thisAspectId + idOutput + ".file"; remoteObject = deserializer.execute(outputFileNameTemp); copyProperties(interceptedObject,remoteObject); }

Figure 1: Advices defined for the GridAspecting abstract aspect.

Figure 2: CDC and CDO metrics.

3. Model Evaluation We now present some experimental results from an initial evaluation of the GridAspecting model. It was carried out in two parts, covering two different perspectives. First, we computed four stringent software modularity metrics for two different, but functionally equivalent, versions of four parallel applications implemented using the OurGrid platform [5]: one to calculate all prime numbers between two given numbers; a parallel version of the MergeSort algorithm; and two data mining algorithms, Sprint [12] and Apriori [1]. These metrics quantitatively evaluate the modularity gains offered by GridAspecting, when compared to traditional objectoriented programming models. The second part of the evaluation compared the performance of the two versions of the parallel prime application (implemented with and without GridAspecting), using different input values and different grid configurations, appraising the performance overhead imposed by GridAspecting.

3.1 Modularity Evaluation The modularity of a software system expresses the strength of the relationships between its code elements, such as the coupling and cohesion levels between its classes and aspects. The modularity metrics used in the evaluation were taken from the AOP assessment framework proposed by Sant’Anna et al. [11]. They are: Separation of Concerns (SoC), Coupling, and Size. SoC is the ability to identify, encapsulate and manipulate parts of software that are relevant to a particular concern [15]. Considering only grid use concerns, the first SoC metric scrutinized was CDC (Concern Diffusion over Components), which measures

Figure 3: CDLoC and CBC metrics. the number of primary components (classes and aspects) that uses or implements a crosscutting concern. The second was CDO (Concern Diffusion over Operations), counting the number of operations that implement these concerns and the classes and aspects that use these operations. The last one, CDLoC (Concern Diffusion over Lines of Code), counts the number of shifts between the application implementation and the crosscutting concern, for instance, any grid specific piece of code. A coupling metric, CBC (Coupling between Components), computes the strength of the interconnections among the application components, counting the number of classes and aspects related to a given component. Size metrics included the number of lines of code, classes, methods and aspects. Figure 2 shows the results for both the CDC and CDO metrics. The green (lighter) bar represents the results for the object-oriented version, while the red (darker) bar represents the results for the GridAspecting versions. For both metrics, the GridAspecting shows smaller values than those of the OO version, which means that GridAspecting provides the best separation of grid concerns. Note that the differences are more significant for the Apriori and Sprint applications, since their implementation is more complex and involves a larger number of code components than the prime and MergeSort applications. Figure 3 shows the results for the CDLoC and CBC metrics. Due to the complete absence of grid-related code in the main application, all CDLoC values for the GridAspecting versions are equals to zero. The CBC values in turn show that GridAspecting also improves the coupling levels amongst application components, producing code that is likely to be more maintainable than the one produced using traditional OO techniques.

Figure 4. Execution time for 10 nodes

time calculated from three consecutive executions for each input value. Notice that the GridAspecting version shows only a slight performance loss. A second test was performed keeping the input value fixed at 50000 and varying the number of nodes to execute the same task to measure the execution time. Once again, the GridAspecting performance was similar to the OO implementation, as it is shown in Figure 5. Both tests indicate that the overhead introduced by the GridAspecting model is negligible. For instance, for a six node grid, the average execution time difference is 324ms. Observe that the performance curve increases after 6 nodes for both implementations, i.e., the distribution overhead is overcoming the benefits of parallelization.

4. Related Work

Figure 5. Input value of 50000 The yields for the Size metrics show that GridAspecting decreases the overall size of the application (in terms of lines of code and number of methods and classes or aspects). However, due to space restrictions, we do not present these metrics here.

3.2 Performance Evaluation In this evaluation we compared the execution time for both versions (developed with and without GridAspecting) of the prime algorithm. The tests consisted of measuring the execution time of each application, in milliseconds, using Ourgrid [5] as a dedicated underlying grid middleware. The grid machines were configured with Intel P4 3.2GHz processors and 1GB of RAM memory in a 100 mbps Ethernet network. The GridAspecting jar file size was 140 KB and the OO jar file was 50KB. The first test was performed in a grid with 10 nodes. The algorithm calculates the primes between 1 and a variable input value, which ranged from 10000 to 500000. Figure 4 shows two execution time curves. The numbers shown correspond to the mean execution

The use of aspect-oriented concepts to implement parallel applications has also been proposed in [14], [8] and [3]. Like our work, those models attempt to modularize parallelization concerns into aspects, so that they can be easily plugged into the application’s core functionality when necessary. However, the GridAspecting primary goal is to reduce the grid programming effort, adopting Java’s native threads model as the mechanism for application decomposition, since that model is more familiar to Java programmers. In [16], grid application development is proposed using special grid services provided as a reflexive middleware. In that model, a grid application would be written as a traditional sequential application, and it would be up to the reflection mechanism to automatically decompose the application and submit its decomposed parts to the grid. That work shares our aim of making grid use transparent to the application programmer. However, while it advocates using the reflection mechanism to completely hide decomposition concerns, we search for transparency in a more pragmatic way, by combining threads and AOP to explicitly separate decomposition concerns from grid use concerns. Finally, in [13], Soares et al. show how a distributed Java application, implemented using RMI, can be converted to a functionally equivalent application that can run locally, with the distribution code being encapsulated in aspects. A similar approach is described by Ceccato and Tonella in [4]. Those two works resemble GridAspecting in that both versions of the target application, i.e., with and without aspects, would also be functionally equivalent. Nevertheless,

while their work uses AOP to separate distribution concerns from the application code, our interest is to allow both concurrent and parallel executions of a Grid application, without exposing the underlying Grid API to the parallel application programmer.

5. Conclusions In this paper we presented GridAspecting, an aspectoriented implementation model for separating crosscutting grid concerns in bag-of-tasks grid applications written in Java. We also presented early quantitative results from a metrics- and performancebased evaluation of the model, when used to separate grid concerns in existing parallel Java applications. The evaluation showed that GridAspecting improves application modularity while imposing a negligible performance overhead. As future work, we plan to test GridAspecting using other grid platforms, and to conduct a more extensive evaluation of its performance impact. Another promising line of research would be to extend the model beyond the bag-of-tasks paradigm, allowing task objects to share variables and make remote method calls to each other. Also, a graphical user interface (GUI) tool could be created to automate the process of deploying grid tasks to a previously implemented grid middleware or to simplify application migration to a new grid platform.

7. References [1] Agrawal, R., Srikant R. Fast Algorithms for Mining Association Rules. In Proc. 20th Int. Conf. Very Large Data Bases (VLDB’94) (1994). [2] AspectJ. AspectJ Projetct Home Page. Available at http://eclipse.org/aspectj/. Accessed on 21/08/2006. [3] Broto, L., Bahsoun, J., Basmadjian, R. Sharing of Threads Variables on Grid Systems with Aspect-Oriented Programming. In Proc. of the 5th AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software (ACP4IS’06) (Bonn, Germany, March 2006). [4] Ceccato, M., Tonella, P. Adding Distribution to Existing Applications by means of Aspect Oriented Programming. In Proc. of the 4th IEEE Int. Workshop on Source Code Analysis and Manipulation (SCAM’04) (Chicago, IL, USA, Sep. 2004). IEEE Computer Society Press, pp. 107-116. [5] Cirne, W., Brasileiro, F., Andrade, N., Costa, L. Andrade, A., Novaes, R., Mowbray, M. Labs of the World, Unite!!!. Journal of Grid Computing, Vol. 4, No. 3, September 2006. [6] Foster, I., Kesselman, C., The Grid: Blueprint for a New Computing Infrastructure. Kaufmann Publishers, Orlando, FL, USA, 1999.

[7] Foster, I., Kesselman, C., Tuecke, S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of Supercomputer Applications, Vol. 15, No. 3, 2001. [8] Harbulot, B., Gurd, J. R. Using AspectJ to Separate Concerns in Parallel Scientific Java Code. In Proc. of the 3rd Int’l Conf. on Aspect-Oriented Software Development (AOSD’04) (Lancaster, UK, March 2004). [9] Kiczales, G. J., Mendhekar, L. A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J. Aspect-Oriented Programming. In Proc. of the 11th Eur. Conf. on Object-Oriented Programming (ECOOP’97), (Jyväskylä, Finnland, June 1997). Springer-Verlag, LNCS Vol. 1241, pp. 220-242. [10] Maia, P. H. M., Mendonça, N. C., Furtado, V., Cirne, W., Saikoski, K. A Process for Separation of Crosscutting Grid Concerns. In Proc. of the 21st Annual ACM Symposium on Applied Computing (SAC’06), Special Track on Programming for Separation of Concerns (Dijon, France, May 2006). ACM Press. [11] Sant'Anna, C., Garcia, A., Chavez, C., Lucena, C., von Staa, A. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. In Proc. o the XVII Brazilian Symposium on Software Engineering (SBES’03) (Manaus, AM, Brazil, Oct. 2003). [12] Shafer, C., Agrawal, R., Mehta, M. SPRINT: A Scalable Parallel Classifier for Data Mining. In Proc. of the 22nd Int'l Conf. on Very Large Databases (VLDB’96) (Mumbai, Bombay, India, Sep. 1996). [13] Soares, S., Laureano, E., Borba, P. Implementing Distribution and Persistence Aspects with AspectJ. In Proc. of the 17th Annual ACM Conf. on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA’02) (Seattle, Washington, USA, Nov. 2002). [14] Sobral, J. L. Incrementally Developing Parallel Applications with AspectJ. In Proc. of the IEEE Int’l Parallel & Distributed Processing Symposium (IPDPS’06) (Rodhes, Greece, April 2006). [15] Tarr, P., Ossher, H., Harrison, W., Sutton, Jr., S. M. N Degrees of Separation: Multi-dimensional Separation of Concerns. In Proc. of the 21st Int’l Conf. on Software Engineering (ICSE’99) (Los Angeles, CA, USA, May 1999). ACM Press, pp. 107-119. [16] Tramontana, E., Welch, I. Reflections on Programming with Grid Toolkits. In Proc. of the ECOOP’04 Workshop on Reflection, AOP and Meta-Data for Software Evolution (RAM-SE’04) (Oslo, Norway, June 2004).