Differences

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

--- at:tutorial:distribution [2007/04/26 19:59] – created elisag
+++ at:tutorial:distribution [2007/04/26 20:13] – elisag
@@ Line 7: / Line 7: @@
 ===== Starting the Network.. =====
-AmbientTalk provides an unique native object, named ''network'',  that responds to two methods that control the network access to an AmbientTalk virtual machine. More specifically, ''network.online()'' and ''network.offline()'' make the interpreter go online and offline, respectively. When the interpreter goes online, this allows the built-in discovery lookup mechanism to export the local objects and let local objects to find other remote objects. AmbientTalk's discovery support will be further explained in the following section. Taking offline a virtual machine breaks immediately the connections with other virtual machines and thus, all remote reference between them are disconnected. This is a deliberate design choice made to facilitate the simulation of transient disconnections.
+AmbientTalk provides an unique native object, named ''network'',  that responds to two methods that control the network access to an AmbientTalk virtual machine. More specifically, ''network.online()'' and ''network.offline()'' make a virtual machine go online and offline, respectively.
+When the virtual machine goes online, this allows the built-in discovery lookup mechanism to export the local objects and let local objects to find other remote objects. AmbientTalk's discovery support will be further explained in the following section. Taking offline a virtual machine breaks immediately the connections with other virtual machines and thus, all remote reference between them are disconnected. This is a deliberate design choice made to facilitate the simulation of transient disconnections.
 <note>
@@ Line 47: / Line 49: @@
 </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''. 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 section on the concurrency model of AmbientTalk.
+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''.
+<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]].
+</note>
+The ''when:discovered:'' observers will be triggered only once when an ''InstantMessenger'' service type becomes available in the network. In order to be able to discover all other instant messenger buddies available in the network, the ''whenever:discovered:'' construct should be used. As ''when:discovered'', ''whenever:discovered'' takes a service type and a block of code that will be triggered when a remote object of a certain type becomes available in the network. However, the block of code specified in ''whenever:discovered'' can be fired multiple times upon discovering several exported objects.
-The observer installed with the ''when:discovered:'' construct will be triggered only once when an ''InstantMessenger'' service type becomes available in the network. In order to be able to discover all other instant messenger buddies available in the network, the ''whenever:discovered:'' construct should be used. As ''when:discovered'', ''whenever:discovered'' takes a service type and a block of code that will be triggered when a remote object of a certain type becomes available in the network. However, the block of code specified in ''whenever:discovered'' can be fired multiple times upon discovering several exported objects. As ''export:as'', both constructs returns a subscription object that responds to a ''cancel'' method that can be used to cancel the subscription so that the block of code is no longer invoked. Note that objects exported by an actor do not trigger the actor's own ''when'' nor ''whenever'' observers.
+As ''export:as'', both constructs returns a subscription object that responds to a ''cancel'' method that can be used to cancel the subscription so that the block of code is no longer invoked. Note that objects exported by an actor do not trigger the actor's own ''when:discovered:'' nor ''whenever:discovered:'' observers.
 ===== Partial Failure Handling =====
-Let us consider again the example instant messenger application described in previous subsection to further explain the semantics of AmbientTalk's remote object references and how they deal with transient disconnections. When an object discovers a service type, the ''when'' observers are triggered receiving as parameter a remote far reference to the remote object discovered. As explained in previous sections, far references operates asynchronously. When a client object sends a message via a remote reference, the message is buffered in the remote far reference and the client does not even wait for the message to be delivered. This is crucial in distributed computing in order to prevent race conditions. The parameter passing in the context of distribution works similar to the inter-actor message sending semantics:
+Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk's remote object references and how they deal with transient disconnections.
+When an object discovers a service type, the ''when'' observers are triggered receiving as parameter a remote far reference to the remote object discovered. As explained in previous sections, far references operates asynchronously. When a client object sends a message via a remote reference, the message is buffered in the remote far reference and the client does not even wait for the message to be delivered. This is crucial in distributed computing in order to prevent race conditions. The parameter passing in the context of distribution works similar to the inter-actor message sending semantics:
   - Objects are always passed by far reference, except for isolate objects which are passed by copy.
   - Native data types are always passed by copy.
 When a remote far reference receives a messages, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, messages are accumulate in its inbox in order to be transmitted once the reference becomes reconnected at a later point in time once the network connection is restored.