Differences

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

--- at:tutorial:distribution [2008/09/16 17:26] – * tvcutsem
+++ at:tutorial:distribution [2009/01/29 10:31] – elisag
@@ Line 3: / Line 3: @@
 Building on the actor-based concurrency model explained in the [[actors|previous chapter]], this chapter discusses the distribution provisions of AmbientTalk. For actors to communicate across the boundaries of a single device, actors need to be capable of discovering one another's presence and need to be resilient to intermittent disconnections of their communication partners.
-These requirements correspond to the cornerstones of the  Ambient-Oriented Programming paradigm. The seamless integration of language support for dealing with partial failures and performing service discovery, hinge on AmbientTalk's concurrency model based on actors and far references. This chapter will explore the discovery mechanisms to create far references which span different devices, and illustrate how such far references are able to deal with intermittent disconnections in mobile ad hoc networks.
+These requirements correspond to the cornerstones of the  Ambient-Oriented Programming paradigm. The seamless integration of language support for dealing with partial failures and performing service discovery, hinge on AmbientTalk's concurrency model based on actors and far references. This chapter will explore the discovery mechanisms to create far references which span different devices, and illustrate how such //remote// far references are able to deal with partial failures in mobile ad hoc networks.
 Before delving in these topics, we illustrate how to activate the network facilities of AmbientTalk in the next section.
@@ Line 63: / Line 63: @@
 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 =====
+===== Dealing with Transient Failures =====
-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, which we call //remote far references//, and how they deal with transient disconnections.
-When an object discovers a service type, the ''when:becomes:'' 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:
+When an object discovers a service type, the ''when:becomes:'' observers are triggered receiving as parameter a 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 far reference, the message is buffered in the 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.
@@ Line 90: / Line 90: @@
 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 order 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.
+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.
 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:
@@ Line 105: / Line 105: @@
 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.
+===== 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.
+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. 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.
+<code>
+def openSession() {
+  def shoppingCart := Cart.new(); // to store purchased items
+  def session := object: {
+    def addItemToCart(anItem) { ... }
+    def checkOutCart() { ... }
+  };
+  def leasedSession := lease: minutes(5) for: session;
+  leasedSession; // return lease on the session to the client
+};
+</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 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:
+<code>
+def mySession := server<-openSession()@FutureMessage;
+...
+mySession<-addItemToCart(selectedItem);
+</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 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>
+renew: mySession for: minutes(5);
+revoke: mySession;
+</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.
+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 e.g. the cart
+}
+</code>
+The construct takes as parameters a leased reference and a block of code that is asynchronously triggered upon the lease expiration. This allows client and service objects to treat a failure as permanent (i.e. to detect when the reference is permanently broken) and to perform application-level failure handling. At server side, this has important benefits for memory management. Once all leased references to a service object have expired, the object becomes subject to garbage collection once it is no longer locally referenced.
+====Leasing patterns====
+As is the case in other leasing mechanisms, determining the proper lease renewal period is not straightforward and may even depend on system parameters such as the number of clients. In AmbientTalk, we incorporate two leasing variants on leased object references which transparently adapt their lease period under certain circumstances.
+The ﬁrst variant is a //renew-on-call// leased reference which automatically prolongs the lease upon each method call received
+by the remote object. In other words, as long as the client uses the remote object, the leased reference is transparently renewed by the interpreter.  In the the shopping application example,  once a client establishes a shopping session with the server, the session should remain active as long as the shopping process is active, i.e. ''addItemToCart'' or ''checkOutCart'' messages are received in the session object. A renew-on-call leased reference can be used for the session object to model that kind of collaboration as follows:
+<code>
+def openSession() {
+  def shoppingCart := Cart.new(); // to store purchased items
+  def session := object: {
+    def addItemToCart(anItem) { ... }
+    def checkOutCart() { ... }
+  };
+  def leasedSession := renewOnCallLease: minutes(5) for: session;
+  leasedSession; // return lease on the session to the client
+};
+</code>
+Similar to ''lease:for:'', this construct takes as parameters a time interval (in milliseconds) and the remote object to which it grants access, and returns a leased reference that remains initially valid for 5 minutes but it is automatically renewed each time the remote object receives a message. The renewal time applied on every call is the initial interval of time speciﬁed at creation by default.
+The second variant is a //single-call// leased reference which automatically revokes the lease upon performing a successful method call on the remote object.  The ''singleCallLease:for:'' construct allows developers to create single-call leased references as follows:
+<code>
+def myObject: =  object:{
+...
+};
+def leasedObject := singleCallLease: minutes(5) for: myObject;
+</code>
+Similar to the other two constructs, ''singleCallLease:for:'' takes as parameters a time interval (in milliseconds) and the remote object to which it grants access, and returns a leased reference that remains valid for only a single call. In other words, the leased reference expires after the remote object receives a single message. However, if no message has been received within the speciﬁed time interval, the leased reference also expires.
+====Integrating leasing with future-type message passing====
+Single-call leases are useful for objects adhering to a single call pattern, such as callback objects. Callback objects are often used in asynchronous message passing schemes in order for remote object to be able to return values. These callback objects are typically remotely accessed only once by remote objects with the computed return value. In AmbientTalk, futures serves as an implicit callback.
+We have integrated leasing into futures by parameter-passing a future attached to an asynchronous message via a singe-call lease which either expires due to a timeout or upon the reception of the computed return value. The timeout for the implicit single-call lease on a future can be set by annotating the asynchronous message with a ''@Due'' annotation as follows:
+<code>
+def sessionFuture := server<-openSession()@Due(minutes(10));
+when: sessionFuture becomes: { |session|
+   // open session with server
+}catch: TimeoutException using: { |e|
+  // unable to open a session, do some clean-up if necessary
+}
+</code>
+If the future is resolved, the session variable stores a leased object reference to the remote session object.  A ''TimeoutException'' is raised when the future’s lease expires, i.e. when the reception of the computed return value is not received before the lease time elapsed.
+<note>
+Note that specifying a ''catch:'' block for the ''TimeoutException'' is equivalent to installing a ''when:expired:'' observer on the future’s (server-side) lease.
+</note>
+====Importing leased object references====
+Similar to futures, leased object references have been built reflectively on top of AmbientTalk.  The system library shipped with AmbientTalk contains the reflective implemention that adds leased references to the language kernel. This implementation can be found in the file at/lang/leasedrefs.at.
+To use the language constructs for leased references, you should import the leasedref module as follows:
+import /.at.lang.leasedref;
+<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 are enabled.
+</note>
+More information pertaining to the API of the leased references language module can be found in the appendix.
 ===== Garbage collecting remote references =====
+<note>
+Under Construction:
+Update this section to explain takeOffline in the contest of unitesting to unexport remotely accessible objects.
+</note>
 As explained in the previous section, AmbientTalk's remote references are by default resilient to disconnections. This has significant repercussions at a distributed memory management level. The main impact is that an exported object cannot be reclaimed when all of its clients are disconnected since the remote references remain pointing to the server object. In other words, servers objects are kept alive even though there are only remotely accessible by a disconnected remote reference. AmbientTalk provides built-in support to unexport explicitly remotely accessible objects by means of the ''takeOffline'' language construct. The construct look as follows: