|
|
An Actor-Based Approach to World-Wide ComputingCarlos A. Varela
|
We define several actor-based abstractions (casts, directors, messengers) to effectively harness the power of the World Wide Web as a global computing infrastructure. Groups of actors, or "casts", represent an abstraction unit for naming, synchronization, migration and load balancing. Each cast contains a "director" and inter-cast communication is performed via special actors named "messengers".
Recent advances in networking have made it possible to think of a "World-Wide Computer" [Berners-Lee 97], which uses the present international infrastructure of computers connected by the Web [Berners-Lee et al. 94] as a global computing platform. One key component is the Java programming language [Gosling et al. 96] and its ability to execute remote code safely and in a platform-independent manner. This has been accomplished with a sandbox security model and the definition of a Java Virtual Machine. Java has also provided new important high-level APIs for remote method invocation, object serialization and reflection [JavaSoft 97].
Even though all these facilities make it a very promising technology to accomplish world-wide computing; its main drawback is at its very heart: the Java passive object model. Java objects have several inherent problems for open distributed computing [Varela and Agha 98]:
In the remainder of this article, we describe our approach to solve these problems, expected results, and our work's current status.
The actor model of computation [Hewitt 77, Agha 85] improves on the sequential limitations of passive objects. Each actor encapsulates its state as well as its own thread of computation. Communication between actors is exclusively limited to message passing. Actors react to new messages by creating new actors, modifying their own state, or sending new messages to acquaintances. Incoming messages are buffered internally in a mailbox and dispatched sequentially.
An actor sends a message and proceeds with its local computation immediately, thereby allowing for maximum concurrency. Because only one message is processed at a given time, there are no safety problems. Not having a shared memory implies that there is no need for locks or monitors which may produce deadlocks. Thus, the actor model provides an ideal infrastructure for distributed computing.
We have extended the actor model to incorporate actor groups, or
casts, coordinated by directors. These
casts are meant to be
abstraction units for naming, synchronization, migration and load
balancing. Actors within a cast communicate via asynchronous
passive messages, with guaranteed message delivery. Actors across
different casts may communicate via asynchronous active messages, or
messengers.
Different meta-level architectures have been created to implement grouping and multi-actor synchronization concepts such as ActorSpaces and Synchronizers [Callsen and Agha 94, Frølund 96]. Even though these are valid implementation approaches, we believe that they complicate needlessly the semantics of actor-based programs. Correctness of a particular application not only depends on actor semantics, but also on the run-time implementation of the meta-level architecture.
Our approach is different in the sense that our abstractions are themselves based on actors. There is no requirement for more powerful meta-level actors to intercept base-level actor messages. Nor is there a requirement for a particular run-time system implementing the proposed meta-level architectures.
The director of a cast of actors plays a special role (coordination of internal actors, interface to external casts, request broker for the cast's provided service, etc) but it has no more power than any of the other actors in the cast. The director communicates via asynchronous messages, and to the run-time system, it is just another actor.
Likewise, a messenger is an actor with a very specific purpose: inter-cast communication. Because casts have different naming spaces and they will usually be in different physical locations, a messenger handles naming and networking issues, and it can migrate following the target actor and guaranteeing message delivery or return. The sender should provide methods for handling the exception that may occur should a messenger not be able to deliver its message.
One important goal of this dissertation is to identify the issues required for effectively using the resources of the Web as a global computing infrastructure. We'd like to fully take advantage of the Actor model of concurrent computation for distributed systems and extend it as necessary to accomplish the goal of ubiquitous worldwide computation.
By grouping actors in casts as a unit for high-level synchronization, migration and composition; we expect to provide a framework that will allow distributed software developers to analize, design and code their programs in a modular and intuitive fashion. We'd like to make the best possible use of Java and to keep the same level of reusability that object-oriented programming languages currently provide with inheritance and polymorphism.
One potential way to implement these ideas is to provide linguistic support via a new programming language (SALSA: Simple Actor Language: System and Applications). This language could embody the higher-level mechanisms for actor interaction. SALSA applications could then be compiled into Java bytecode to leverage the current investment in Java virtual machine implementations and safe remote code execution in the World Wide Web.
We have carefully studied the latest theoretical and practical developments of the Actor model of computation. Additionally, we have studied the technologies underlying the World Wide Web and Java.
We have defined casts as groupings of actors to serve as units for naming, synchronization and migration in worldwide distributed systems. We have also defined directors and messengers as special-purpose actors for intra-cast and inter-cast communications.
In 1996, the author developed an HTTP server in Java to test its support for sockets and its multi-platform compatibility. In the last year, he has given talks to his Actor research group about concurrency support, remote method invocation (RMI), and reflection in Java. This year, the author has presented a doctoral symposium paper at the Seventh International WWW Conference [Varela and Agha 98].
In the next year, we plan to create a working prototype of SALSA, a programming language containing the ideas presented above. We plan to develop a SALSA compiler that creates Java bytecode. One possible sample application is a chess program that should employ multiple Internet computers to produce its moves. We currently have a one-host chess playing program as a working prototype. We'd like to compare its performance to the program running in multiple configurations of Internet hosts.