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
research:ambientrefs [2007/03/19 12:41] – tvcutsemresearch:ambientrefs [2010/09/13 15:13] (current) – fixed tvcutsem
Line 1: Line 1:
 ===== Ambient References ===== ===== Ambient References =====
-[[http://prog.vub.ac.be/~tvcutsem/|Tom Van Cutsem]]+[[http://soft.vub.ac.be/~tvcutsem|Tom Van Cutsem]]
  
 {{ ambientrefs.jpg }} {{ ambientrefs.jpg }}
  
-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 type of remote object references. 
 +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 ===
Line 10: Line 11:
 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:
  
-  - **Provisional References**: remote references should be able to point to remote objects which are "not yet available" in the network. This is founded on the observation that in [[research:terms:monets|mobile networks]], ambient resources need to be discovered in the environment and will most likely be unavailable most of the time. +  - **Intensional Naming**: in mobile networks, one does not always know the identity or the exact number of the services one requires. Hence, rather than having to //extensionally// specify the services to bind to, one would like to refer to remote objects //intensionally//, based on the kind of services they provide. 
-  - **Resilience to Partial Failure**: remote references for mobile networks should be able to tolerate network disconnections because of the volatile connnections hardware phenomenon of mobile networks. +  - **Resilience to Partial Failure**: remote references for mobile networks should be able to tolerate network disconnections because transient network partitions are more commonplace in these types of networks. 
-  - **Transitory Addressing**: remote references in mobile networks should bind to (point to) objects based on what services that object provides, rather than based on a low-level UID, object-id, IP address or MAC address. Such low-level IDs preclude the reference from reconfiguring itself by rebinding to a different object providing the same or equally matching services. +  - **Roaming**: remote references in mobile networks should bind to (point to) objects based on what services that object provides, rather than based on a low-level UID, object-id, IP address or MAC address. Such low-level IDs preclude the reference from reconfiguring itself by rebinding to a different object providing the same or equally matching services. In other words, we want object references for MANETs to integrally support roaming by being able to opportunistically bind to whatever proximate matching service is available, regardless of its identity. 
-  - **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.+  - **Broadcasting**: in mobile networks, one often wants to communicate with an entire group of proximate objects. To this end, remote references should be introduced that can automatically broadcast messages to a set of (proximate) objects.
  
 === 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 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.+Ambient references have undergone several design iterations. We summarize here the latest design in AmbientTalk/2, as it is fully described in [[:research:atpapers|my PhD dissertation]].
  
-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.+Ambient references unify two concepts: they are both a peer-to-peer discovery channel //and// an asynchronous communication channel to a remote object. In AmbientTalk/2, they are represented as a special kind of **far references**. This implies that ambient references, like far references, are object references that can only carry asynchronously sent messages.
  
-== Describing services == +An ambient reference is initialized with a type tag: a network-wide name that describes a service known to the distributed peers. At any point in time, an ambient reference designates the set of proximate services whose type matches its type tag. For example:
- +
-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> <code javascript>
-printer = ambient Printer;+def printers := ambient: Printer;
 </code> </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 variable ''printers'' refers to an ambient reference which, at any point in time, designates all nearby ''Printer'' objects. An ambient reference designates a volatile set of proximate objects: the set may grow or shrink as devices are moving in and out of wireless communication range.
  
-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.+It is possible to restrict the set of service objects which an ambient reference may designate even further, by using so-called filter queries. For example, suppose one only wants to send documents to a printer that supports a resolution greater than 400 dpi. This can be expressed as: 
 +<code javascript> 
 +def printers := ambient: Printer where: { |p| p.dpi > 400 }; 
 +</code>
  
-== Communicating with services ==+== Message Passing Styles ==
  
-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:+An ambient reference can be used in two modes: as a point-to-point communication channel to //any// object in its designated set, or as a one-to-many communication channel to //all// objects in its designated set.
  
 +=== Point-to-point ===
 +Here is how to send a point-to-point message to any matching printer:
 <code javascript> <code javascript>
-printer<-print(document);+printers<-print(document)@One;
 </code> </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.+The ''<-'' syntax denotes an asynchronous message send in AmbientTalk/2. The ''@'' syntax is used to //annotate// an asynchronous message with additional metadata. In the above code, the ''@One'' annotation signifies to the ambient reference that the ''print'' message should be sent to only one of the nearby ''Printer'' services.
  
-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:+AmbientTalk/2 supports future-type message passing, which basically allows the programmer to access the return value of the ''print'' method via a future. Futures are a very well known concept that unify asynchronous message passing with return values. More specifically, the futures employed in AmbientTalk/2 are based on the non-blocking futures of the [[http://www.erights.org|E programming language]]. For more details, we refer to the papers below, but as a teaser, here's how one can notify the user when the print job has been sent:
  
 <code javascript> <code javascript>
-answer = printer<-print(document); +def answer := printers<-print(document)@One; 
-when(answer) lambda(ok) -> { +when: answer becomes: { |ack| 
-  if (ok) +  system.println("document successfully transmitted");
-    print("document successfully transmitted");+
 } }
 </code> </code>
  
-== Synchronising with the ambient ==+Ambient references seamlessly support roaming via point-to-point messaging: multiple messages sent to the same ambient reference may be delivered to //different// printing services. The programmer need not to worry about rebinding or reassigning the pointer to another ''Printer'' once the previously used ''Printer'' has moved out of range.
  
-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:+We will discuss later what happens if there are //no// matching ''Printer'' services at the time the message is sent. 
 + 
 +=== One-to-many === 
 + 
 +The following piece of code illustrates how to broadcast a ''receiveTextMessage'' message to all proximate ''ChatPeer'' objects in a virtual chat room:
  
 <code javascript> <code javascript>
-printer = ambient Printer; +def peers := ambient: ChatPeer; 
-printers = []; +... 
-when-found(printer) lambda(foundService) { +peers<-receiveTextMessage("hello world")@All; 
-  printers.add(foundService) +</code> 
-} + 
-when-lost(printer) lambda(lostService) { +Note the use of the ''@All'' annotation to signify to the ambient reference that the message should be broadcast to //all// nearby chat peers, not just to one of them. 
-  printers.remove(lostService)+ 
 +Ambient references extend AmbientTalk/2's support for futures such that they can be used for broadcast messages. The issue with broadcast messages is that they may be received by more than one receiver object. As a result, they may return more than one return value. To deal with this, we introduce //multi//futures: futures that may be resolved multiple times. Multifutures have their own kind of listeners that can be used to observe state changes in the multifuture. For example, to gather replies to a text message, one may write: 
 + 
 +<code javascript> 
 +def multifuture := peers<-receiveTextMessage("hello world")@All; 
 +whenEach: multifuture becomes: { |reply| 
 +  // process the reply
 } }
 </code> </code>
  
-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 above block closure ''{ |reply| ... }'' is applied for each return value sent back to the multifuture associated with the broadcast ''receiveTextMessage'' message.
  
-== Design Dimensions ==+== Disconnected Operation and Timeouts ==
  
-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:+Ambient references have been designed for Mobile ad hoc networks in which transient network partitions are commonplace. Hence, ambient references support a form of message passing which is resilient to temporary network failures. 
 + 
 +Any message sent to an ambient reference may be annotated with ''@Expires(timeout)''. The ''timeout'' parameter is a time period that describes how long the message will remain available for reception by proximate objects. We refer to it as the message's //expiration period//. When a message is sent to an ambient reference whose designated set of objects is empty, the message is not necessarily "lost". The message will remain buffered within the ambient reference for its expiration period. 
 + 
 +When an ambient reference discovers a receiver for its buffered messages in the ad hoc network, the messages are forwarded to the receiver(s). At this point, the message's remaining expiration period serves as a timeout for the outgoing message: if no reply to the message is received within the remaining timeout period, the message's associated future is ruined with a ''TimeoutException''. Here is a modified version of the ''Printer'' example that deals with disconnected operation and failures:
  
-  * **Scope of binding**: it is possible to restrict the set of remote service objects to which an ambient reference may bind even further, by using so-called filter queries. For example, suppose one only wants to send documents to a printer that supports a resolution greater than 400 dpi. This can be expressed as: 
 <code javascript> <code javascript>
-printer = ambient Printer p where p.dpi > 400; +def reply := printers<-print(document)@[One,Expires(minutes(2))]; 
-</code> +when: reply becomes: { |ack| 
-  * **Elasticity**: it is possible to specify that an ambient reference should "keep its connection alive" for a certain time period even after its remote service object has moved out of range. For example, one may declare an ambient reference to a printer that will not rebind to another printer unless disconnected for longer than one minute: +  system.println("document successfully transmitted"); 
-<code javascript> +catch: TimeoutException using: { |e| 
-printer = ambient(1min) Printer; +  system.println("request timed out"); 
-</code> +}
-  * **Cardinality**: it is possible to declare an ambient reference that points to a group of objects or even to //all// objects of a certain kind available in the environment. For example, one may send a message to "all nearby cars" as follows: +
-<code javascript> +
-cars = ambient* Car; +
-cars<-getSpeedAndSteeringAngle();+
 </code> </code>
  
-For more details regarding all of these design dimensions, have a look at the further reading section below.+If there are no matching ''Printer'' service objects at the time the ''print'' message is sent, the message will be buffered for at least 2 minutes within the ambient reference. If the message could not be sent to any printer, or it was sent to a printer but no reply was received within the 2 minute expiration period, the future associated with the message is ruined with a ''TimeoutException''.
  
-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.+== Conclusion ==
  
-=== Implementation === +What is important to recall is that an ambient reference is a remote object reference that allows programmers to //intensionally// designate a volatile set of proximate objects. Ambient references support asynchronous point-to-point or one-to-many communication styles. Programmers can tweak a message's expiration period to make message delivery more resilient to temporary failures, and to perform failure handling.
- +
-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 ===
  
-  * Object-oriented Collaboration in Mobile Ad Hoc Networks. Tom Van Cutsem. 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: Object Designation in Mobile Ad Hoc Networks. Tom Van Cutsem. PhD Thesis, Vrije Universiteit Brussel, May 2008. [ [[http://soft.vub.ac.be/Publications/2008/vub-prog-phd-08-01.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://soft.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 //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://soft.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]] ]+  * 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://soft.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.1174304501.txt.gz · Last modified: 2007/03/19 12:45 (external edit)