Differences

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

--- at:tutorial:distribution [2009/01/28 17:31] – adding elisag
+++ at:tutorial:distribution [2009/01/28 17:55] – elisag
@@ Line 110: / Line 110: @@
 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.
-To deal with permanent failures, AmbientTalk uses the concept of leasing. A lease denotes the right to access a resource for a speciﬁc 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 ﬁrst 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 speciﬁc 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 ﬁrst 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====
-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.
+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}}
 ====Working with leased object references====
-The code snippet below illustrates a leased far reference in the context of an online shopping application. In the example, a client object can ask a server to start a shopping session by sending it the openSession message. In response to this message, the server returns a new session object which implements methods that allow a client to place items in its shopping cart or to check out. The returned session gets leased by means of the lease:for: construct.
+The code snippet below illustrates a leased far reference in the context of an online shopping application. In the example, a client object can ask a server to start a shopping session by sending it the ''openSession'' message. In response to this message, the server returns a new session object which implements methods that allow a client to place items in its shopping cart or to check out. The returned session gets leased by means of the ''lease:for:'' construct.
 <code>
@@ Line 132: / Line 134: @@
 </code>
-The lease:for: construct takes as parameters a time interval (in milliseconds) and the remote object to which it grants access, and returns a leased far reference that remains valid for the indicated time interval (5 minutes in the example). The construct  alters the parameter passing semantics of the remote object to which it grants access, which gets parameter passed by lease rather than the default by far reference semantics.
+The ''lease:for:'' construct takes as parameters a time interval (in milliseconds) and the remote object to which it grants access, and returns a leased far reference that remains valid for the indicated time interval (5 minutes in the example). The construct alters the parameter passing semantics of the remote object to which it grants access, which gets parameter passed by lease rather than the default by far reference semantics.
+<note>
+We assume the use of futures to get the return value of the ''openSession'' asynchronous message invocation. For further details about futures, we refer the reader to the previous chapter on the [[actors|concurrency model of AmbientTalk]].
+</note>
 At client side, a customer can ask a server to open a shopping session as follows:
@@ Line 142: / Line 148: @@
 </code>
-The future attached to the openSession message will be resolved with a leased reference to a session object which remains valid for the next 5 minutes. From that moment on, the client can use the leased reference as if it were the session object itself until it expires. Similar to far references, client objects can only send messages to service objects asynchronously. The lifetime of a leased reference can be explicitly controlled by renewing or revoking it before it expires as shown below:
+The future attached to the ''openSession message'' will be resolved with a leased reference to a session object which remains valid for the next 5 minutes. From that moment on, the client can use the leased reference as if it were the session object itself until it expires. Similar to far references, client objects can only send messages to remote objects asynchronously. The lifetime of a leased reference can be explicitly controlled by renewing or revoking it before it expires as shown below:
 <code>
@@ Line 149: / Line 155: @@
 </code>
-The renew: construct requests a prolongation of the speciﬁed leased reference with a new interval of time which can be diﬀerent than the initial time. The revoke: construct cancels the given leased reference. Cancelling a lease is in a sense analogous to a natural expiration of the lease, but it requires communication between the client and server side of the leased reference.
+The ''renew:'' construct requests a prolongation of the speciﬁed leased reference with a new interval of time which can be diﬀerent than the initial time. The ''revoke:'' construct cancels the given leased reference. Cancelling a lease is in a sense analogous to a natural expiration of the lease, but it requires communication between the client and server side of the leased reference.
-When no renewal is performed due to a network partition outlasting the lease time period or in absence of utilization,  the leased reference expires when the its lease time elapses. Both client and service objects can schedule clean-up actions with the leased reference upon expiration by means of the when:expires: construct as follows:
+When no renewal is performed due to a network partition outlasting the lease time period or in absence of utilization,  the leased reference expires when the its lease time elapses. Both client and service objects can schedule clean-up actions with the leased reference upon expiration by means of the ''when:expires:'' construct as follows:
 <code>
 when: mySession expired: {
-... // free up resources used by this session
+... // free up resources used by this session e.g. the cart
 }
 </code>
@@ Line 223: / Line 229: @@
 <note>
-leasedref 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 leasedref import statement if some other module has already imported them, e.g. if futures were imported.
+leasedref 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 leasedref import statement if some other module has already imported them, e.g. if futures are enabled.
 </note>