Differences

This shows you the differences between two versions of the page.

--- at:tutorial:distribution [2009/01/29 15:10]
elisag revision
+++ at:tutorial:distribution [2009/01/29 22:10]
elisag *
@@ Line 19: / Line 19: @@
 </note>
-===== Exporting and discovering objects =====
+===== Exporting and Discovering Objects =====
 AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows:
@@ Line 116: / Line 116: @@
 A leased object reference is a remote far reference that grants access to a remote object for a limited period of time. When the time period has elapsed, the access to the remote object is terminated and the leased reference is said to //expire//. Similarly to remote far references, a leased reference abstracts client objects from the actual network connection state. Client objects can send a message to the remote object even if a leased references is disconnected at that time. Message are accumulated in order to be transmitted when the reference becomes reconnected. When the leased reference expires it, messages are discarded since an expired leased reference behaves as a //permanently// disconnected remote far reference. The figure below shows a diagram of the different states of a leased reference.
-{{ :at:tutorial:leasedref-state.png |:at:tutorial:leasedref-state.png}}
+{{ :at:tutorial:leasedref-state.png |:at:tutorial:leasedref-state.png?160x30}}
 ====Working with leased object references====
@@ Line 227: / Line 227: @@
 import /.at.lang.leasedrefs;
 </code>
-<note>
+<note warning>
 leasedrefs module exports support primitives to manipulate time intervals (i.e. ''minutes'', ''seconds'', ''millisecs'') so that you do not need to explicitly import the timer module. Remember to exclude those methods from the leasedrefs import statement if some other module has already imported them, e.g. if futures are enabled.
 </note>
