Differences

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

--- research:ambientrefs [2006/07/11 20:58] – added tvcutsem
+++ research:ambientrefs [2006/07/11 21:16] – added tvcutsem
@@ Line 20: / Line 20: @@
 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:
@@ Line 32: / Line 32: @@
 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:
@@ Line 52: / Line 52: @@
 </code>
-== Example Usage ==
+= 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:
+<code javascript>
+printer = ambient Printer;
+printers = [];
+when-found(printer) lambda(foundService) {
+  printers.add(foundService)
+}
+when-lost(printer) lambda(lostService) {
+  printers.remove(lostService)
+}
+</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.
+= 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:
+  * **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>
+printer = ambient Printer p where p.dpi > 400;
+</code>
+  * **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:
+<code javascript>
+printer = ambient(1min) Printer;
+</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>
+For more details regarding all of these design dimensions, have a look at the further reading section below.
+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 ==