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:34] – * elisagat:tutorial:distribution [2009/01/28 11:26] – elisag
Line 1: Line 1:
-<note> +====== Distributed Programming ======
-This tutorial is under heavy construction! +
-</note>+
  
-====== Distributed Programming ======+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.
  
-This tutorial chapter discusses how AmbientTalk virtual machines can discover and communicate with each other over the network.  +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. 
-The integration of distribution was one of the main concerns in the design of AmbientTalk programming model. +
  
-More specifically, as a distributed programming language that adheres to the Ambient-Oriented Programming paradigm, AmbientTalk incorporates partial failures and discovery lookup facilities at the heart of its distributed programming model. Rather than creating stubs and skeletons to manage remote communications, AmbientTalk integrates them transparently to the developer thanks to its concurrency model based on actors and far references. Far references are in fact a vital feature of the distributed model of AmbientTalk that allows the language to be able to handle the so-called volatile connections featured in mobile ad hoc networks.  This chapter mainly explains the language abstractions to export and discover other remote objects, and handle partial failures. But first, let us start simply by showing how to enable the network functionality.+Before delving in these topics, we illustrate how to activate the network facilities of AmbientTalk in the next section.
  
-===== Starting the Network.. =====+===== Going Online =====
    
 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.  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.+When the virtual machine goes online, the built-in service discovery mechanism is able to broadcast the presence of locally discoverable objects to all virtual machines in the environment, as well as acquaint local objects with discoverable objects on other devices. The precise details of AmbientTalk's discovery support will be further explained in the following section. 
 + 
 +Taking a virtual machine offline on the other hand will immediately sever all connections with other virtual machines and thus, induce a partial failure for all references that transgress the boundaries of a single virtual machine. This is a deliberate design choice made to facilitate the simulation of transient disconnections. Note that such disconnections do not render far references unusable, as we shall explain [[distribution#partial_failure_handling|below]].
    
 <note> <note>
Line 24: Line 23:
 AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows: AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows:
 <code> <code>
-defstripe Printer;+deftype Printer;
 def service := object: {  def service := object: { 
- def print(aDoc) { +  def print(aDoc) { 
- system.println("printing " +aDoc); +    system.println("printing " +aDoc); 
-    }+  }
 }; };
 export: service as: Printer; export: service as: Printer;
 </code> </code>
  
-When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a [[actors#stripes|stripes]]. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a stripe, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following stripe:+When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a type tag. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a type tag, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following type tag:
 <code> <code>
-defstripe ColorPrinter <: Printer;+deftype ColorPrinter <: Printer;
 </code> </code>
  
Line 47: Line 46:
 <code> <code>
 when: InstantMessenger discovered: { |messenger| when: InstantMessenger discovered: { |messenger|
-     when: (messenger<-getName()) becomes: { |name| +  when: (messenger<-getName()) becomes: { |name| 
- buddyList.put(name, messenger); +    buddyList.put(name, messenger); 
- system.println("Added buddy: " + name);   +    system.println("Added buddy: " + name); 
-     };+  };
 }; };
 </code> </code>
Line 57: Line 56:
  
 <note> <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]].+We are using a future to get the return value of the ''getName'' asynchronous 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> </note>
  
Line 63: Line 62:
  
 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. 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 ===== ===== Partial Failure Handling =====
Line 69: Line 67:
 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 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.+  - Objects are always passed //by far reference//, except for isolate objects which are passed by copy.
   - 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 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. 
  
-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 when 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 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:
  
 <code> <code>
 when: InstantMessenger discovered: { |messenger| when: InstantMessenger discovered: { |messenger|
- ... +  ... 
- when: messenger disconnected: { +  whenever: messenger disconnected: { 
-     system.println("Buddy offline: " + name); +    system.println("Buddy offline: " + name); 
- }; +  }; 
- when: messenger reconnected: { +  whenever: messenger reconnected: { 
-     system.println("Buddy online: " + name); +    system.println("Buddy online: " + name); 
- };+  };
 }; };
 </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 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 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:
 +
 +<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. 
 +
 +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.
  
 ===== Garbage collecting remote references ===== ===== Garbage collecting remote references =====
 +
 +<note>
 +This is an advanced topic and probably does not belong in the tutorial. Moreover, it discusses features to be used only by implementors of reflective language constructs. It would better be replaced by a thorough explanation of leased object references.
 +</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: 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:
Line 104: Line 121:
  
 <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>
 when: messenger takenOffline: { when: messenger takenOffline: {
-   system.println("Buddy offline: " + name); +  system.println("Buddy offline: " + name); 
-   //clean certain resources associated to the buddy+  //clean certain resources associated to the buddy
 }; };
 </code> </code>
Line 121: Line 138:
  
 <note> <note>
-The complete implementation of the instant messenger application explained along this chapter 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