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.

Key Concepts

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 globally 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
Ostrowski, K., Birman, K., Dolev, D., and Sakoda, C. (2009). "Implementing Reliable Event Streams in Large Systems via Distributed Data Flows and Recursive Delegation", ''3rd ACM International Conference on Distributed Event-Based Systems (DEBS 2009)'', Nashville, TN, USA, July 6–9, 2009, http://www.cs.cornell.edu/~krzys/krzys_debs2009.pdf
.Ostrowski, K., Birman, K., Dolev, D. (2009). "Programming Live Distributed Objects with Distributed Data Flows", Submitted to the ''International Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA 2009)'', http://www.cs.cornell.edu/~krzys/krzys_oopsla2009.pdf

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.

The term ''live distributed object'' was first used informally in a series of presentations given in the fall of 2006 at an ICWS conference,Ostrowski, K., and Birman, K., 'Extensible Web Services Architecture for Notification in Large-Scale Systems', IEEE International Conference on Web Services (ICWS 2006), Chicago, IL, September 2006, http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4032049.STC
conference,Ostrowski, K., and Birman, K., 'Scalable Group Communication System for Scalable Trust',
First ACM Workshop on Scalable Trusted Computing (ACM STC 2006), Fairfax, VA, November 2006, http://portal.acm.org/citation.cfm?id=1179477. and at the MSR labs in Redmond, WA
,Ostrowski, K., (2006). ''QuickSilver Scalable Multicast''. Microsoft Research, Redmond, WA, November 2006. http://www.researchchannel.org/prog/displayevent.aspx?rID=7870&fID=2276. and then formally defined in 2007, in an IEEE Internet Computing article.Ostrowski, K., Birman, K., and Dolev, D. (2007). "Live Distributed Objects: Enabling the Active Web", ''IEEE Internet Computing'', November–December 2007, 11(6):72-78, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4376216&arnumber=4376231. 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 i
Krzysztof Ostrowski
s Ph.D. dissertation.Ostrowski, K. (2008). "Live Distributed Objects", Ph.D. Dissertation, Cornell University, http://hdl.handle.net/1813/10881.

The more general definition presented above has been first proposed in 2008, in a paper published at the ECOOP conference.Ostrowski, K., Birman, K., Dolev, D., and Ahnn, J. (2008). "Programming with Live Distributed Objects", ''Proceedings of the 22nd European Conference on Object-Oriented Programming'', Paphos, Cyprus, July 07–11, 2008, J. Vitek, Ed., ''Lecture Notes in Computer Science'', vol. 5142, Springer-Verlag, Berlin, Heidelberg, 463-489, http://portal.acm.org/citation.cfm?id=1428508.1428536. 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, was the Live Distributed Objects platform developed b
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, and to support various types of hosted content such as Google Maps.http://liveobjects.cs.cornell.edu/community/index.html As of March 2009, the platform is being actively developed by its creators.Ostrowski, K., and Birman, K. (2009). "Storing and Accessing Live Mashup Content in the Cloud", ''3rd ACM SIGOPS International Workshop on Large Scale Distributed Systems and Middleware (LADIS 2009)'', Big Sky, MT, USA. October 11, 2009, http://www.cs.cornell.edu/~krzys/krzys_ladis2009.pdf
Akdogan, A., and Polepalli, S. (2008). "Live Maps", http://liveobjects.cs.cornell.edu/community/1/index.html
Kashyap, R., and Nagarajappa, D. (2008). "Cornell Yahoo! Live Objects", http://liveobjects.cs.cornell.edu/community/2/index.html
Dong, X., and Zhang, Z. (2008). "Integrate Live Objects with Flickr Web Service", http://liveobjects.cs.cornell.edu/community/3/index.html
Prateek, U. (2008). "Goole Earth Live Object", http://liveobjects.cs.cornell.edu/community/4/index.html
Gupta, S., and Vora, H. (2008). "ALGE (A Live Google Earth)", http://liveobjects.cs.cornell.edu/community/5/index.html
Mahajan, R., and Wakankar, S. (2008). "Distributed Google Earth", http://liveobjects.cs.cornell.edu/community/6/index.html
Wadhwa, A., Sankar, H., and Subramaniyan, S. (2008). "Live Google Earth UI", http://liveobjects.cs.cornell.edu/community/7/index.html

See also

* Active object

References

{{DEFAULTSORT:Live Distributed Object
Network protocols
Distributed computing architecture
Object (computer science)