Differences

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

--- at:introduction [2007/04/07 11:50]
tvcutsem added
+++ at:introduction [2008/07/15 12:19]
tvcutsem *
@@ Line 1: / Line 1: @@
-===== What is AmbientTalk? =====
-{{:at:atlogo.jpg?80  |:at:atlogo.jpg}} AmbientTalk is a //distributed programming language// developed specifically for writing programs to be deployed on [[:research:terms:monets|mobile ad hoc networks]]. A distributed programming language is often characterised as a programming language with built-in support for aiding the programmer in dealing with the difficulties engendered by distribution. If you wonder what those difficulties would be, a good starting point are the well-known [[Wp>Fallacies_of_Distributed_Computing|fallacies of distributed computing]].
-For the programming language adepts: AmbientTalk is:
-  * **dynamically typed**, which is **not** the same as being untyped: AmbientTalk //values// are typed, but //variables// are not
-  * object-oriented, but prototype-based: AmbientTalk provides full support for objects, **delegation** (a form of inheritance) and polymorphic message dispatch. Objects are not instantiated from classes, as in Smalltalk, but rather cloned from existing objects or created //ex-nihilo//, as in Self.
-  * event-driven: AmbientTalk has built-in support for **actor**-based concurrency, which operates based on entirely //asynchronous// and //event-driven// communication. No threads, no locks, no deadlock and no data-level race conditions!
-  * distributed: AmbientTalk has built-in natives to make objects discover and talk to one another in a **peer-to-peer** manner across a TCP/IP network.
-  * **symbiotic**: built on top of the Java Virtual Machine, AmbientTalk exploits the Java reflection API to enable AmbientTalk objects to collaborate with Java objects. This enables reuse of existing Java libraries while not abandoning the dynamic programming style of AmbientTalk.
-A word of warning, though: AmbientTalk is **not** a stable development platform. Rather, it is a research artifact used as a "programming language laboratory" to experiment with and discover new language abstractions for distributed computing in mobile ad hoc networks.
-==== AmbientTalk in a nutshell ====
-Enough talking, let's delve into some AmbientTalk code by means of a simple example to see whether we can spark your interest in AmbientTalk. The demo program we're about to explore is an extremely simple instant messenger program. Each instant messenger runs on e.g. a PDA, laptop or cell phone. When peers join the ad hoc network, the instant messenger should issue a warning to the user that a new buddy is available for chatting. The user can then send simple text messages to that buddy. When peers leave the ad hoc network, the user should also be notified. Off we go.
-=== Design ===
-Here is the skeleton code for the instant messenger:
-<code>
-def createInstantMessenger(username) {
-  def TextMessage := ...; // object encapsulating a text message
-  def buddyList := ...; // maps buddy names to remote IM objects
-  // the interface to the IM for local objects
-  def localInterface := object: {
-    def sendTextMessage(to, string) { ... };
-  };
-  // the interface to the IM for remote objects
-  def remoteInterface := object: {
-    def receiveTextMessage(textMessage, replyTo) { ... };
-    def getName(replyTo) { ... };
-  };
-  // engage in peer-to-peer service discovery
-  defstripe InstantMessenger;
-  export: remoteInterface as: InstantMessenger;
-  whenever: InstantMessenger discovered: { |messenger|
-    ...
-  };
-  localInterface; // return value of this function
-};
-</code>
-An instant messenger object is created by invoking a function called ''createInstantMessenger''. A ''username'' should be passed to identify the user. The function defines two nested objects named ''localInterface'' and ''remoteInterface''. As their names indicate, the ''localInterface'' defines all of the methods that can be invoked by local objects referring to the instant messenger (e.g. by a GUI object that provides the user interface for the messenger). That's why the ''localInterface'' object is also the return value of the ''createInstantMessenger'' function. The ''remoteInterface'' provides the methods that may be invoked by remote objects (i.e. other instant messengers). In a sense, the remote interface defines the //protocol// that the messengers will use to exchange simple text messages.
-Within the lexical scope of the ''createInstantMessenger'' function, we also define a //stripe// named ''InstantMessenger'' which will be used to identify remote objects in the network as peer instant messengers. Stripes are simply symbolic marks that can be attached to objects to classify them. They replace the role of classes in class-based OO languages to classify objects. The advantage over classes is that an object can be classified under multiple stripes (unlike classes, stripes do not say anything about the implementation of an object). A few lines down, you'll notice that the nested ''remoteInterface'' object is **exported** as an ''InstantMessenger''. This means that the object is //published// on the network as an instant messenger peer. The next line of code shows AmbientTalk's built-in discovery mechanism at work: the instant messenger asks the AmbientTalk interpreter to be notified whenever an object exported as an ''InstantMessenger'' becomes available in the network. Yes, service discovery in ad hoc networks can be as simple as this.
-The ''buddyList'' variable will map the names of connected buddies to remote references to the ''remoteInterface'' objects of other instant messengers. The ''TextMessage'' object is a simple object that encapsulates a text string and the username of the sender.
-=== Implementation ===
-Let's delve into the method bodies and see how the instant messengers engage in distributed communication:
-<code>
-def createInstantMessenger(username) {
-  def TextMessage := isolate: {
-    def from := nil;
-    def content := nil;
-    def init(f,c) {
-        from := f;
-        content := c;
-    };
-    def printMessage() {
-      system.println(from + ": " + content)
-    };
-  };
-  def buddyList := jlobby.java.util.HashMap.new();
-</code>
-The ''TextMessage'' variable is bound to a prototype object that defines two instance variables (''from'' to store the sender and ''content'' to store the text message itself), it defines a constructor (always called ''init'' in AmbientTalk) and one method named ''printMessage'' to display the message. Why is ''TextMessage'' defined as an ''isolate:'' rather than an ''object:''? An //isolate// in AmbientTalk is an object that can be passed by copy in remote message sends, at the expense of losing its surrounding lexical scope. See the [[:at:tutorial:concurrency|tutorial on actors]] for more details.
-Also interesting is the initialisation code of the ''buddyList'' variable. The ''buddyList'' is actually a symbiotic Java object instantiated from the class ''java.util.HashMap''. That's one less data structure to implement ourselves!
-<code>
-  def localInterface := object: {
-    def sendTextMessage(to, string) {
-      def buddy := buddyList.get(to);
-        if: (nil == buddy) then: {
-          system.println("Unknown buddy: " + to);
-        } else: {
-          def msg := TextMessage.new(username, string);
-          buddy<-receiveTextMessage(msg, object: {
-            def uponReceipt() {
-              msg.printMessage();
-            }
-          });
-        };
-    };
-  };
-  def remoteInterface := object: {
-    def receiveTextMessage(textMessage, replyTo) {
-      textMessage.printMessage();
-      replyTo<-uponReceipt();
-    };
-    def getName(replyTo) { replyTo<-receive(username) };
-  };
-  defstripe InstantMessenger;
-  export: remoteInterface as: InstantMessenger;
-  whenever: InstantMessenger discovered: { |messenger|
-    messenger<-getName(object: {
-      def receive(name) {
-        if: (nil == buddyList.get(name)) then: {
-          buddyList.put(name, messenger);
-          system.println("Added buddy: " + name);
-          when: messenger disconnected: {
-            system.println("Buddy offline: " + name);
-          };
-          when: messenger reconnected: {
-            system.println("Buddy online: " + name);
-          };
-        };
-      };
-    });
-  };
-  localInterface;
-};
-</code>
-Notice the initialisation of the ''buddyList'' variable:
-<code>def buddyList := jlobby.java.util.HashMap.new();</code>
-The buddy list is actually

Ambient-Oriented Programming

User Tools

Site Tools

Differences

Page Tools