GHolo: a multiparadigm model oriented to development of grid systems

Future Generation Computer Systems 21 (2005) 227–237

GHolo: a multiparadigm model oriented to development of grid systems Jorge Luis Vict´oria Barbosaa,∗ , Cristiano Andr´e da Costaa , Adenauer Corrˆea Yaminb , Cl´audio Fernando Resin Geyerc a

Informatics Department, University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo, RS, Brazil b Informatics Department, Catholic University of Pelotas (UCPel), Pelotas, RS, Brazil c Informatics Institute, Federal University of Rio Grande do Sul (UFRGS), Porto Alegre, RS, Brazil Available online 30 October 2004

Abstract Multiparadigm approach integrates programming language paradigms. We propose Holoparadigm (Holo) as a multiparadigm model oriented to development of grid systems. Holo uses a logic blackboard (called history) to implement a coordination mechanism. The programs are organized in levels using abstract entities called beings. First, we describe the principal concepts of the Holoparadigm. After, the principles of a language based on the Holoparadigm are presented. Besides, we propose the Grid Holo (GHolo), a platform to support the multi-domain heterogeneous distributed computing of programs developed in Holo. GHolo is based on object mobility and blackboards. This distributed model can be fully implemented on Java platform. © 2004 Elsevier B.V. All rights reserved. Keywords: Multiparadigm; Mobility; Blackboard; Grid systems

1. Introduction Several programming language paradigms were developed to make computer programming more effective. There is no ideal solution since each one has advantages and disadvantages. Multiparadigm approaches mix two or more basic paradigms trying ∗

Corresponding author. E-mail addresses: [email protected] (J.L.V. Barbosa), [email protected] (C.A.d. Costa), [email protected] (A.C. Yamin), [email protected] (C.F.R. Geyer). 0167-739X/$ – see front matter © 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.future.2004.09.014

to get a more powerful and general solution and to overcome the specific limitations of each paradigm taking advantage of its most useful characteristics. Several multiparadigm languages and environments have been proposed as for example [3,12,18,20,23]. Each paradigm has sources of implicit parallelism, for example, AND parallelism and OR parallelism in logic programming [4,27]. Another example is object-oriented paradigm that allows the exploitation of inter-object parallelism and intra-object parallelism [9,21]. The multiparadigm approach integrates paradigms. So, it also integrates their parallelism sources. In this context, interest in automatic exploitation of parallelism in

228

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

multiparadigm software has emerged. The development of distributed software using multiparadigm models has received attention of the scientific community [9,13,14,21,25] with some systems considering mobility, heterogeneous hardware and cluster architectures. In this paper, we propose Holoparadigm (Holo) as a multiparadigm model oriented to development of grid systems. A logic blackboard (called history) implements the coordination mechanism and a new programming entity (called being) organizes the several encapsulated levels of beings and histories (multi-domains). A new multiparadigm language (Hololanguage) implements the main ideas introduced by Holoparadigm. Besides, we propose a platform to support the distributed execution of programs developed in Holo. This platform is called Grid Holo (GHolo). GHolo has a heterogeneous network as physical execution environment and is based on object mobility, blackboards and multi-domain organization (tree of beings). A prototype was implemented using Java [17] and special libraries to support mobility (Voyager [28]) and blackboards (Jada [10]). The paper is organized in six sections. Section 2 presents the Holoparadigm and the Hololanguage. In Section 3 is proposed the Grid Holo. Experimental results are presented and discussed in Section 4. Section 5 describes related works. Finally, Section 6 draws some conclusions and presents directions for future works.

2. Holoparadigm and Hololanguage Being is the main Holoparadigm abstraction. There are two kinds of beings: elementary being (atomic being without composition levels) and composed being (being composed by other beings). An elementary being (Fig. 1a) is organized in three parts: interface, behavior and history. The interface describes the possible interactions between beings. The behavior contains actions, which implement functionalities. The history is a shared storage space in a being. A composed being (Fig. 1b) has the same organization, but may be composed by others beings (component beings). Each being has its history. The history is encapsulated in the being. In composed being, the history is shared by component beings. Several levels of encapsulated history can possibly exist. A being uses the history in a specific composition level. For example, Fig. 1c shows two levels of encapsulated history in a being with three composition levels. Behavior and interface parts are omitted for simplicity. Automatic distribution is one of the main Holoparadigm goals. Fig. 2 exemplifies a possible distribution of the being presented in the Fig. 1b. Besides that, the figure presents the mobility in Holo. The being is distributed in two nodes of the distributed architecture. The history of a distributed being is called distributed history. This kind of history can be implemented using DSM techniques [24] or distributed shared spaces [2,10,11].

Fig. 1. Being organization.

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

229

Fig. 2. Distributed being and mobility.

Mobility [16] is the dislocation capacity of a being. In Holo, there are two kinds of mobility: logical mobility (being is moved when crosses one or more borders of beings) and physical mobility (dislocation between nodes of distributed architectures). Fig. 2 exemplifies two possible mobilities in the being initially presented in the Fig. 1b. After the dislocation, the moveable being is unable to contact the history of the source being (Fig. 2, mobility A). However, now the being is able to use the history of the destiny being. Here, physical mobility only occurs if the source and destiny beings are in different nodes of the distributed architecture (it is the case in our example). Logical and physical mobilities are independent. Occurrence of one does not imply in the occurrence of the other. For example, the mobility B in the Fig. 2 is a physical mobility without logical mobility. In this example, the moved being does not change its history view (supported by the blackboard). This kind of situation could happen if the execution environment aims to speedup execution through locality exploitation. The coordination model used in Holo is based on the blackboard architecture [22] (Fig. 3a). A blackboard is composed by a common data area (blackboard) shared by a collection of programming entities called knowledge sources (KSs). Control is implicit in the blackboard access operations. The read and write op-

erations in the blackboard are used to communication and synchronization between KSs. This kind of control is called implicit invocation. A composed being architecture is similar to the blackboard architecture, since several components share a common data area. In Holo, KSs are beings and the blackboard is the history. Since blackboard implicit invocation has several limitations, explicit invocation was introduced in the coordination model. Explicit invocation is any direct call between entities. So, the beings influence the others using the history, but can change information directly too. Fig. 3b shows the Holo coordination model. History is a logic blackboard, i.e., the information stored is a group of logic terms. Interaction with the history uses two kinds of Linda-like [8] operations: affirmation and question. An affirmation puts terms in the history, like asserts in Prolog databases. Moreover, a question permits to consult terms from the history. A consult does a search in the database using unification of terms. A question is blocking or non-blocking. A blocking question only returns when a unifying term is found. Therefore, blocking questions synchronize beings using the implicit invocation. In a non-blocking question, if a unifying term is not found, the question immediately fails. Besides that, a question is destructive or non-destructive. A destructive question retracts

230

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

Fig. 3. Holo coordination model.

the unifying term. The non-destructive one does not remove it. Hololanguage (so-called Holo) is a programming language that implements the concepts of Holoparadigm. A program is composed by descriptions of beings. The language supports logical mobility and concurrency between actions of a being. Besides that, the Hololanguage permits both kinds of blackboard interaction proposed by the Holoparadigm. Five kinds of actions are supported: (1) logic action (LA) is a logic predicate; (2) imperative action (IA) is a group of imperative commands; (3) modular logic action (MLA) contains several logic actions encapsulated in a module; (4) modular imperative action (MIA) encapsulates several imperative actions and (5) multiparadigm action (MA) integrates logic and imperative actions. Actions are composed using an Action Composition Graph (ACG). Following the Peter Wegner’s opinion [29] about the impossibility of mixing logic and imperative behaviors, we have created the Action Invocation Graph (AIG). This graph determines the possible order of action calls during a program execution. MAs, IAs and MIAs call any action. LAs and MLAs only call LAs and MLAs. Therefore, there are two regions of actions during an execution, namely, imperative and logic regions. If an execution flow goes in the logic region, the only way to return to the imperative region is finishing the flow (returning the results asked from the imperative region). This methodology eliminates many problems, which emerge when logic and imperative commands are mixed (for example, distributed backtracking [5]).

