Ambient-Oriented Programming

User Tools

Site Tools

Trace:
research:ambientrefs

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
research:ambientrefs [2006/07/11 21:16] – added tvcutsemresearch:ambientrefs [2008/02/19 10:36] – * tvcutsem
Line 1: Line 1:
 ===== Ambient References ===== ===== Ambient References =====
 +[[http://prog.vub.ac.be/~tvcutsem/|Tom Van Cutsem]]
  
 {{ ambientrefs.jpg }} {{ ambientrefs.jpg }}
Line 5: Line 6:
 Ambient references are a novel remote object reference mechanism. Remote object references are "pointers across the network" and are a frequently recurring abstraction in both distributed OO languages and distributed middleware. Ambient references are designed to refer to objects in [[research:terms:monets|mobile networks]]. What exactly constitutes a mobile network and how it differs from traditional, stationary networks is described [[research:terms:monets|elsewhere]]. Ambient references are a novel remote object reference mechanism. Remote object references are "pointers across the network" and are a frequently recurring abstraction in both distributed OO languages and distributed middleware. Ambient references are designed to refer to objects in [[research:terms:monets|mobile networks]]. What exactly constitutes a mobile network and how it differs from traditional, stationary networks is described [[research:terms:monets|elsewhere]].
  
-== Motivation ==+=== Motivation ===
  
 One may wonder why new referencing abstractions are required for mobile networks. In order to motivate the need for new referencing abstractions at the language level, we list a number of desirable properties of remote references for mobile networks which current remote referencing abstractions do not offer: One may wonder why new referencing abstractions are required for mobile networks. In order to motivate the need for new referencing abstractions at the language level, we list a number of desirable properties of remote references for mobile networks which current remote referencing abstractions do not offer:
Line 14: Line 15:
   - **Group Communication**: in mobile networks, one often wants to communicate with an entire group of objects. To this end, remote references should be introduced that automatically represent a set of (proximate) objects. Messages sent to such references are automatically multicast or broadcast to all objects in the set.   - **Group Communication**: in mobile networks, one often wants to communicate with an entire group of objects. To this end, remote references should be introduced that automatically represent a set of (proximate) objects. Messages sent to such references are automatically multicast or broadcast to all objects in the set.
  
-== Design ==+=== Design ===
  
-Ambient references unify two concepts: they are both a peer-to-peer discovery channel //and// an asynchronous communication channel to a remote object. When an ambient reference is **unbound** (i.e. it is a dangling pointer), it is acting as a discovery channel, actively looking for remote service objects in the environment to bind to. Once such a suitable ((What exactly constitutes a "suitable" service is discussed below.)) service object is found, the ambient reference becomes **bound**. Once bound, an ambient reference is a true remote object reference to the remote service. An ambient reference carries //asynchronous// message sends only.+Ambient references unify two concepts: they are both a peer-to-peer discovery channel //and// an asynchronous communication channel to a remote object. When an ambient reference is **unbound** (i.e. it is a dangling pointer), it is acting as a discovery channel, actively looking for remote service objects in the environment to bind to. Once such a suitable ((What exactly constitutes a "suitable" service is discussed later.)) service object is found, the ambient reference becomes **bound**. Once bound, an ambient reference is a true remote object reference to the remote service. An ambient reference carries //asynchronous// message sends only.
  
 When the service object to which an ambient reference is bound moves out of communication range, the ambient reference can become unbound again. It becomes a dangling pointer anew and immediately becomes a peer discovery mechanism again: the ambient reference will try to //rebind// to the same or another matching service. When the service object to which an ambient reference is bound moves out of communication range, the ambient reference can become unbound again. It becomes a dangling pointer anew and immediately becomes a peer discovery mechanism again: the ambient reference will try to //rebind// to the same or another matching service.
  
-= Describing services =+== Describing services ==
  
 An ambient reference is always initialized with a //service type// which denotes remote objects intensionally by the service it provides. One may, for example, declare an ambient reference to a nearby printer: An ambient reference is always initialized with a //service type// which denotes remote objects intensionally by the service it provides. One may, for example, declare an ambient reference to a nearby printer:
Line 32: Line 33:
 The primary advantage of using such service types rather than e.g. name servers, IP addresses or URLs is, evidently, abstraction over the machine address of the host providing the services. Ambient references can be used to refer to service objects, the host address of which is unknown to the code declaring the reference. All that needs to be agreed upon is a matching service type. The primary advantage of using such service types rather than e.g. name servers, IP addresses or URLs is, evidently, abstraction over the machine address of the host providing the services. Ambient references can be used to refer to service objects, the host address of which is unknown to the code declaring the reference. All that needs to be agreed upon is a matching service type.
  
-= Communicating with services =+== Communicating with services ==
  
 Asynchronous messages may be sent to an ambient reference at any point in time. For example, in order to print a document on a nearby printer, the ''printer'' ambient reference may be sent a message as follows: Asynchronous messages may be sent to an ambient reference at any point in time. For example, in order to print a document on a nearby printer, the ''printer'' ambient reference may be sent a message as follows:
Line 42: Line 43:
 In this example code ''<-'' denotes asynchronous message passing. The message passing semantics is as follows: if the ambient reference is unbound when it receives the ''print'' message, the message is //buffered// and kept for later forwarding; if the ambient reference is bound, it immediately forwards the message to its bound service object. Using these basic parameter passing semantics, a programming may safely abstract from the internal state of the ambient reference: even if the reference is unbound at the time it receives the message, it is smart enough to store the message and forward it whenever a matching service is found. In this example code ''<-'' denotes asynchronous message passing. The message passing semantics is as follows: if the ambient reference is unbound when it receives the ''print'' message, the message is //buffered// and kept for later forwarding; if the ambient reference is bound, it immediately forwards the message to its bound service object. Using these basic parameter passing semantics, a programming may safely abstract from the internal state of the ambient reference: even if the reference is unbound at the time it receives the message, it is smart enough to store the message and forward it whenever a matching service is found.
  
-One may wonder how return values can be acquired from such asynchronous message sends. We use the concept of a **future**, which is a very well known concept that unifies asynchronous message passing with return values. More specifically, the futures employed in the language AmbientTalk are based on the non-blocking futures of the [[www.erights.org|E programming language]]. For more details, we refer to the paper below, but as a teaser, here's how one can notify the user when the print job has been sent:+One may wonder how return values can be acquired from such asynchronous message sends. We use the concept of a **future**, which is a very well known concept that unifies asynchronous message passing with return values. More specifically, the futures employed in the language AmbientTalk are based on the non-blocking futures of the [[http://www.erights.org|E programming language]]. For more details, we refer to the paper below, but as a teaser, here's how one can notify the user when the print job has been sent:
  
 <code javascript> <code javascript>
Line 52: Line 53:
 </code> </code>
  
-= Synchronising with the ambient =+== Synchronising with the ambient ==
  
 Sometimes it is useful to know when a matching service has become available and to act upon that event. Equally useful is the ability to act upon the unavailability of a previously discovered service. Ambient references cater to such behaviour by providing for a number of observers which can monitor the state of the reference. Reusing the printer example, here's how one can keep a list of nearby printing services up-to-date: Sometimes it is useful to know when a matching service has become available and to act upon that event. Equally useful is the ability to act upon the unavailability of a previously discovered service. Ambient references cater to such behaviour by providing for a number of observers which can monitor the state of the reference. Reusing the printer example, here's how one can keep a list of nearby printing services up-to-date:
Line 69: Line 70:
 The ''when-found'' and ''when-lost'' clauses each register an observer function with the ambient reference. Whenever the ambient reference becomes bound or unbound, the corresponding observer functions are invoked, leading to the desired behaviour. The ''when-found'' and ''when-lost'' clauses each register an observer function with the ambient reference. Whenever the ambient reference becomes bound or unbound, the corresponding observer functions are invoked, leading to the desired behaviour.
  
-= Design Dimensions =+== Design Dimensions ==
  
 One may notice from the above description of ambient references that their behaviour of binding and rebinding is not always what is desired. Furthermore, sometimes one may want to refer to more than just one single remote service; i.e. group communication is required. In fact, there is more to ambient references than currently meets the eye. There are three design dimensions along which you, as a developer, can change the behaviour of ambient references: One may notice from the above description of ambient references that their behaviour of binding and rebinding is not always what is desired. Furthermore, sometimes one may want to refer to more than just one single remote service; i.e. group communication is required. In fact, there is more to ambient references than currently meets the eye. There are three design dimensions along which you, as a developer, can change the behaviour of ambient references:
Line 91: Line 92:
 In conclusion, what is important to recall is that an ambient reference is a remote object reference that may be in two states: it can be unbound, searching for a matching object or it can be bound, becoming an asynchronous communication channel to a remote object. The programmer can tweak **what** objects can be bound to, **how long** it should bind with an object and **how many** objects an ambient reference can bind to simultaneously. In conclusion, what is important to recall is that an ambient reference is a remote object reference that may be in two states: it can be unbound, searching for a matching object or it can be bound, becoming an asynchronous communication channel to a remote object. The programmer can tweak **what** objects can be bound to, **how long** it should bind with an object and **how many** objects an ambient reference can bind to simultaneously.
  
-== Implementation ==+=== Implementation ===
  
 A detailed explanation of ambient references can be found in [[ftp://prog.vub.ac.be/tech_report/2006/vub-prog-tr-06-07.pdf|this technical report]]. A detailed explanation of ambient references can be found in [[ftp://prog.vub.ac.be/tech_report/2006/vub-prog-tr-06-07.pdf|this technical report]].
  
-== Further Reading ==+=== Further Reading ===
  
-Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D'Hondt, Wolfgang De Meuter. In //Technical Report VUB-PROG-TR-06-10, Vrije Universiteit Brussel//, 2006 [ [[http://prog.vub.ac.be/Publications/2006/vub-prog-tr-06-10.pdf|download]] ]+  * Object-oriented Coordination in Mobile Ad Hoc Networks. Tom Van Cutsem, Jessie Dedecker, Wolfgang De Meuter. In //Proceedings of the 9th International Conference on Coordination Models and Languages//, Cyprus, 2007 [ [[http://prog.vub.ac.be/Publications/2007/vub-prog-tr-07-03.pdf|download]] ] 
 + 
 +  * Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D'Hondt, Wolfgang De Meuter. In //Proceedings of the Dynamic Language Symposium - OOPSLA '06: Companion of the 21st annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages and Applications.// Portland, U.S.A. ACM Press., 2006 [ [[http://prog.vub.ac.be/Publications/2006/vub-prog-tr-06-22.pdf|download]] ] 
 + 
 +  * Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D'Hondt, Wolfgang De Meuter. In //Technical Report VUB-PROG-TR-06-10, Vrije Universiteit Brussel//, 2006 [ [[http://prog.vub.ac.be/Publications/2006/vub-prog-tr-06-10.pdf|download]] ]
  
 Also see the [[research:posters]] section for a poster describing ambient references graphically. Also see the [[research:posters]] section for a poster describing ambient references graphically.
research/ambientrefs.txt · Last modified: 2010/09/13 15:13 by tvcutsem