Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:introduction

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
at:introduction [2007/04/11 12:36] – tvcutsemat:introduction [2008/07/15 12:19] (current) – * tvcutsem
Line 6: Line 6:
   * **dynamically typed**, which is **not** the same as being untyped: AmbientTalk //values// are typed, but //variables// are not   * **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.   * 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.
-  * Like Smalltalk, Self and Ruby, AmbientTalk embraces the use of elegant and expressive **block closures** to achieve a level of reusability far exceeding that of Java or similar languages lacking true closures.+  * flexible: like Scheme, Smalltalk, Self and many other languages, AmbientTalk embraces the use of elegant and expressive **block closures** to achieve a level of reusability far exceeding that of Java or similar languages lacking true closures.
   * 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!   * 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.+  * distributed: AmbientTalk has built-in language constructs 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.   * **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.
  
Line 40: Line 40:
      
   // engage in peer-to-peer service discovery   // engage in peer-to-peer service discovery
-  defstripe InstantMessenger;+  deftype InstantMessenger;
   export: remoteInterface as: InstantMessenger;   export: remoteInterface as: InstantMessenger;
   whenever: InstantMessenger discovered: { |messenger|   whenever: InstantMessenger discovered: { |messenger|
Line 51: Line 51:
 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. 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.+Within the lexical scope of the ''createInstantMessenger'' function, we also define a //type tag// named ''InstantMessenger'' which will be used to identify remote objects in the network as peer instant messengers. Type tags 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 type tags (unlike classes, type tags 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. 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.
Line 79: Line 79:
 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:actors|tutorial on actors]] for more details. 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:actors|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!+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 that we need to implement ourselves!
  
 Now let us delve into the details of the local interface object: Now let us delve into the details of the local interface object:
Line 132: Line 132:
  
 <code> <code>
-  defstripe InstantMessenger;+  deftype InstantMessenger;
   export: remoteInterface as: InstantMessenger;   export: remoteInterface as: InstantMessenger;
   whenever: InstantMessenger discovered: { |messenger|   whenever: InstantMessenger discovered: { |messenger|
Line 152: Line 152:
 </code> </code>
  
-The ''whenever:discovered:'' method takes a stripe and a one-argument closure as parameters. It invokes the closure every time a remote object exported as the given stripe is discovered. The first thing to do when a new messenger is discovered is to ask it for its name, by sending it the ''getName'' message. If the messenger was not previously discovered (i.e. its name is not in the buddy list), the messenger is added and the user is notified of the presence of the new buddy.+The ''whenever:discovered:'' method takes a type tag and a one-argument closure as parameters. It invokes the closure every time a remote object exported with (a subtype of) the given type tag is discovered. The first thing to do when a new messenger is discovered is to ask it for its name, by sending it the ''getName'' message. If the messenger was not previously discovered (i.e. its name is not in the buddy list), the messenger is added and the user is notified of the presence of the new buddy.
  
 Finally, notice how AmbientTalk allows you to deal with //partial failures//: you can register two kinds of //observers// on remote references which are triggered when the remote reference becomes disconnected (because of e.g. network partitions) and when it becomes reconnected. The second argument to ''when:disconnected:'' and ''when:reconnected:'' is a zero-arity closure. In this example, all we do is notify the user that a buddy when offline or came online. AmbientTalk's default semantics is to buffer messages sent to disconnected remote references internally, and to flush such messages if the remote reference should become reconnected. This provides the nice property that we can send messages to disconnected buddies and rest assured that the messages will arrive when the buddy rejoins the ad hoc network. Finally, notice how AmbientTalk allows you to deal with //partial failures//: you can register two kinds of //observers// on remote references which are triggered when the remote reference becomes disconnected (because of e.g. network partitions) and when it becomes reconnected. The second argument to ''when:disconnected:'' and ''when:reconnected:'' is a zero-arity closure. In this example, all we do is notify the user that a buddy when offline or came online. AmbientTalk's default semantics is to buffer messages sent to disconnected remote references internally, and to flush such messages if the remote reference should become reconnected. This provides the nice property that we can send messages to disconnected buddies and rest assured that the messages will arrive when the buddy rejoins the ad hoc network.
Line 170: Line 170:
   * no need to generate stubs, skeletons or other kinds of proxies to manage remote objects   * no need to generate stubs, skeletons or other kinds of proxies to manage remote objects
  
-Of course, we are not claiming that AmbientTalk is a good replacement for standards such as CORBA, which are much more flexible, at the cost of increasted complexity. AmbientTalk is simply a lightweight alternative for doing experimental research.+Of course, we are not claiming that AmbientTalk is a good replacement for distributed computing standards such as CORBA or Jini, which are much more flexible, at the cost of increased complexity. AmbientTalk is simply a lightweight alternative for doing experimental research.
  
-So, you read the introduction and are interested in all of the gory details of the language? In that case, you can go ahead and [[at:download|download]] AmbientTalk and read the [[at:tutorial:tutorial|tutorial]] which explains the language in much more detail.+===== Moving on ===== 
 + 
 +So, you read the introduction and are interested in all of the gory details of the language? In that case, you can go ahead and [[at:download|download]] AmbientTalk and read the [[at:tutorial:tutorial|tutorial]] which explains the language in much more detail. You can also {{http://prog.vub.ac.be/amop/presentations/SCCC-AT2.html|watch}} an introductory presentation on AmbientTalk (in flash format).
at/introduction.1176287790.txt.gz · Last modified: 2007/04/11 12:39 (external edit)