OBLIQ (1742/obl001) |
 |
OO language for distributed objects
Lexically-scoped untyped interpreted language that supports distributed OO computation. An Obliq computation may involve multiple threads of control within an address space, multiple address spaces on a machine, heterogenous machines over a local network, and multiple networks over the internet. Obliq objects have state and are local to a site. Obliq computations can roam over the network, while maintaining network connections. Luca Cardelli, 1993.
Luca Cardelli, 1993. A distributed object-oriented scripting language. Small, statically scoped, untyped, higher order, and concurrent. State is local to an address space, while computation can migrate over the network. The distributed computation mechanism is based on Modula-3 network objects.
People:
Structures:
Related languages
| Modula-3 | => | OBLIQ | Adaptation of | |
| OBLIQ | => | Phantom | Extension of |
References:
Introduction
A simple guiding principle separates Obliq from other distributed procedural languages: adherence to lexical scoping in a distributed context. This principle has a number of interesting consequences: it supports a natural and consistent semantics of distributed computation, and enables elegant techniques for distributed programming. In lexically scoped languages, the binding location of every identifier is determined by simple analysis of the program text surrounding the identifier. Therefore, one can be sure of the meaning of program identifiers, and can much more easily reason about the behavior of programs.
In a distributed language like Obliq, lexical scoping assumes a further role. It ensures that computations have a precise meaning even when they migrate over the network a meaning that is determined by the binding location and network site of identifiers, and not by execution sites.
Network-wide scoping becomes an issue in the presence of higher-order distributed computation, for example when a site acting as a compute server accepts procedures for execution. The question here is: what happens to the free identifiers of network-transmitted procedures? Obliq takes the view that such identifiers are bound to their original locations, as prescribed by lexical scoping, even when these locations belong to different network sites.
In the rest of this introduction we review the main notions.
In section 2 we describe Obliq?s object model and distributed semantics. In section 3 we present a collection of distributed programming techniques, enabled by Obliq?s unique features. The most illuminating example is the compute server, in section 3.1; the most intriguing one is object migration, in section 3.5. The syntax is summarized in the appendix. Extract: Language Overview
Language Overview
The principal way of structuring distributed computations in Obliq is through the notion of objects. Network services normally accept a variety of messages; it is then natural to see each service as a network object (or, more neutrally, as a network interface). Obliq supports objects in this spirit, relying for its implementation on Modula- 3?s network objects [7].
The Obliq object primitives are designed to be simple and powerful, with a coherent relationship between their local and distributed semantics. Obliq objects are collections of named fields, with four basic operations: selection/ invocation, updating/overriding, cloning, and aliasing. There are no class hierarchies, nor complex method-lookup strategies. Every object is potentially and transparently a network object. An object may become accessible over the network either by the mediation of a name server, or simply by being used as the argument or result of a remote method.
In any framework where objects are distributed across sites, it is critical to decide what to do about mobility of state. To avoid problems with state duplication, objects in Obliq are local to a site and are never automatically moved over the network. In contrast, network references to objects can be transmitted from site to site without restrictions.
Atomic object migration can be coded from our primitives, specifically from cloning and aliasing. In addition to the distribution of data, the distribution of computations must also be designed carefully. It is clearly desirable to be able to transmit computing agents for remote execution. However, one should not be satisfied with transmitting just the program text of such agents. Program text cannot carry with it live connections to its originating site, nor to any data or service at any other site. Hence the process of transmitting program text over the network implies a complete network disconnect from the current distributed computation. In addition, unpredictable dynamic scoping results from transmitting and then running program text containing free identifiers.
Obliq computations, in the form of procedures or methods, can be freely transmitted over the network. Actual computations (closures, not source text) are transmitted; lexically scoped free identifiers retain their bindings to the originating sites. Through these free identifiers, migrating computations can maintain connections to objects and locations residing at various sites. Disconnected agents can be represented as procedures with no free identifiers; they do not rely on prolonged network connectivity.
In order to concentrate on distributed computation issues and to reduce complexity, Obliq is designed as an untyped language (lacking static typing). This decision leads to simpler and smaller language processors that can be easily embedded in applications. Moreover, untyped programs are somewhat easier to distribute, avoiding problems of compatibility of types at multiple sites.
The Obliq run-time, however, is strongly typed: erroneous computations produce clean errors that are correctly propagated across sites. The run-time data space is heterogeneous, meaning that there are different kinds of run-time values and no provisions to discriminate between them; heterogeneity discourages writing programs that would be difficult to typecheck in typed languages.
Because of heterogeneity and lexical scoping, Obliq is in principle suitable for static typing. More importantly, Obliq is compatible with the disciplined approach to programming that is inspired by statically typed languages. Extract: Distributed Semantics
Distributed Semantics
The Obliq distributed semantics is based on the notions of sites, locations, values, and threads. Sites (that is, address spaces) contain locations, and locations contain values. Each location belongs to a unique site. Sites are not explicit in the syntax but are implicit in the creation of locations: when a location is created during a computation, it is allocated at the current site.
Threads are virtual sequential instruction processors.
Multiple threads may be executed concurrently, both at the same site or at different sites. A given thread may stop executing at a site, and continue executing at another site. That is, threads may jump from site to site while retaining their conceptual identity.
In the Obliq syntax, constant identifiers denote values, while variable identifiers denote locations. A location containing a value may be updated by assignment to the variable denoting the location.
Obliq values include basic values (such as strings and integers), objects, arrays, and closures (the results of evaluating methods and procedures).
A value may contain embedded locations. An array value has embedded locations for its elements, which can be updated. An object value has embedded locations for its fields, which can be updated. A closure value may have embedded locations because of free variables in its program text that refer to locations in the surrounding lexical scope.
Values may be transmitted over the network. A value containing no embedded locations is copied on transmission. A value containing embedded locations is copied up to the point where those locations appear; local references to locations are replaced by network references. Because of transmission, a value may thus contain network references to locations at different sites. This semantics of value transmission has particular implications for closure values.
In general terms, a closure is a pair consisting of a piece of source text and a pointer to an evaluation stack. Transmission of a closure, in this view, implies transmission of an entire evaluation stack. Obliq, however, implements each closure as a pair of a source text and a table of values for free identifiers; this technique is well known and applicable to lexically-scoped higher-order languages. In our context, this implementation of closures has the effect of reducing network traffic by transmitting only the values from the evaluation stack that are needed by the closure. A closure that has been transmitted may thus contain program text that, when executed, accesses remote locations (via its table of free identifiers) over the network.
Every Obliq object consists of a collection of locations spanning a single site; hence the object itself is bound to a unique site, and does not move. This immobility of objects is not a strong limitation, because objects can be cloned to different sites, and because procedures can be transmitted that allocate objects at different sites. Hence, a collection of interacting objects can be dynamically allocated throughout the network. If migration is necessary, cloning can be used to provide the needed state duplication, and aliasing can be used to redirect operations to the clones.
We have stressed so far how Obliq computations can evolve into webs of network references. However, this is not necessarily the case. For example, a procedure with no free identifiers forms a completely self-contained computing agent. The execution of such an agent may be carried out autonomously by a remote compute server; the agent may dynamically reconnect to the originating site to report results. Intermediate situations are also possible, as with semi-autonomous agents that maintain low-traffic tethers to their originating site for status queries.
in [ACM SIGACT-SIGPLAN] Proc. of the 22nd Annual ACM Symposium on Principles of Programming Languages, San Francisco, January 1995. view details
in [ACM SIGACT-SIGPLAN] Proc. of the 22nd Annual ACM Symposium on Principles of Programming Languages, San Francisco, January 1995. view details
in Concurrency: Practice and Experience 2000 v12 view details
Resources