Differences

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

--- research:doforreal [2010/08/03 20:29] – created stijnm
+++ research:doforreal [2010/08/04 17:34] (current) – shortened tvcutsem
@@ Line 1: / Line 1: @@
-==== Distributed Objects for Real ====
+====== Distributed Objects for Real ======
-== Real Objects ==
+Over the past year, the Software Languages Lab has been experimenting with new programming language abstractions for mobile RFID-enabled applications. We approached the development of such applications from two opposing perspectives, each outlined below.
-The widespread adoption of RFID tags provides a unique opportunity to equip physical objects with a digital presence.  While the idea was previously explored in the Cooltown project, the introduction of RFID tags as a cost-effective means to tag virtually any object implies a massive increase in scale.  It is important to note that some technical problems remain to be addressed in order to allow the user to roam a world populated by a vast amount of objects, both digital and physical.
+===== Volatile Data Clouds =====
+<note>The volatile data clouds model can be considered a special case of [[research:recap]] specifically applied to the domain of mobile RFID-enabled applications.</note>
-One problem of note involves the power requirements of an RFID reader.  To communicate with passive RFID tags, the reader should emit a magnetic field which provides the RFID tag with sufficient energy to be able to respond.  The strength of the field emitted by the reader determines the distance at which the tag can be read.  While a fixed reader can continuously scan its environment within a broad range, mobile readers currently operate at a significantly smaller range in an effort to conserve battery power.  For instance, our fixed Feig HF reader has a maximal reading range of 18cm (with other HF readers boasting ranges of 30 to 60 cm) as opposed to a mobile Cathexis Bluetooth reader which only detects tags within 1 cm.  However, it is conceivable that in the near future mobile readers will be able to scan tags in a considerably broader range.
+The //volatile data clouds// model considers RFID tags to be data containers whose presence or absence can be used to steer the application.  Therefore, it focusses on designing a general means to represent the collection of currently visible tags.
-Anticipating the advent of mobile readers with an extended range of operation, the authors believe that it is crucial to devise mechanisms that allow application developers to deal with a situation where users carry mobile devices capable of detecting physical objects in their environment.  A thorough discussion is needed on how to model a collection of nearby objects which is constantly in flux.  Over the past year, we have developed two opposing programming models to represent RFID tags in an application.  In this position paper we present these models as two extremes in hopes of inspiring discussion on how mobile applications should deal with a world populated by both digital and physical objects.
+Since the collection is implicitly tied to the environment and changes frequently in response to events emitted by the RFID reader, //change// is at the very heart of the model.  To permit application developers to respond to and propagate these changes without having to explicitly register a plethora of observers, we borrow concepts from [[research:rp|reactive programming]].
-Prototype implementations of both models have been developed in AmbientTalk, an actor-based domain-specific language built on top of J2ME.  In this position paper, the models are explained as independently as possible of their realization in AmbientTalk.
+Concretely, the collection of visible tags is modeled as a //reactive collection//. In order to test for the presence of a particular tag, one can invoke the ''contains'' method of the reactive collection, which results in a new dependent reactive value.  That value is transparently updated whenever the collection changes.  This automatic propagation of changes to a reactive collection of RFID tags is a determining factor in the expressiveness of applications that use the volatile data cloud metaphor.
-== Volatile Data Clouds ==
+Another important aspect is efficiently detecting when interesting patterns occur in a reactive tag collection.  A pattern of interest can be the presence of a particular (kind of) tag, but should extend to combinations of interesting tags.  To detect such
+occurrences, we make use of [[research:patterns|pattern matching rules]] which can be applied to any reactive collection.  This technique allows building RFID applications using a declarative programming style.
-The //volatile data clouds// model considers an RFID tag as data whose presence or absence can be used to steer the application.  Therefore, it provides an explicit representation for the collection of visible tags.  This collection is implicitly tied to the environment and is likely to change frequently.  Such changes are at the very heart of the model and consequently application programmers do not need to manually specify observers to react to them.  Instead changes are propagated implicitly and automatically.
+===== Proxy Objects =====
-The implicit and automatic propagation of change is achieved by borrowing ideas from //functional reactive programming//, which introduces reactive values.  Changes to these reactive values (which represent e.g. time, the speed of a robot wheel etc.) are propagated to a network of dependent computations.  Such a network of dependent computations is built when functions are applied to one or more reactive values.  The result of applying such a function is a new reactive value, which can in turn be used to construct additional dependent computations.
+<note>
+The proxy objects model represents RFID-tagged physical objects as full-blown software objects, which introduces a natural mechanism to deal with **mutable tag data**.  More information as well as videos of our experiments can be found [[research:rfid|here]].
+</note>
-When programing with reactive values that represent the collection of visible tags, the programming language needs to provide the following support.  First of all, support is needed for //reactive collections//, such that operations such as ''size'' and ''contains'' result in a reactive value that changes when the collection changes.  This necessitates the introduction of reactive programming support in the programming language.  Reactive programming has been successfully incorporated in various languages including Scheme, Java.
+While the //volatile data clouds// model considers RFID tags to be containers of data which is to be filtered and interpreted by the application, the //proxy objects// model conceived them as hosts for full-fledged objects, which encapsulate mutable state and provide their own methods.
-Furthermore, such collections should provide //memoized iteration// constructs (e.g. ''map:'').  Hence, when mapping a function //f// over a source collection //s//, a memoized ''map:'' produces a derived collection //d// by simply mapping //f// over the current elements of //s//.  If at any later point in time, a new element //a// is added to //s//, the update will not cause the derived collection to be computed anew.  Instead, //d// is extended with a single new element, to wit //f(a)//.  Similarly, when an element //r// is removed, only the value //f(r)// is removed from //d//.
+When interacting with these proxy objects, one has to deal with the ephemeral nature of the connection between the mobile RFID-enabled application and any particular tag denoted by a proxy object.  The concerns to be addressed when interacting with RFID-tagged physical objects closely mimic those that govern
+the interaction with classic remote objects:
-Most importantly, the programming language should provide support to detect interesting patterns as they occur in a reactive collection.  A pattern of interest can be the presence of a particular (kind of) tag, but should extend to combinations of interesting tags.  Therefore, we propose a model which uses //pattern matching rules// to detect changes of interest in the application's environment.  An application could for instance specify a rule which triggers when the tags that represent the user's keys and coat are detected simultaneously.  Such a rule could be used to remember that the user is likely to have left his keys in one of the pockets of his coat.
+First of all, mobile RFID-enabled applications need a means to detect when a particular tagged object has come into range.  As RFID tags are modeled as devices hosting an object, the most natural
+mechanism to achieve this is to use the default [[at:tutorial:distribution#exporting_and_discovering_objects|service discovery mechanisms]] of AmbientTalk.
-== Tags Objects ==
+Once a proxy object has been discovered, the application can start to interact with it.  However, if either the user of the application or the tagged object is roaming, it is extremely likely that the tag will (temporarily) go out of range.  Hence,  application programmers are provided with [[at:tutorial:actors#ambienttalk_actors_and_far_references|far references]] to the proxy objects.  This design ensures that proxy objects can only be addressed using asynchronous messages and it implies that when a tag goes out of range, all messages that are sent to it are [[at:tutorial:distribution#dealing_with_transient_failures|buffered]].  Subsequently, when the object comes in range again, these buffered messages will be flushed and forwarded to the tag on the object.
-While the //volatile data clouds// model considers RFID tags as containers of data which is to be filtered and interpreted by the application, the //tag objects// model interprets them to be full-blown objects.  Applications can interact with these objects and e.g. invoke methods on them.  In this case, the tag contains a marshalled object representation which is implicitly unmarshalled to provide a live object which applications can interact with.
+By aligning tagged objects with remote objects, one can develop mobile RFID-enabled applications without having to learn about a new concept.  Furthermore, application programmers can rely on the entire arsenal of abstractions to deal with remote objects. For instance, one can be notified of disconnection using the default //disconnection// and //reconnection listeners//.
-When treating tags as objects, it is important to deal with the ephemeral nature of the connection between the mobile application and any particular tag.  A first problem to be tackled is how applications detect new tags as they come into range.  This is addressed by the introduction of a semantic //service discovery// mechanism, which allows applications to be notified when an interesting tag appears.  The use of a service discovery mechanism also provides an implicit mechanism to disregard tags which contain objects that are irrelevant to the application.  For instance, an application can choose to only discover objects of type ''Book'' or ''Ingredient''.
+A particularly interesting abstraction when developing mobile RFID-enabled applications are [[research:ambientrefs|ambient references]].  First of all, such references introduce mechanisms to clearly specify which objects one wants to refer to (i.e. one can impose additional constraints beyond the type of the object).  Additionally, ambient references provide a mechanism to implicitly denote and send messages to a collection of (proxy) objects.
-Once a tag object has been discovered, the application can start to interact with it.  However, if either the user of the application or the tagged object is roaming, it is extremely likely that the tag will (temporarily) go out of range.  The tagged object model requires that the programming abstraction are sufficiently robust to deal with such sudden disappearances.  Therefore, tag objects should be treated as "remote objects"; objects which can only be addressed using asynchronous messages.  Hence, when a tag goes out of range, all messages that are sent to it are buffered.  Subsequently, when the tag comes in range again, all //buffered messages// sent to it can be flushed.
+===== Comparison =====
-While messages are implicitly buffered during a temporary disconnection, it is important to provide the application programmer with the necessary abstractions to explicitly detect when a tag has disappeared or when it has been unreachable for a certain period of time. Therefore, the programming model should allow the application to explicitly provide //disconnection// and //reconnection listeners//.
+Having implemented both models, we have found their virtues and limitations to be largely complementary.  As it stands, both models have shown to cater to different kinds of applications.
-Within the tag object model, we have conducted initial experiments on how to use ad hoc //replication strategies// which could allow continued use of a tag object even when the tag is temporarily unreachable.  When the tag becomes reachable again, updates can be synchronized.  With such a custom replication strategy in place, it can in principle be possible to treat tag objects as "local objects"; objects which can be addressed with both asynchronous and synchronous messages.
+The volatile data clouds model treats RFID tags as simple containers of data and aims at providing applications with expressive means to represent a collection of nearby tags which is constantly in flux.  Consequently, the model focusses on being able to expressively filter such collections and detect the presence of (a combination of) tags, to which the application can respond.  Using volatile data clouds as a means to represent nearby tags allows the programmer to abstract over the events that underly the discovery of new tags and the handling of their disappearance.  The cost incurred by using these abstractions is the need for a rather heavy-weight infrastructure to properly handle reactive computation.  In its current incarnation, the volatile data clouds model treats RFID tags as containers of immutable data whose presence indicates the presence of a physical object in close proximity to the device that is running a particular application.
-== Comparison ==
+The tag objects model on the other hand treats the contents of an RFID tag as a full-fledged object.  This makes the model capable of interacting naturally with tags that contain mutable objects and makes it particularly interesting to model interactions with //active RFID tags//((Active tags are RFID tags which contain their own power source and are capable of independently performing (some limited form of) computation.)).  Another advantage is that the model only requires a service discovery mechanism and a means to buffer messages, which makes it considerably more light-weight that the volatile data clouds model.  The downside of this method that it provides only crude support to detect the presence of (combinations of) tags in the environment.  Furthermore, the application needs to explicitly provide listeners to react to the events signalling the disconnection or reconnection of a tag.
-Having implemented both models, it remains unclear whether one of the models presented in this paper is to be preferred over the other.  As it stands, both models have shown to cater to different kinds of applications.  Moreover, when analysing the strengths and weaknesses of each of the models, they have shown to be largely complementary.
-The volatile data clouds model treats RFID tags as simple containers of data and aims at providing applications with expressive means to represent a collection of nearby tags which is constantly in flux.  Consequently, the model focusses on being able to expressively filter such collections and detect the presence of (a combination of) tags, to which the application can respond.  Using volatile data clouds as a means to represent nearby tags allows the programmer to abstract over the events that underly the discovery of new tags and the handling of their disappearance.  The cost incurred by using these abstractions is the need for a rather heavy-weight infrastructure to properly handle reactive computation.  Furthermore, this model considers RFID tags almost exclusively as a means to indicate the presence of a physical object in close proximity to the device that is running a particular application.
-The tag objects model on the other hand treats the contents of an RFID tag as a full-fledged object.  This makes the model capable of interacting naturally with tags that contain marshalled objects and makes it particularly interesting to model interactions with //active tags//.  Active tags are RFID tags which contain their own power source and are capable of independently performing (some limited form of) computation.  Another advantage is that the model only requires a service discovery mechanism and a means to buffer messages, which makes it considerably more light-weight that the volatile data clouds model.  The downside of this method that it provides only crude support to detect the presence of (combinations of) tags in the environment.  Furthermore, the application needs to explicitly provide listeners to react to the events signalling the disconnection or reconnection of a tag.
 In all likelihood, a programming model that fully leverages the advantages of a world teeming with tagged objects will incorporate elements of both models presented here.
-== Further Reading ==
+===== Further Reading =====
 * Distributed Objects for Real. Stijn Mostinckx, Andoni Lombide Carreton, Kevin Pinte, Wolfgang De Meuter. Technical report, 2010, Vrije Universiteit Brussel [[|pdf]]