We believe AIG is an important contribution to the discussion presented by Wegner [29,30].

3. Grid Holo Holo to grid systems is called Grid Holo. The being multi-level organization (see Fig. 1c) is adequate to modelling heterogeneous multi-domain distributed systems. Holo was created to support implicit distribution, i.e., automatic exploitation of distribution using mechanisms provided by basic software (compiler and execution environment). Holoparadigm abstractions are hardware independent. However, the model is dedicated to distributed architectures. When the hardware is distributed, there are two main characteristics to be considered: (1) mobility support: it is necessary to implement the physical mobility treatment when there is a move to a being located in another node; (2) dynamic and hierarchical history support: distribution involves data sharing between beings in different nodes (distributed history). There are several levels of history (hierarchical history). Besides that, access history is adapted during the execution to support the mobility (dynamic history). GHolo is the software layer that supports the grid distributed computing of programs in Holo. It creates support to physical mobility and dynamic/hierarchical history in a grid. GHolo project is based on a structure called tree of beings (HoloTree, see Fig. 4). This structure is used to organize a being during its execution. The tree organizes the beings in levels. A being only can access the history of the composed being to which

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

231

Fig. 4. Grid Holo (distributed Holo Tree).

it belongs. This is equivalent to access the history of being localized in the superior level. A logical mobility is implemented moving a leaf (elementary being) or a tree branch (composed being) from the source being to the destiny being. The Jada spaces [10] are used to support the change of context. After the mobility, the being moved has direct access to the destiny being’s space. The Fig. 4 presents the GHolo architecture to the being initially shown in the Fig. 2. The figure shows the Holo Tree distributed in two nodes. The changes to both mobilities of Fig. 2 are demonstrated. Each being is implemented using an object and a Jada space (history). GHolo initialization involves the creation of a Voyager-enabled program [28] (Voyager environment) in each node that will be used. Since Voyager executes on the Java Virtual Machine each node will also have a running JVM. During the initialization, a Table Environment (TE) indicates the nodes that will be used by GHolo. During a program execution, if a logical mobility results in a physical mobility, it executes a moveTo operation in Voyager (mobility A, Figs. 2 and 4). When a physical mobility is realized without logical mobility (mobility B, Figs. 2 and 4), the tree of beings does not change, but a moveTo operation is realized. This kind of mobility does not have any kind of relation with the program. It is a decision of the environment to support

a specific functionality (load balancing, tolerance fault, etc.). GHolo does not support this kind of decision yet, but there is on going work in this subject [31].

4. Experimental results We have done a group of experiments using homogeneous and heterogeneous distributed architectures. In addition, we have used different software configurations to implement the support to Grid Holo. The experiments were done looking for the following goals: - evaluate the GHolo model. This goal involves the evaluation of logical and physical mobility control using the distributed tree. Besides that, it is important to evaluate the context change control using blackboards and - evaluate two different spaces technologies that can be used to implement the GHolo prototype, more specifically, Jada [10] and JavaSpaces [17]. Our experiments are based on a specific application: datamining. We have simulated three standard cases of datamining in a network environment: (A) Sequential datamining in one node (Fig. 5): one miner mines three databases (mines) in the same

232

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

Fig. 5. Sequential datamining in one node (case A).

node. The miner changes its level using mobility and goes in the first mine (mark 1). It mines the history using a specific number of read operations to space (mark 2). After that, the miner goes out of the mine (mark 3) and writes the data mining result (mark 4) in the history of the most general being (called Holo). This behavior is repeated to the others two mines; (B) Sequential datamining in three nodes (Fig. 6): one miner mines three mines localized in different nodes. The behavior is the same of the first situation. However, the two last mines are located in different nodes. This implies two important

points. First, when the miner goes in the second and third mines (mark 1), it is necessary to use physical mobility (moveTo command of Voyager). Second, when the miner writes the results of the second and third mining (mark 2), it is necessary to use remote method invocation (RMI). Both points result in costs that should be measured and (C) Parallel datamining in three nodes (Fig. 7): three miners mining in parallel three mines localized in different nodes. The situation is similar to the case B. The only difference is that there are three miners that work in parallel over mines. This solution

Fig. 6. Sequential datamining in three nodes (case B).

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

233

Fig. 7. Parallel datamining in three nodes (case C). Table 1 Nodes specification Node

Platforms 1 and 2

Platform 3

1 2

Sun SPARC station 20–128 M RAM Sun Ultra 10–128 M RAM

3

SunUltra 5–192 M RAM

Intel Pentium II 233 MHz–64 M RAM Intel Pentium II 233 MHz–64 M RAM Intel Pentium II 233 MHz–64 M RAM

involves the realization of two physical mobilities (mark 1) and two RMIs (mark 2). Holoparadigm is a generic model that can be used in any kind of distributed architecture. Following this idea, our experiments have used three different platforms (hardware and software): (1) Heterogeneus network and GHolo implemented using Jada and Voyager; (2) Heterogeneous network and GHolo implemented using JavaSpaces and Voyager and (3) Homogeneous network and GHolo implemented using Jada and Voyager.

Two first tables show the platforms configuration. Table 1 contains the nodes specification and Table 2 presents the software versions used. Table 3 contains the cost of one basic datamining operation at each node. Our basic operation is one tuple read (two fields, a string and an integer) from the mine space (for example, mark 2 in Fig. 5). In platforms 1 and 2, each node has a significant different cost because software and hardware are heterogeneous. Besides that, when JavaSpaces was used to implement the case C a meaningful performance lost has occured, comparing with the cases A and B. This fact results from the concurrent access to the JavaSpaces server during the parallel datamining. In the cases A and B the access is sequential. In platform 3, the cost of one read operation is similar in all nodes (homogeneous). The experiments showed that JavaSpaces is much slower than Jada when it is used to implement the GHolo architecture. For example, if we compare the cost to one read operation in the nodes 2 and 3, it is possible to determine that JavaSpaces was around 500 times slower than Jada. Based on this fact, we have chosen Jada to implement Grid Holo (see Section 3).

Table 2 Software Version Software

Platform 1

Platform 2

Platform 3

Operating system Voyager Java Jada Jini/JavaSpaces

SunOS Release 5.7 Version 3.3 Version 1.2 Version 3.0 beta 7 Not used

SunOS Release 5.7 Version 3.3 Version 1.2 Not used Version 1.1

Conectiva Linux v. 6.0 Voyager orb professional 4.0.1 Version 1.3.1 Version 3.0 beta 7 Not used

234

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

Table 3 Mining operation costs (ms) Operation

Node1

Node 2

Node 3

One read operation, platform 1 One read operation, platform 2, cases A and B One read operation, platform 2, case C One read operation, platform 3

0.129 32

0.032 17

0.040 20

42

37

39

0.039

0.036

0.037 Fig. 9. Datamining benchmarks—platform 2.

Table 4 Network costs (ms) Operation

Platform 1

Platform 2

One remote write One physical mobility

193 594

190 580

Platform 3 37 196

Table 4 presents the network costs involved in our experiment, i.e., remote write (for example, mark 2 in Figs. 6 and 7) and physical mobility (for example, mark 1 in Figs. 6 and 7). The costs in the platforms 1 and 2 were very similar. These platforms have used the same hardware and software. Each case was executed using five grains (number of mining operations) in each platform. In addition, in the platform 3 the test was extended with four grain sizes (from 10,000 to 25,000 mining operations). Using this extension, we are looking for the point where the case C (parallel execution) is better than the case A (sequential execution). Figs. 8–10 present graphics representing the results. The graphic in Fig. 10 is composed by two parts. The first represents the results with the same grain sizes of the other experiments. The second shows the grain sizes 5000, 10,000, 15,000, 20,000 and 25,000. A link shows the relation between the graphics. Considering the results, some interesting points can be underlined. Thinking in performance, the case C (parallel execution) is the best solution after around

