Live distributed object

An illustration of the basic concepts involved in the definition of a live distributed object.

Live distributed object (also abbreviated as live object) refers to a running instance of a distributed multi-party (or peer-to-peer) protocol, viewed from the object-oriented perspective, as an entity that has a distinct identity, may encapsulate internal state and threads of execution, and that exhibits a well-defined externally visible behavior. The key programming language concepts, as applied to live distributed objects, are defined as follows.

• Identity. The identity of a live distributed object is determined by the same factors that differentiate between instances of the same distributed protocol. The object consists of a group of software components physically executing on some set of physical machines and engaged in mutual communication, each executing the distributed protocol code with the same set of essential parameters, such as the name of a multicast group, the identifier of a publish-subscribe topic, the identity of a membership service, etc. Thus, for example, publish-subscribe channels and multicast groups are examples of live distributed objects: for each channel or group, there exists a single instance of a distributed protocol running among all computers sending, forwarding, or receiving the data published in the channel or multicast within the group. In this case, the object's identity is determined by the identifier of the channel or group, qualified with the identity of the distributed system that provides, controls, and manages the given channel or group. In the case of multicast, the identity of the system might be determined, for example, by the address of the membership service (the entity that manages the membership of the multicast group).

• Proxies (replicas). The proxy or a replica of a live object is one of the software component instances involved in executing the live object's distributed protocol. The object can thus be alternatively defined as a group of proxies engaged in communication, jointly maintaining some distributed state, and coordinating their operations. The term proxy stresses the fact that a single software component does not in itself constitute an object; rather, it serves as a gateway through which an application can gain access to a certain functionality or behavior that spans across a set of computers. In this sense, the concept of a live distributed object proxy generalizes the notion of a RPC, RMI, or .NET remoting client-side proxy stub.

• Behavior. The behavior of a live distributed object is characterized by the set of possible patterns of external interactions that its proxies can engage in with their local runtime environments. These interactions are modeled as exchanges of explicit events (messages).

• State. The state of a live distributed object is defined as the sum of all internal, local states of its proxies. By definition, it is distributed and replicated. The different replicas of the object's state may be strongly or only weakly consistent, depending on the protocol semantics: an instance of a consensus protocol will have the state of its replicas strongly consistent, whereas an instance of a leader election protocol will have a weakly consistent state. In this sense, the term live distributed object generalizes the concept of a replicated object; the latter is a specific type of live distributed object that uses a protocol such as Paxos, virtual synchrony, or state machine replication to achieve strong consistency between the internal states of its replicas. The state of a live distributed object should be understood as a dynamic notion: as a point (or consistent cut) in a stream of values, rather than as a particular value located in a given place at a given time. For example, the externally visible state of a leader election object would be defined as the identity of the currently elected leader. The identity is not stored at any particular location; rather, it materializes as a stream of messages of the form elected(x) concurrently produced by the proxies involved in executing this protocol, and concurrently consumed by instances of the application using this protocol, on different machines distributed across the network.

• Interfaces (endpoints). The interface of a live distributed object is defined by the types of interfaces exposed by its proxies; these may include event channels and various types of graphical user interfaces. Interfaces exposed by the proxies are referred to as the live distributed object's endpoints. The term endpoint instance refers to a single specific event channel or user interface exposed by a single specific proxy. To say that a live object exposes a certain endpoint means that each of its proxies exposes an instance of this endpoint to its local environment, and each of the endpoint instances carries events of the same types (or binds to the same type of a graphical display).

• References. The reference to a live object is a complete set of serialized, portable instructions for constructing its proxy. To dereference a reference means to locally parse and follow these instructions on a particular computer, to produce a running proxy of the live object. Defined this way, a live object reference plays the same role as a Java reference, a C/C++ pointer, or a web service's WSDL description; it contains a complete information sufficient to locate the given object and interact with it. Since live distributed objects may not reside in any particular place (but rather span across a dynamically changing set of computers), the information contained in a live distributed object's reference cannot be limited to just an address. If the object is identified by some sort of a gobally unique identifier (as might be the case for publish-subscribe topics or multicast groups), the reference must specify how this identifier is resolved, by recursively embedding a reference to the appropriate name resolution object.

