Differences

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

--- research:doforreal [2010/08/04 13:55]
stijnm separately
+++ research:doforreal [2010/08/04 14:25]
stijnm edited
@@ Line 23: / Line 23: @@
 </note>
-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 //tag objects// model conceived them as hosts for full-fledged objects.
+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 //tag objects// model conceived them as hosts for full-fledged objects, which encapsulate mutable state and provide their own methods.
-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.
+When interacting with these tag objects, one has to deal with the ephemeral nature of the connection between the mobile RFID-enabled application and any particular tag.  The concerns to be addressed when interacting with tag objects closely mimic those that govern
+the interaction with classic remote objects:
-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''.
+First of all, mobile RFID-enabled applications need a means to detect when a particular RFID tag 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.
-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.
+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.  Hence,  application programmers are provided with [[at:tutorial:actors#ambienttalk_actors_and_far_references|far references]] to the tag objects.  This design ensures that tag 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 tag comes in range again, these buffered messages will be flushed and forwarded to the tag.
-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//.
+By aligning tag 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//.
-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.
+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 (tag) objects.
 ===== Comparison =====

Ambient-Oriented Programming

User Tools

Site Tools

Differences

Page Tools