Fig. 10. Datamining benchmarks—platform 3.

2500 operations in the platform 1 and after around 10,000 operations in the platform 3. In the platform 2, the case C was the best solution in all executions. These facts stimulate the parallelism exploitation. Besides, the case B overcomes the case A after around 3750 operations in the platform 1. This results from the fact that case A was executed in the node of smaller computational power (node 1, see Table 1). The network costs (see Table 4) were overcome by the use of more powerful nodes to work in the mines 2 and 3. Thinking in functionality, it is also important to say that almost all the times the mine distribution is related to data locality. Getting speedup is desired but not required.

5. Related works

Fig. 8. Datamining benchmarks—platform 1.

There are other multiparadigm implementations over distributed environment. I+ model [21] supports the distribution of objects, which implement methods using functions (functional classes) and predicates

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

(logic classes). The implementation is based on the translation of functional classes into Lazy ML (LML) modules and translation of logic classes into Prolog modules. The distributed architecture is a network of Unix workstations using 4.3 BSD sockets to implement message passing. The runtime environment was initially implemented using C language, Quintus Prolog and LML. In a second phase, programs were only translated into C language. I+ does not focus mobility. In addition, none kind of shared space is supported between objects. Ciampolini et al [9] have proposed DLO, a system to create distributed logic objects. This proposal is based on previous works (Shared Prolog [7], ESP [11] and ETA [2]). The implementation is based on the translation of DLO programs into clauses of a concurrent logic language called Rose [6]. The support to Rose execution is implemented on a MIMD distributed memory parallel architecture (transputer-based Meiko Computing Surface). The runtime environment consists of a parallel abstract machine that is an extension of the WAM [1]. This proposal does not support mobility and it is not applied on a network of workstations. DLO does not support levels of spaces. Oz multiparadigm language [20] is used to create a distributed platform called Mozart [25]. Oz uses a constraint store similar to a blackboard and supports the use of several paradigm styles [15,20]. Besides, Mozart has special support to mobility of objects [13] and distributed treatment of logic variables [14]. Mozart distributed architecture is a network of workstations providing standard protocols such as TCP/IP. The runtime environment is composed by four software layers [25]: Oz centralized engine (Oz virtual machine [19]), language graph layer (distributed algorithms to decide when to do a local operation or a network communication), memory management layer (shared communication space and distributed garbage collection) and reliable message layer (transfer of byte sequences between nodes). The physical mobility supported by Mozart is completely transparent, i.e., the system decides when to move an object. None kind of logical mobility is used. The shared space supported by Mozart is monotonic and stores constraints, while Holo being’s history is a non-monotonic logic blackboard that stores logic tuples (terms). In addition, Mozart does not provide levels of encapsulated contexts composed by objects accessing a shared space.

235

Tarau has proposed Jinni [26], a logic programming language that supports concurrency, mobility and distributed logic blackboards. Jinni is implemented using BinProlog [5] a multi-threaded Prolog system with ability to generate C/C++ code. Besides that, it has special support to Java, such as a translator allowing packaging of Jinni programs as Java classes. Jinni is not a multiparadigm platform. In addition, Jinni does not work with logical mobility and with levels of encapsulated blackboards. So, Oz and Jinni have a kind of mobility. In addition, they can be executed over network of workstations. However, we believe that the support to hierarchy of spaces as proposed by Holo is an innovation.