• Types. The type of a live distributed object determines the patterns of external interactions with the object; it is determined by the types of endpoints and graphical user interfaces exposed by the object's proxies, and the patterns of events that may occur at the endpoints. The constraints that the object's type places on event patterns may span across the network. For example, type atomic multicast might specify that if an event of the form deliver(x) is generated by one proxy, a similar event must be eventually generated by all non-faulty proxies (proxies that run on computers that never crash, and that never cease to execute or are excluded from the protocol; the precise definition might vary). Much as it is the case for types in Java-like languages, there might exist many very different implementations of the same type. Thus, for example, behavior characteristic to atomic multicast might be exhibited by instances of distributed protocols such as virtual synchrony or Paxos.

The semantics and behavior of live distributed objects can be characterized in terms of distributed data flows; the set of messages or events that appear on the instances of a live object's endpoint forms a distributed data flow ^[1] .^[2]

History

Early ideas underlying the concept of a live distributed object have been influenced by a rich body of research on object-oriented environments, programming language embeddings, and protocol composition frameworks, dating back at least to the actor model developed in the early 1970s; a comprehensive discussion of the relevant prior work can be found in Krzysztof Ostrowski's Ph.D. dissertation.^[3]

The term live distributed object was first used informally in a series of presentations given in the fall of 2006 at an ICWS conference,^[4] STC conference,^[5] and at the MSR labs in Redmond, WA ,^[6] and then formally defined in 2007, in an IEEE Internet Computing article.^[7] Originally, the term was used to refer to the types of dynamic, interactive Web content that is not hosted on servers in data centers, but rather stored on the end-user's client computers, and internally powered by instances of reliable multicast protocols. The word live expressed the fact that the displayed information is dynamic, interactive, and represents current, fresh, live content that reflects recent updates made by the users (as opposed to static, read-only, and archival content that has been pre-assembled). The word distributed expressed the fact that the information is not hosted, stored at a server in a data center, but rather, it is replicated among the end-user computers, and updated in a peer-to-peer fashion through a stream of multicast messages that may be produced directly by the end-users consuming the content; a more comprehensive discussion of the live object concept in the context of Web development can be found in Krzysztof Ostrowski's Ph.D. dissertation.^[3]

The more general definition presented above has been first proposed in 2008, in a paper published at the ECOOP conference.^[8] The extension of the term has been motivated by the need to model live objects as compositions of other objects; in this sense, the concept has been inspired by Smalltalk, which pioneered the uniform perspective that everything is an object, and Jini, which pioneered the idea that services are objects. When applied to live distributed objects, the perspective dictates that their constituent parts, which includes instances of distributed multi-party protocols used internally to replicate state, should also be modeled as live distributed objects. The need for uniformity implies that the definition of a live distributed object must unify concepts such as live Web content, message streams, and instances of distributed multi-party protocols.

The first implementation of the live distributed object concept, as defined in the ECOOP paper,^[8] was the Live Distributed Objects ^[9] platform developed by Krzysztof Ostrowski at Cornell University. The platform provided a set of visual, drag and drop tools for composing hierarchical documents resembling web pages, and containing XML-serialized live object references. Visual content such as chat windows, shared desktops, and various sorts of mashups could be composed by dragging and dropping components representing user interfaces and protocol instances onto a design form, and connecting them together. Since the moment of its creation, a number of extension have been developed to embed live distributed objects in Microsoft Office documents,^[10] and to support various types of hosted content such as Google Maps.^[11] As of March 2009, the platform is being actively developed by its creators.^{[12] [13] [14] [15] [16] [17] [18]} <ref name=wadhwa2008"">Wadhwa, A., Sankar, H., and Subramaniyan, S. (2008). "Live Google Earth UI", http://liveobjects.cs.cornell.edu/community/7/index.html</ref>

References