Live distributed object: Difference between revisions

Revision as of 20:59, 1 March 2009

Revision as of 22:17, 1 March 2009

Line 3:

[[Image:Definition_of_a_Live_Distributed_Object.gif|right|thumbnail|300 px|An illustration of the basic concepts involved in the definition of a live distributed object.]]

The term ''live distributed object'' (also abbreviated as ''live object'') refers to a running instance of a [[distributed computing|distributed]] multi-party (or [[peer-to-peer]]) [[protocol (computing)|protocol]], viewed from the [[object-oriented programming|object-oriented]] perspective, as an entity that has a distinct [[identity (object-oriented programming)|identity]], andmay [[Encapsulation (computer science)|encapsulatesencapsulate]] state and internal threads of execution, and exhibits a well-defined externally visible behavior. The key object-oriented 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:. theThe 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 group|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).

The* software'''Proxies''' component('''replicas'''). instancesThe involved''proxy'' inor executinga the''replica'' of a live object's distributedis protocolone areof referredthe tosoftware ascomponent liveinstances distributedinvolved in executing the live object's ''proxies'', ordistributed ''replicas''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 [[remote procedure call|RPC]], [[Java remote method invocation|RMI]], or [[.Net Remoting|.NET remoting]] client-side proxy [[Method stub|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).

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 (computer science)|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.

* '''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 (computer science)|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.

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).

* '''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 [[serialization|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 (computer science)|reference]], a C/C++ [[Pointer (computing)|pointer]], or a [[web service]]'s [[Web Services Description Language|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.

== References ==

Line 22 ⟶ 25:

[[Category:Network protocols]]

[[Category:Distributed computing]]

[[Category:Object-oriented programming]]