Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:tutorial:distribution

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
at:tutorial:distribution [2007/05/04 08:32] – * elisagat:tutorial:distribution [2007/05/04 09:06] – * elisag
Line 69: Line 69:
 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.  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:+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 semantics for messages sent to remote objects 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.   - Objects are always passed by far reference, except for isolate objects which are passed by copy.
Line 93: Line 93:
 This code illustrate how the instant messenger application notifies when a buddy goes online or offline. In the above code, ''messenger'' is a remote reference to another remote buddy discovered. Note that installing disconnected observers also allows developers to clean certain resources when a remote reference becomes disconnected. However, when an instant messengers disconnects, the remote object referred to by ''messenger'' remains exported. This implies that remote objects remains pointed by a disconnected remote reference which prevents them from being garbage collected. In fact, ''messenger'' are never garbage unlesss explicit cancelation of the subscription. But other types of objects which are only relevant within the context of an interaction should become eventually candidates for garbage collection. In the next section, we detail how AmbientTalk deals with distributed memory management.  This code illustrate how the instant messenger application notifies when a buddy goes online or offline. In the above code, ''messenger'' is a remote reference to another remote buddy discovered. Note that installing disconnected observers also allows developers to clean certain resources when a remote reference becomes disconnected. However, when an instant messengers disconnects, the remote object referred to by ''messenger'' remains exported. This implies that remote objects remains pointed by a disconnected remote reference which prevents them from being garbage collected. In fact, ''messenger'' are never garbage unlesss explicit cancelation of the subscription. But other types of objects which are only relevant within the context of an interaction should become eventually candidates for garbage collection. In the next section, we detail how AmbientTalk deals with distributed memory management. 
  
 +In other to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the far reference outbox by means of the ''retract'' language construct. This is specially useful in the context of distribution, since developers can have explicit control on the messages that are buffered but have not been sent while the remote far reference is disconnected. Any undelivered messages accumulated by the remote reference can be then for example forwarded to another remote object or simply cancelled. 
 +
 +The ''retract'' language construct takes as argument the far reference of which to retract outgoing message send. One can store the unsent messages upon disconnection of a service type ''Service'' as follows:
 +
 +<code>
 +when: Service discovered: { | reference |
 +    when: reference disconnected: {
 +         messages := retract: reference;
 +    }
 +}
 +</code>
 +
 +The construct returns a table containing copies of all messenges that were sent to this far reference, but not yet transmitted by the far reference to the remote object pointed to. Note that this has the side effect that the returned messages will not be sent automatically anymore; the programmer is thus responsible to explicitly resend all messages that were retracted but still need to be sent. 
  
 ===== Garbage collecting remote references ===== ===== Garbage collecting remote references =====
Line 105: Line 118:
  
 <note> <note>
-As you may have noticed, the ''takeOffline'' language construct is reminiscent to the so-called ''delete'' operation provided by some languages without built-in local garbage collection. It is indeed a design decision providing the minimal set of language constructs for distributed memory management. Rather than defining one specific distributed garbage collector directly in the interpreter, we have opted to enable the experimentation of distributed garbage collection techniques from within AmbientTalk itself. Thanks to AmbientTalk reflective infrastructure, it has been possible to build more sophisticated distributed garbage collection techniques to avoid the extra burden that takeOffline places on developers. More specifically, AmbientTalk integrates leasing techniques with the notion of a remote object reference, and provides the resulting ''leased object references''. The system library shipped with AmbientTalk contains a reflective implementation of leased object references together with a set of language constructs to manipulate them.+As you may have noticed, the ''takeOffline'' language construct is reminiscent to the so-called //delete// operation provided by some languages without built-in local garbage collection. It is indeed a design decision providing the minimal set of language constructs for distributed memory management. Rather than defining one specific distributed garbage collector directly in the interpreter, we have opted to enable the experimentation of distributed garbage collection techniques from within AmbientTalk itself. Thanks to AmbientTalk reflective infrastructure, it has been possible to build more sophisticated distributed garbage collection techniques to avoid the extra burden that takeOffline places on developers. More specifically, AmbientTalk integrates leasing techniques with the notion of a remote object reference, and provides the resulting //leased object references//. The system library shipped with AmbientTalk contains a reflective implementation of leased object references together with a set of language constructs to manipulate them.
 </note> </note>
  
-On the client side, taking offline an object results in a permanent disconnection of the remote 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. To this end, ''when:takenOffline'' was implemented in order for developers to be able to install observers on an far reference which are notified when the object pointed to is taken offline. The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified. As an example, the instant messenger application can clean certain resources when a buddy shuts down its instant messenger application as follows:+On the client side, taking offline an object results in a permanent disconnection of the remote 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. To this end, ''when:takenOffline'' has been implemented in order for developers to be able to install observers on an far reference which are notified when the object pointed to is taken offline. The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified. As an example, the instant messenger application can clean certain resources when a buddy shuts down its instant messenger application as follows:
  
 <code> <code>
Line 117: Line 130:
 </code> </code>
  
-Be aware that unexporting a object will not only trigger the takenOffline observers but also the disconnected observers since the taking offline event is also considered as a logical disconnection between two devices. Unlike disconnection observers, the block of code takenOffline observer will be triggered only once. The remote object becomes then subject to be eventually reclaimed by the garbage collector. As a result, the disconnected and reconnected observers will be no longer trigger for such remote reference. +Be aware that unexporting a object will not only trigger the takenOffline observers but also the disconnected observers since the taking offline event is also considered as a logical disconnection between two devices. Unlike the network observers, the block of code of a takenOffline observer will be triggered only once. The remote object becomes then subject to be eventually reclaimed by the garbage collector. As a result, the disconnected and reconnected observers will be no longer trigger for such remote reference. 
  
 Note that disconnection, reconnection and takenOffline observers can be also installed for the inter-actor far references. Such inter-actor far references are local to a virtual machine and as such, network failures cannot happen. In that case, the disconnection and takenOffline observers are triggered when the object pointed to by the far reference is taken offline. But the reconnected observers won't be never triggered since an unexported object cannot be exported again.  Note that disconnection, reconnection and takenOffline observers can be also installed for the inter-actor far references. Such inter-actor far references are local to a virtual machine and as such, network failures cannot happen. In that case, the disconnection and takenOffline observers are triggered when the object pointed to by the far reference is taken offline. But the reconnected observers won't be never triggered since an unexported object cannot be exported again. 
  
 <note> <note>
-The complete implementation of the instant messenger application explained along this section can be found in the file at/demo/InstantMessenger.at.+The complete implementation of the instant messenger application explained along this chapter can be found in the file ''at/demo/InstantMessenger.at''.
 </note> </note>
at/tutorial/distribution.txt · Last modified: 2009/01/30 16:13 by tvcutsem