6. Conclusion We have proposed the use of Holo to multi-domain heterogeneous systems. Holoparadigm concepts estimulate the grid programming. Besides, we proposed the Grid Holo, namely, an environment to grid computing that automatically manages the tree of beings distribution. One important aspect of Holo is the coordination model, which simplifies the management of mobility. For this coordination, the Holo model uses a logic blackboard while GHolo proposes the use of spaces to implement it. Another important concept is the autonomous management of mobility. Holo model does not deal with physical distribution so mobility is always at logic level, i.e., between beings. GHolo execution environment can define what kind of mobility is necessary: a logical or a physical one. A logical mobility requires changes in history sharing, while physical also involves objects mobility. Our experiments have shown interesting results. Voyager, Jada and JavaSpaces can work cooperatively. Besides, parallel datamining has got good performance. In sequential datamining, a surprising result was that the heterogeneous characteristics of nodes have overcome the network costs in the platform 1. Significantly, it was proved that JavaSpaces is much slower than Jada when they are used to implement the GHolo architecture Future works will improve our proposal. One ongoing work [31] aims to propose a dynamic scheduling of distributed objects, which can be directly used in

236

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237

GHolo. Optimizations over initial execution kernel are also under development.

References [1] H. Ait-Kaci, Warren’s Abstract Machine—A Tutorial Reconstruction, MIT Press, 1991. [2] V. Ambriola, G.A. Cignoni, L. Semini, A proposal to merge multiple tuple spaces, object orientation and logic programming, Comput. Languages 22 (2–3) (1996) 79–93. [3] R. Apt, et al., Alma-0: an imperative language that supports declarative programming, ACM Trans. Programming Languages Syst. 20 (1998). [4] J.L.V. Barbosa, P.K. Vargas, C. Geyer, GRANLOG: an integrated granularity analysis model for parallel logic programming, in: Proceedings of the Workshop on Parallelism and Implementation Technology (constraint) Logic Programming, 2000. [5] K. Bosschere, P. Tarau, Blackboard-based extensions in Prolog, Software Pract. Experience 26 (1) (1996) 49–69. [6] A. Brogi, AND-parallelism without shared variables, in: Proceedings of the Seventh International Conference on Logic Programming, MIT Press, 1990, pp. 306–324. [7] A. Brogi, P. Ciancarini, The concurrent language, Shared Prolog, ACM Trans. Programming Languages Syst. 13 (1) (1991) 99–123. [8] N. Carriero, D. Gelernter, Linda in context, Commun. ACM 32 (4) (1989) 444–458. [9] A. Ciampolini, E. Lamma, C. Stefanelli, P. Mello, Distributed logic objects, Comput. Languages 22 (4) (1996) 237–258. [10] P. Ciancarini, D. Rossi, JADA: A Coordination Toolkit for Java, http://www.cs.unibo.it/∼rossi/jada, 2004. [11] P. Ciancarini, Distributed programming with logic tuple spaces, New Generating Comput. 12 (3) (1994) 251–283. [12] M. Hanus, The integration of functions into logic programming from theory to practice, J. Logic Programming 19–20 (1994) 583–628. [13] S. Haridi, et al., Programming languages for distributed applications, New Generating Comput. 16 (3) (1998) 223–261. [14] S. Haridi, et al., Efficient logic variables for distributed computing, ACM Trans. Programming Languages Syst. 21 (3) (1999) 569–626. [15] M. Henz, Objects in Oz, Ph.D. Thesis, Universit¨at des Saarlandes, 1997. [16] IEEE Trans. Software Eng., 24 (5) (1998) (special issue on mobility). [17] Java and JavaSpaces, http://www.sun.com, 2004. [18] J.H.M. Lee, P.K.C. Pun, Object logic integration: a multiparadigm design methodology and a programming language, Comput. Languages 23 (1) (1997) 25–42. [19] M. Meh, R. Scheidhauer, C. Schulte, An Abstract Machine for OZ, in: Proceedings of the Seventh International Symposium on Programming Languages, Implementations, Logics and Programs, Lecture Notes Computer Science, Springer, Berlin, 1995.

