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 revision Previous revision
Next revision 		Previous revision
at:tutorial:distribution [2009/01/29 22:10]
elisag 		at:tutorial:distribution [2009/01/30 16:13] (current)
tvcutsem *fixed
Line 72: Line 72:
   - Native data types are always 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. +When a remote far reference receives a message, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, messages are accumulated in its inbox in order to be transmitted once the reference becomes reconnected at a later point in time, when the network connection is restored. 
  
-Therefore, a remote far reference abstracts a client object from the actual network connection state. However, it is often useful for an application to be informed when a connection to a remote object is lost or reconnected. To this end, AmbientTalk offers language constructs to install observers on a far reference which are triggered whenever the reference becomes disconnected or reconnected. For example, the instant messenger application can notify the user whenever a buddy moves in and out of the communication range as follows:+Therefore, a remote far reference allows its clients to make abstraction from the actual network connection state. However, it is often useful for an application to be informed when a connection to a remote object is lost or restored. To this end, AmbientTalk offers language constructs to install observers on a far reference which are triggered whenever the reference becomes disconnected or reconnected. For example, the instant messenger application can notify the user whenever a buddy moves in or out of the communication range as follows:
  
 <code> <code>
Line 88: Line 88:
 </code> </code>
  
-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 illustrates how the instant messenger application gets notified when a buddy goes online or offline. In the above code, ''messenger'' is a remote reference to another remote buddy discovered. Note that by installing observers that trigger upon disconnection, developers can clean certain resources when a remote reference becomes disconnected. However, when an instant messenger disconnects, the remote object referred to by ''messenger'' remains exported. This implies that a disconnected remote reference remains valid (it can reconnect), but also that the remote object remains referred to by a disconnected remote reference. This reference thus prevents the remote object from being garbage collected. In fact, ''messenger'' is never garbage unless its subscription is explicitly cancelled. But other types of objects which are only relevant within the context of an interaction should eventually become candidates for garbage collection. In the next section, we detail how AmbientTalk deals with distributed memory management. 
  
-In order to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the remote 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. +In order to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the remote far reference outbox by means of the ''retract'' language construct. This is especially useful in the context of distribution, since developers can have explicit control over the messages that are buffered but have not been sent while the remote far reference was disconnected. Any undelivered messages accumulated by the remote reference can then be e.g. 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:+The ''retract'' language construct takes as argument the far reference of which to retract buffered outgoing messages. One can store the unsent messages upon disconnection of a service type ''Service'' as follows:
  
 <code> <code>
Line 102: Line 102:
 </code> </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. +The ''retract:'' call 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. 
  
 The function ''when:disconnected:'' behaves like the previously discussed function ''whenever:disconnected:'', except it triggers the associated closure at most once, not upon //every// disconnect. The function ''when:disconnected:'' behaves like the previously discussed function ''whenever:disconnected:'', except it triggers the associated closure at most once, not upon //every// disconnect.
Line 108: Line 108:
 ===== Dealing with Permanent Failures ===== ===== Dealing with Permanent Failures =====
  
-As explained in the previous section, remote far references have been designed to be resilient to intermittent disconnections by default. This behaviour is desirable because it can be expected that many partial failures in mobile ad hoc networks are the result of transient network partitions. However, not all network partitions are transient. For example, a remote device has crashed or has moved out of the wireless communication range and does not return. Such permanent failures should also be dealt by means of compensating actions, e.g. application-level failure handling code.+As explained in the previous section, remote far references have been designed to be resilient to intermittent disconnections by default. This behaviour is desirable because it can be expected that many partial failures in mobile ad hoc networks are the result of transient network partitions. However, not all network partitions are transient. For example, a remote device has crashed or has moved out of the wireless communication range and does not return. Such permanent failures should also be dealt with by means of compensating actions, e.g. application-level failure handling code.
  
-To deal with permanent failures, AmbientTalk uses the concept of leasing. A lease denotes the right to access a resource for a specific duration that is negotiated by the owner of a resource and a resource claimant (called the lease grantor and lease holder, respectively) when the access is first requested.  At the discretion of the lease grantor a lease can be renewed, prolonging access to the resource. In AmbientTalk, we represent leases as a special kind of remote far references, which we call //leased object references//. +To deal with permanent failures, AmbientTalk uses the concept of leasing. A lease denotes the right to access a resource for a specific duration that is negotiated by the owner of a resource and a resource claimant (called the lease grantor and lease holder, respectively) when the access is first requested. At the discretion of the lease grantor a lease can be renewed, prolonging access to the resource. In AmbientTalk, we represent leases as a special kind of remote far references, which we call //leased object references//.
  
 ====Leased Object References==== ====Leased Object References====
  
-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.+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 reference 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?160x30}} {{ :at:tutorial:leasedref-state.png |:at:tutorial:leasedref-state.png?160x30}}
Line 231: Line 231:
 </note> </note>
  
-More information pertaining to the API of the leased references language module can be found in the [[appendix#language_extensions|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 =====
at/tutorial/distribution.1233263404.txt.gz · Last modified: 2009/01/29 22:10 (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki