DOWL(ID:1724/dow002)Distributed OWL. B. Achauer, U Karlsruhe. An extension of Trellis supporting transparently distributed objects. Structures: Related languages
References: With the advent of workstations and efficient networks, distributed systems are becoming common, and these systems are inherently more complex to program than their centralized counterparts. The additional mechanisms introduced to access information on distant nodes are a major source of complexity. Within a single address space, procedure call is a well-understood mechanism for the transfer of both control and data. In contrast, messagebased systems require the programmer to deal with the details of message packaging, locating the message target, and asynchronous communication. Remote procedure call (RPC) [4] provides', the familiar procedure call abstraction and hides most of the details of control and data transfer. However, the programmer is still responsible for locating the target of the call. Other problems arise from subtle semantic differences between RPC and local procedure call and because RPC imposes a client/server model on the distributed application [16]. Recently, the object-oriented paradigm has attracted much interest because it achieves data abstraction, software modularity, and code reuse in a natural way. Operations on an object are invoked by sending messages to the object. Thus, communication among objects maps readily to the communication in a distributed system, and local and remote invocation are both syntactically and semantically identical. Since there is no distinction between local and remote objects, it is possible to move objects at run time between the nodes of the distributed system, thus allowing for dynamic load adaptation and reconfiguration. However, total transparency is not desirable: a few distribution-related features are required to take full advantage of distribution and to tune performance (e.g., to keep related objects close together to avoid remote invocation), but their use can be deferred to a late implementation (preinstallation) phase. Integrating distribution and objectoriented languages has attracted much attention in recent years. Some well-known systems offering both location-independent invocation and object migration are Emerald [5, 6, 10], Amber [7], and Distributed Smalltalk [2, 3, 8, 11]. Extract: Aims of DOWL As part of project DOCASE, we have designed and implemented Trellis/DOWL (short, DOWL), an extension of the Trellis language to support distribution. Its key features are: ? a distributed, object-oriented language ? upward compatibility to Trellis (at user code level) ? support for distributed, volatile objects ? transparent operation invocation on remote objects ? ability to move objects among the nodes of the distributed system ? linguistic support to describe location relationships between objects Extract: DOWL DOWL In Trellis, every object has its fixed place: it resides in a workspace which is contained entirely in the virtual address space of the single process running Trellis. In contrast, a DOWL workspace is shared among several processes possibly running on different physical nodes, and a DOWL object must live in the address space of one of these processes. For constant objects, this is not a problem: they do not change once they are created and can therefore be distributed by replication--moving a constant object simply creates a copy of the object on the target node. Mutable objects, however, can change during their lifetime and therefore cannot be replicated. Instead, a mutable object resides in exactly one address space, and a reference to a remote mutable object denotes a local proxy for the object Proxies behave exactly like the objects they represent: invoking an operation on a proxy is trapped by the run-time system and forwarded to the remote object. The operation is then performed at the object's actual location, and values returned or exceptions raised are transmitted back and delivered to the caller [1]. Normally, arguments given to operations on remoted objects are passed as proxies, and the operation returns a proxy for the result value to its caller. Ahernative value t:mnsmission mechanisms are available by using attachment attributes. Representing remote objects as proxies has some important consequences. In the first place, it preserves Trellis' semantics: several objects can share and exchange information by having a reference to the same mutable object. Second, operations on objects residing on the local node are more efficient than operations on remote objects since there is no overhead introduced by the run-time system or the network. Finally, operations on constant objects are even more efficient since these objects are guaranteed to be always resident, and there is no need to check whether an operation invocation has to be forwarded to the real object. in [ACM] CACM 36(09) (Sep 1993) view details in [ECOOP] ECOOP '93 Conference Proceedings, Kaiserslautern, Germany, July, 1993 view details in Concurrency: Practice and Experience 2000 v12 view details |