research:ambientrefs
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
research:ambientrefs [2006/06/27 11:31] – tvcutsem | research:ambientrefs [2006/07/11 20:58] – added tvcutsem | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | === Ambient References === | + | ===== Ambient References |
- | [[ambientrefs.jpg]] | + | {{ ambientrefs.jpg |
Ambient references are a novel remote object reference mechanism. Remote object references are " | Ambient references are a novel remote object reference mechanism. Remote object references are " | ||
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 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; | ||
+ | </ | ||
+ | |||
+ | The code excerpt above creates an ambient reference to an object providing the '' | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | <code javascript> | ||
+ | printer< | ||
+ | </ | ||
+ | |||
+ | In this example code ''< | ||
+ | |||
+ | 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, | ||
+ | |||
+ | <code javascript> | ||
+ | answer = printer< | ||
+ | when(answer) lambda(ok) -> { | ||
+ | if (ok) | ||
+ | print(" | ||
+ | } | ||
+ | </ | ||
== 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' | Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D' | ||
+ | |||
+ | Also see the [[research: |
research/ambientrefs.txt · Last modified: 2010/09/13 15:13 by tvcutsem