Differences

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

--- at:tutorial:distribution [2007/04/26 20:13] – elisag
+++ at:tutorial:distribution [2007/04/26 20:24] – elisag
@@ Line 1: / Line 1: @@
+<note>
+This tutorial is under heavy construction!
+</note>
 ====== Distributed Programming ======
-This section discusses how AmbientTalk virtual machines can discover and communicate with each other over the network.
+This tutorial chapter discusses how AmbientTalk virtual machines can discover and communicate with each other over the network.
-The integration of distribution was one of the main concerns in the design of AmbientTalk programming model. More specifically, as a distributed programming languages that adheres to the Ambient-Oriented Programming paradigm, AmbientTalk incorporates partial failures and discovery lookup facilities at the heart of its distributed programming model. Rather than creating stubs and skeletons to manage remote communications, AmbientTalk integrates them transparently to the developer thanks to its concurrency model based on actors and far references. Far references are in fact a vital feature of the distributed model of AmbientTalk that allows the language to be able to handle the so-called volatile connections featured in mobile ad hoc networks.  This section mainly explains the language abstractions to export and discover other remote objects, and handle partial failures. But first, let us start simply by showing how to enable the network functionality.
+The integration of distribution was one of the main concerns in the design of AmbientTalk programming model. More specifically, as a distributed programming languages that adheres to the Ambient-Oriented Programming paradigm, AmbientTalk incorporates partial failures and discovery lookup facilities at the heart of its distributed programming model. Rather than creating stubs and skeletons to manage remote communications, AmbientTalk integrates them transparently to the developer thanks to its concurrency model based on actors and far references. Far references are in fact a vital feature of the distributed model of AmbientTalk that allows the language to be able to handle the so-called volatile connections featured in mobile ad hoc networks.  This chapter mainly explains the language abstractions to export and discover other remote objects, and handle partial failures. But first, let us start simply by showing how to enable the network functionality.
 ===== Starting the Network.. =====
@@ Line 28: / Line 31: @@
 </code>
-When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a stripe. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a stripe, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following stripe:
+When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a [[actors#stripes|stripes]]. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a stripe, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following stripe:
 <code>
 defstripe ColorPrinter <: Printer;
@@ Line 49: / Line 52: @@
 </code>
-The code block to execute when the service type becomes available is parameterized with the actual remote reference to the discovered service object. In the example above, ''messenger'' is a remote reference to the remote object exporting the ''InstantMessenger'' service type. Imagine the interaction between the instant messenger applications executing the above code of two persons, e.g. Bart and Lisa. When the instant messenger of Bart and the instant messenger of Lisa come into one another's communication range, Bart will discover Lisa and Lisa will discover Bart via the ''InstantMessenger'' service type. Then, both will interchange their names and store it in their ''buddyList''.
+The code block to execute when the service type becomes available is parameterized with the actual remote reference to the discovered service object. In the example above, ''messenger'' is a remote reference to the remote object exporting the ''InstantMessenger'' service type. Imagine the interaction between the instant messenger applications executing the above code of two persons, e.g. //Bart// and //Lisa//. When //Bart's// instant messenger and //Lisa's// instant messenger  come into one another's communication range, //Bart// will discover //Lisa// and //Lisa// will discover //Bart// since both are exporting and also searching the ''InstantMessenger'' service type. Once discovered, both will interchange their names and store it in their ''buddyList''.
 <note>
 We are using a future to get the return value of the ''getName'' asynchrnonus message invocation. For further details about futures and the ''when:becomes:'' language construct, we refer the reader to the previous chapter on the [[actors|concurrency model of AmbientTalk]].