Obliq: Network Scopes

Let us now look at a similar language, Obliq [], that is closer to supporting distributed shared memory. In Obliq, programs have network scopes, that is, scopes extending to multiple address spaces/hosts. An Obliq program starts of in some address space and can send portions of its code to other address spaces, much as an HTTP server sends applets to HTML browsers. The code, however, can be bound to variables at the original site, and these bindings are preserved when it executes at the remote site, that is, they become remote references to the values at the original site. As in Java, a distributed name space can be implemented through a registry - network scopes provide another, more convenient, mechanism for implementing suc spaces that use a registry only for bootstrapping purposes.

Also, as in Java, objects may be transmitted to a remote address space as parameters and return values of remote method invocations. Obliq distinguishes between immutable entities such as procedures and mutable entities such as objects. How an entity is sent to a remote address space depends on whether it mutable or immutable. If it is mutable, then a remote reference to it is sent; otherwise a ''copy'' of it is sent, which may contain remote references to the original site. Obliq constructs the copy of an object as follows: It determines the graph of nodes reachable from the object, creates copies of all the immutable nodes in the graph and the links to them (preserving cycles), and replaces local reference to mutable objects from the copied nodes with corresponding remote references. Obliq also allows a process to that a copy of a mutable object be sent.

To illustrate how Obliq may be used to create collaborative programs, and also the nature of higher-level collaboration infrastructures, consider Visual Obliq [], an Obliq library for creating a replicated collaborative application. Each replica of the application creates one or more top-level windows, called forms, for its user. Visual Obliq allows a user to interactively specify the appearance of forms and attach Obliq callback procedures to their fields.

The library generates Obliq form classes (with associated form constructors) that implement the form user-interfaces specified by the user, and also an Obliq session-constructor object for adding new users. In addition, for each form class, it creates a global session array that keeps track of the instances of the form created for different users. The application programmer can augment/modify/subclass the generated code.

Let us say we have created a helloWorld program using Visual Obliq. A user, at machine jeeves.cs.unc.edu, can create a new instance of this program by typing:

visobliq -run helloWord

A new Obliq process is created, containing all the global entities defined by the program such as the session constructor and the session arrays for the different forms. VisualObliq registers the session-constructor under the name "helloWorld" with a local registry. It also executes this constructor in the new process, which instantiates each form of the application by calling its form-constructor procedure, and adds references to each of these forms to its session array. Thus, this instance of the program is a ``server'', in that creates the global session data, and a ``client'', in that it creates local data to interacts with a user and refers to the global data.

Now another user, say at emsworth.cs.unc.edu can join this session by typing:

visobliq -join helloWorld@jeeves.cs.unc.edu

VisObliq creates a new client at the local site, retrieves a reference to the session-constructor from the registry at jeeves.cs.unc.edu and invokes the constructor. The session-constructor fetches copies of all the form-constructor procedures from the server, invokes them to create new instances of these forms, attaches local callback procedures to them, and adds (references to) these instances to the global session arrays stored in the server. Notice that the session arrays do not have to stored in a registry, they are automatically visible to the procedures copied from the server.

When a user enters information in a form, VisObliq invokes appropriate programmer-defined callbacks procedures attached to the form. A callback can update not only the local form instance but also the remote instances stored in the session arrays. For instance, in our example, when a user changes the local greeting, the callback can access access the references to the remote form instances replicas and update their greetings fields.

We have seen above how a replicated version of our example can be created using Obliq and VisualObliq.

It does not support centralized applications, but Obliq can be used directly to create such applications. A single copy of each application form would be stored in the master process, which would invoke remote methods in the I/O managers to update their displays.

Obliq can be used not only to create migrating applications or agents []. A migrating agent hops from site to site, collecting and processing information at each site. When it hops to a new site, it brings with it a suitcase containing information it has collected from the previous sites, receives a briefing from the new site, and executes a procedure parameterized by these two pieces of information. In fact, we can formally define the notion of hopping agents in Obliq []:

let rec agent =
    proc(suitcase, briefing)
        (* work at the current site *)
        ....
        hop (nextSite, agent, suitcase);
    end;

The hop procedure is implemented not as a language primitive but, in fact, using existing Obliq constructs:

let hop =
    proc (agentServer, agent, suitcase)
        agentServer (
            proc(briefing)
                fork(
                    proc()
                        agent(copy(suitcase), briefing);
                    end);
                ok
            end);
    end;

The hop procedure invokes the remote agentServer, passing it a procedure as an argument. Since a procedure is an immutable object, Obliq passes a copy of the procedure (and the agent procedure referenced by it) with a remote references to the local mutable suitcase object bound to it. On receiving this copy, the remote server executes it after passing it the local briefing. This procedure forks a new process, executes another procedure, while the parent process terminates and unblocks the caller. Meanwhile, the child process retrieves a copy of the suitcase and passes it, along with the briefing, to the copy of the agent procedure it received.

Migrating agents could be used for several purposes. They can be used to implement: POLITeam like workflow, taking a form to each user in the routing slip; computational mail, executing a program mailed to a user at the local site; and follow a user from site to site. If an agent is interactive, as in the examples above, it puts the user-interface state in the suitcase, and recreates it on the local display received as a briefing.

Currently Obliq does not support migration of multiuser agents since it does not maintain connectivity with distributed processes as the agent moves.