User Tools

Site Tools


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/06/27 11:32] tvcutsemresearch:ambientrefs [2006/07/11 20:58] – added tvcutsem
Line 1: Line 1:
-=== Ambient References ===+===== Ambient References =====
  
 {{ ambientrefs.jpg }} {{ ambientrefs.jpg }}
Line 16: Line 16:
 == 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.+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. 
 + 
 +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 === 
 + 
 +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: 
 + 
 +<code javascript> 
 +printer = ambient Printer; 
 +</code> 
 + 
 +The code excerpt above creates an ambient reference to an object providing the ''Printer'' service and stores it in the variable named ''printer''. This code assumes that remote service objects publish their printing services using the ''Printer'' type. Ambient references bind to remote objects when the type they require is the same or a subtype of the providing object (e.g. the above ''printer'' ambient reference may bind to a ''ColorPrinter'' if that type is a subtype of ''Printer''). 
 + 
 +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 === 
 + 
 +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: 
 + 
 +<code javascript> 
 +printer<-print(document); 
 +</code> 
 + 
 +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: 
 + 
 +<code javascript> 
 +answer = printer<-print(document); 
 +when(answer) lambda(ok) -> { 
 +  if (ok) 
 +    print("document successfully transmitted"); 
 +
 +</code>
  
 == Example Usage == == Example Usage ==
Line 27: Line 61:
  
 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]] ] 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.
research/ambientrefs.txt · Last modified: 2010/09/13 15:13 by tvcutsem