-More information pertaining to the API of the leased references language module can be found in the appendix.
+More information pertaining to the API of the leased references language module can be found in the [[appendix|appendix]].
-===== Taking offline remote objects =====
+===== Taking Offline Remote Objects =====
-AmbientTalk distributed memory management scheme has been based on reference listing and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, which encapsulates a wire representation of the exported object and whose methods are stubs that transform local message sends into distributed message sends. Messages sent to the server include method invocation information, as well as the wire representation of the receiver. Each actor maintains an export object table which maps wire representations onto local references to exported objects. This table is used by the interpreter to resolve remote far references into local object references. Objects in the export table are considered as root objects for the local garbage collector. When an object is removed from the export table, it is no longer accessible remotely and, importantly, it no longer belongs to the set of root objects and as such, it becomes subject to garbage collection once it is no longer locally referenced.
+AmbientTalk distributed memory management scheme has been based on [[http://en.wikipedia.org/wiki/Reference_counting#Variants_of_reference_counting|reference listing]] and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, which encapsulates a wire representation of the exported object and whose methods are stubs that transform local message sends into distributed message sends. Messages sent to the server include method invocation information, as well as the wire representation of the receiver. Each actor maintains an export object table which maps wire representations onto local references to exported objects. This table is used by the interpreter to resolve remote far references into local object references. Objects in the export table are considered as root objects for the [[http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)|local garbage collector]]. When an object is removed from the export table, it is no longer accessible remotely and, importantly, it no longer belongs to the set of root objects and as such, it becomes subject to garbage collection once it is no longer locally referenced.
-As previously explained, in order to deal with volatile connections, remote far references tolerate network disconnections by default.  To enforce this, objects pointed by remote far references are not automatically taken offline when all their remote far references become disconnected, as traditionally happens in the above mentioned techniques. Rather, the object is kept in the export table since disconnected remote far references remain valid and still refer to the server object while disconnected. This implies a remote object is never reclaimed. AmbientTalk provides the takeOffline: primitive that takes a remote object offline, enabling the object to be eventually locally garbage collection.
+As previously explained, in order to deal with volatile connections, remote far references tolerate network disconnections by default.  To enforce this, objects pointed by remote far references are not automatically taken offline when all their remote far references become disconnected, as traditionally happens in the above mentioned techniques. Rather, the object is kept in the export table since disconnected remote far references remain valid and still refer to the server object while disconnected. This implies a remote object is never reclaimed. AmbientTalk provides the ''takeOffline:'' primitive that takes a remote object offline, enabling the object to be eventually locally garbage collection.
 <code>
@@ Line 243: / Line 243: @@
 </code>
-The primitive takes as parameter an object which is removed from the export table of the actor where the code is executed. When the object is removed from the export table, all remote far reference to the object become invalidated and the object no longer belongs to the set of root objects and as such, it can be eventually reclaimed by Java's local garbage collector once it is no longer locally referenced. Although the actual reclamation of an unexported object may be triggered at a later point in time, any attempt to access via a remote far reference results in an ObjectOffline exception notifying the client object that the object was taken offline and thus, the remote far references is invalid.
+The primitive takes as parameter an object which is removed from the export table of the actor where the code is executed. When the object is removed from the export table, all remote far reference to the object become invalidated and the object no longer belongs to the set of root objects and as such, it can be eventually reclaimed by Java's local garbage collector once it is no longer locally referenced. Although the actual reclamation of an unexported object may be triggered at a later point in time, any attempt to access via a remote far reference results in an ObjectOffline exception notifying the client object that the object was taken offline and thus, its remote far references is invalid.
-<note>
+<note tip>
-Leased object references make use of the takeOffline: primitive to terminate the access to a remote object once the lease time elapses. Note that the \atkeyword{takeOffline} primitive can be considered the equivalent to the so-called \texttt{delete} operation provided by some sequential languages without built-in local garbage collection.  Rather than using this primitive for garbage collection purposes, regular AmbientTalk developers are encouraged to use the high-level language constructs for leasing explained above which aids them to deal with both transient and permanent disconnections and properly reclaim their remote objects.
+[[distribution#dealing_with_permanent_failures|Leased object references]] make use of the ''takeOffline:'' primitive to terminate the access to a remote object once the lease time elapses. Note that the ''takeOffline'' primitive can be considered the equivalent to the so-called [[http://en.wikipedia.org/wiki/Manual_memory_management|''delete'' operation]] provided by some sequential languages without built-in local garbage collection.  Rather than using this primitive for garbage collection purposes, regular AmbientTalk developers are encouraged to make use of the high-level language constructs for leasing explained [[distribution#dealing_with_permanent_failures|in the previous section]] which aids them to deal with both transient and permanent disconnections and properly reclaim their remote objects.
 </note>
@@ Line 253: / Line 253: @@
 On the client side, taking offline an object results in a permanent disconnection of the remote far references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects.
-Clients can get notified when an object is taken offline by means of ''when:disconnected:'' observers. Disconnected observers get triggered since the taking offline event is considered as a logical disconnection between two devices. However, an object taken offline is removed from the export table and thus, it cannot go online anymore. As a result, the disconnected and reconnected observers will be no longer trigger for that remote far reference.
+Clients can get notified when an object is taken offline by means of ''when:disconnected:'' observers. Disconnected observers get triggered since the taking offline event is considered as a logical disconnection between two devices. However, once an object taken offline is removed from the export table, it cannot go online anymore. As a result, the disconnected and reconnected observers will be no longer trigger for that remote far reference.
 Additionally, AmbientTalk provides dedicated takenOffline observers which get triggered only once when the object is taken offline. They are installed similarly to when:disconnected observers as follows:
+<code>
 when: messenger takenOffline: {
   system.println("Buddy offline: " + name);
   //clean certain resources associated to the buddy
 };
+</code>
+The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified to the virtual machine. ''when:takenOffline'' observers can be considered as a special kind of ''when:disconnected'' observers which are triggered only in case of "logical" disconnection, but not in cases of network disconnections.
-The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified to the virtual machine. ''when:takenOffline'' can be considered as a special kind of ''when:disconnected'' observers which are triggered only in case of "logical" disconnection, but not in cases of network disconnections.
 <note>
@@ Line 269: / Line 270: @@
 </note>
-====Distributed unit testing and ''takeOffline''====
+====Distributed unit testing and takeOffline====
-As previously mentioned, the ''takeOffline'' primitive notifies connected virtual machines when taking an object offline. Since AmbientTalk 2.12, the primitive not only notifies remote virtual machines, but it also notifies the local virtual machine where the ''takeOffline'' was executed so that if any inner actor has local far references to that object, it will also get notified. In other words, if an object is taken offline, all actors holding far references to it (independent of their location) get notified.
+As previously mentioned, the ''takeOffline'' primitive notifies connected virtual machines when taking an object offline. Since AmbientTalk 2.12, the primitive not only notifies remote virtual machines, but it also notifies the local virtual machine where the ''takeOffline'' was executed so that if any inner actor has local far references to that object, it will also get notified. In other words, if an object is taken offline, all actors holding (local or remote) far references to it get notified.
-This semantics are useful for unit test purposes. The unit testing framework shipped with AmbinentTalk has support to perform asynchronous invocations which can be used to perform concurrent or distributed unit tests. However, distributed unit tests couldn't simulate network disconnections as ''network.offline'' works at actor level. In other words, ''network.offline'' simulates a disconnection of the complete virtual machine, but it cannot simulate the disconnection of a particular actor inside the VM. By means of ''takeOffline'' primitive, you can cut the access of an object contained in any actor (within the same VM or a remote VM),  enabling the simulation of the disconnection of an actor inside a virtual machine.
+These semantics is useful for unit test purposes. The [[appendix#unit_testing_framework|unit testing framework]] shipped with AmbientTalk has support for asynchronous test invocations which can be used to perform concurrent or distributed unit tests. In fact, distributed unit tests are simulated by means of concurrency, i.e. using different actors in your unit test which make use of the network facilities. However, distributed unit tests cannot simulate network disconnections by means of ''network.offline'' since the construct works at virtual machine level. In other words, ''network.offline'' simulates a network disconnection of a complete virtual machine, but what those tests need is to simulate the disconnection of a particular actor inside the virtual machine where they are running.
-<note>
+By means of the ''takeOffline'' primitive, the intra-actor access to an object can be cut (independently if the actor is located within the same virtual machine or in a remote one),  enabling the simulation of the disconnection of an actor inside a virtual machine.
-The complete implementation of the instant messenger application explained along this chapter can be found in the file ''at/demo/InstantMessenger.at''.
-</note>

Ambient-Oriented Programming

User Tools

Site Tools

Differences

Page Tools