[20] M. Muller, T. Muller, P.V. Roy, Multiparadigm programming in Oz, in: Visions for the Future of Logic Programming: Laying the Foundations for a Modern Successor of Prolog, 1995. [21] K.W. Ng, C.K. Luk, I+: a multiparadigm language for objectoriented declarative programming, Comput. Languages 21 (2) (1995) 81–100. [22] H.P. Nii, Blackboard systems: the blackboard model of problem solving and the evolution of blackboard architectures, AI Mag. 7 (2) (1986) 38–53. [23] A. Pineda, M. Hermenegildo, O’CIAO: An Object Oriented Programming Model Using CIAO Prolog, Technical report CLIP 5/99.0, Facultad de Inform´atica, 1999. [24] Proc. IEEE, 87 (3) (1999) (special issue on distributed DSM). [25] P.V. Roy, et al., Mobile objects in distributed Oz, ACM Trans. Programming Languages Syst. 19 (5) (1997) 804–851. [26] P. Tarau, Jinni: intelligent mobile agent programming at the intersection of Java and Prolog, in: Proceedings of the PAAM’9, The Practical Applications Company, 1999. [27] P.K. Vargas, J.L.V. Barbosa, et al., Distributed OR Scheduling with Granularity Information, in: Proceedings of the XII Symposium on Computer Architecture and High Performance Computing, Brazil, 2000. [28] Voyager. http://www.recursionsw.com/voyager.htm, 2004. [29] P. Wegner, Tradeoffs between Reasoning and Modeling, in: G. Agha, P. Wegner, A. Yonezawa (Eds.), Research Direction in Concurrent Object-Oriented Programming, Mit Press, 1993, pp. 22–41. [30] P. Wegner, Why interaction is more powerful than algorithms, Commun. ACM 40 (5) (1997) 80–91. [31] A.C. amin, ExEHDA: execution environment for high distriubted applications, Ph.D. Thesis proposal, PPGC/UFRGS, 2001. Jorge Luis Vict´oria Barbosa received his BS degree in electrical engineering from the Catholic University of Pelotas, Brazil, in 1991. He obtained his MS and PhD degree in computer science from the Federal University of Rio Grande do Sul, Brazil in 1996 and 2002, respectively. Actually he is Professor at University of Vale do Rio dos Sinos, S˜ao Leopoldo, Brazil. His research interests include parallel and distributed computing, grid computing and programming languages. He is a member of the Brazilian Computer Society. Cristiano Andr´e da Costa received his BS degree in Computer Science from the Catholic University of Pelotas, Brazil, in 1994. He obtained his MS degree in computer science from the Federal University of Rio Grande do Sul, Brazil in 1997. Actually he is Professor at University of Vale do Rio dos Sinos, S˜ao Leopoldo, Brazil. Research interests include wide-area distributed computing, distributed objects systems, operating systems and Java. He is member of the Brazilian Computer Society.

J.L.V. Barbosa et al. / Future Generation Computer Systems 21 (2005) 227–237 Adenauer Corrˆea Yamin received his BS degree in electrical engineering from the Catholic University of Pelotas, Brazil, in 1981. He obtained his MS and PhD degree in computer science from the Federal University of Rio Grande do Sul, Brazil in 1994 and 2004, respectively. He is an associate Professor at the Catholic University of Pelotas in the Computer Science Department. His research interests include parallel and distributed computing, grid computing and execution environments for adaptive applications. He is member of the Brazilian Computer Society.

237

Cl´audio Fernando Resin Geyer received his BS degree in mechanical engineering, and his MS degree in computer science from the Federal University of Rio Grande do Sul, Brazil, in 1978 and 1986 respectively. He received his PhD degree in informatics from the Joseph Fourier University, France, in 1991. He is Associate Professor at Informatics Institute of Federal University of Rio Grande do Sul. His research interests include parallel and distributed computing, grid computing and Distributed Object Computing. He is a member of the Brazilian Computer Society and of the High Performance Regional Group of Rio Grande do Sul.