Service

There are many kinds of practical distributed applications: some are designed for scientific computation, which may produce a lot of temporary actors for parallel processing; some are developed for services, such as the web server, the web search engine, ... etc. Useless actors should be reclaimed for memory reuse, while service-oriented actors must remain available under any circumstance.

The most important reason for reclamation of useless actors is to avoid memory leakage. For example, by running the HelloWorld actor (shown in Section 3.5) in the world-wide computer, the world-wide computer must be able to reclaim this actor after it prints out "Hello World". Reclamation of actors is formally named actor garbage collection.

Reclamation of useless actors introduces a new problem: how to support non-collectable service-oriented actors in language level. This is important because a service-oriented actor cannot be reclaimed even if it is idle. For instance, a web service should always wait for requests. Reclamation of an idle service is wrong.

A service written by C or Java programming language uses loops to listen requests, preventing termination of it. A SALSA service should not use this approach because loops preclude an actor from executing messages. The way SALSA keeps a service actor alive is by specifying it in language level - a SALSA service actor must implement the interface ActorService to tell the actor garbage collector not to collect it.

The following example illustrates how a service actor is implemented and how message passing is used in SALSA. The example implements a simple address book. The AddressBook actor provides the functionality of creating new <name, email> entities, and responding to end users' requests. The example defines the AddUser behavior, which communicates with the AddressBook to add new entries in the database.

 
module examples;


import  java.util.Hashtable;
import  java.util.Enumeration;


behavior AddressBook implements ActorService{
  private Hashtable name2email;


AddressBook() {
   // Create a new hashtable to store name & email
   name2email = new Hashtable();
  }


// Add a new user to the system, returns success
  boolean addUser (String name, String email) {
    // Is the user already listed
    if (name2email.containsKey(name) || 
        name2email.contains(email)) {
      return false;
    }
    // Add to our hash table
    name2email.put(name, email);
    return true;
  }


void act(String args[]) {
    try{
      if (args.length != 0) {
        standardOutput<-println(
        "Usage:" +
        "java -Duan=<UAN> -Dual=<UAL> examples.AddressBook" );
        return;
      }
    } catch (Exception e) {
      standardOutput<-println("AddressBook at: ") @
      standardOutput<-println("uan: " + getUAN()) @
      standardOutput<-println("ual: " + getUAL());
    }
  }
}
 
   

The AddressBook actor is bound to the UAN and UAL pair. This will result in placing the AddressBook actor in the designated location and notifying the Naming server.

To be able to contact the AddressBook actor, a client actor first needs to get the remote reference of the service. The only way to get the reference is by the message handler getReferenceByName(). The example we are going to demonstrate is the AddUser actor, which communicates with the AddressBook actor to add new entries. Note that the AddUser actor can be started anywhere.

 
module examples;


behavior AddUser {
  void act(String args[]) {
    if (args.length != 3 ) {
      standardOutput<-println( 
      "Usage:" +
      "java examples.AddUser <targetUAN> <Name> <Email>" );
      return;
    }
    AddressBook book = 
      (AddressBook)AddressBook.getReferenceByName( 
        new UAN(args[0]) );
    book<-addUser(args[1], args[2]);
  }
}