Ambient-Oriented Programming

User Tools

Site Tools

Trace:
research:rfid

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:rfid [2010/07/27 17:15] – kpinteresearch:rfid [2011/09/12 18:50] (current) – kpinte
Line 1: Line 1:
-====== Software Abstractions for the Development of Mobile RFID-enabled Applications ======+====== Distributed Object-Oriented Programming with RFID Technology ======
 //Representing RFID-tagged physical objects as **mutable software objects**//. //Representing RFID-tagged physical objects as **mutable software objects**//.
 +
 +[[http://soft.vub.ac.be/soft/members/kevinpinte|Kevin Pinte]] and [[http://soft.vub.ac.be/~alombide|Andoni Lombide Carreton]]
 +
 +<note>
 +This page is under construction, some sections are not yet completed. Please refer to the [[:research:rfid#further_reading|futher reading]] section for a full text.
 +</note>
  
 ==== RFID-enabled Library ==== ==== RFID-enabled Library ====
-The RFID-enabled library is a //mobile RFID-enabled application// and illustrates the kind of application we target. The application runs on a mobile device, such as a smartphone and shows the books that are in the vicinity of the user and allows certain operations to be performed on them. Users can attach a small review message to a book, rate a book or associate keywords with the book, etc. This data is all stored on the book directly, using RFID tag(s). The application lets the user also filter the books based on rating or comparison with a keyword profile describing the user's preferences. For example, the user could just swipe his smartphone over a shelf of books and discover which books on the shelf are must-read books!+The RFID-enabled library is a //mobile RFID-enabled application (MoREnA)// and illustrates the kind of application we target. The application runs on a mobile device, such as a smartphone and shows the books that are in the vicinity of the user and allows certain operations to be performed on them. Users can attach a small review message to a book, rate a book or associate keywords with the book, etc. This data is all stored on the book directly, using RFID tag(s). The application lets the user also filter the books based on rating or comparison with a keyword profile describing the user's preferences. For example, the user could just swipe his smartphone over a shelf of books and discover which books on the shelf are must-read books!
  
 == Towards naturally expressing RFID applications == == Towards naturally expressing RFID applications ==
Line 28: Line 34:
  
 ==== Requirements ==== ==== Requirements ====
-To align physical objects tagged with writable RFID tags as true mutable software objects we model these objects as proxy objects acting as stand-ins for physical objects. For this model to be applicable to mobile RFID- enabled applications, it must adhere to the following requirements:+To align physical objects tagged with writable RFID tags as true mutable software objects we model these objects as proxy objects acting as stand-ins for physical objects. For this model to be applicable to mobile RFID-enabled applications, it must adhere to the following requirements:
  
-  - **Addressing physical objects** RFID communication is based on broad- casting a signal. However, to be able to associate a software object with one particular physical object, it is necessary to address a single designated physical object.+  - **Addressing physical objects** RFID communication is based on broadcasting a signal. However, to be able to associate a software object with one particular physical object, it is necessary to address a single designated physical object. Object identities of digital objects should always correspond to object identities of physical objects.
   - **Storing application-specific data on RFID tags** Since mobile RFID- enabled applications do not rely on a backend database, the data on the RFID tags should be self-contained and stored on the writable memory of the tags.   - **Storing application-specific data on RFID tags** Since mobile RFID- enabled applications do not rely on a backend database, the data on the RFID tags should be self-contained and stored on the writable memory of the tags.
-  - **Reactivity to appearing and disappearing objects** It is necessary to observe the connection, reconnection and disconnection of RFID tags to keep the proxy objects synchronized with their physical counterparts. Differen- tiating between connection and reconnection is important to preserve the identity of the proxy object. Furthermore, it should be possible to react upon these events from within the application. +  - **Reactivity to appearing and disappearing objects** It is necessary to observe the connection, reconnection and disconnection of RFID tags to keep the proxy objects synchronized with their physical counterparts. Differentiating between connection and reconnection is important to preserve the identity of the proxy object. Furthermore, it should be possible to react upon these events from within the application. 
-  - **Asynchronous communication** To hide latency and keep applications responsive, communication with proxy objects representing physical objects should happen asynchronously. Blocking communication will freeze the ap- plication as soon as one physical object is unreachable.+  - **Asynchronous communication** To hide latency and keep applications responsive, communication with proxy objects representing physical objects should happen asynchronously. Blocking communication will freeze the application as soon as one physical object is unreachable.
   - **Fault-tolerant communication** Treating communication failures as the rule instead of the exception allows applications to deal with temporary unavailability of the physical objects and makes them resilient to failures. For example, read/write operations frequently fail due hardware phenomena.   - **Fault-tolerant communication** Treating communication failures as the rule instead of the exception allows applications to deal with temporary unavailability of the physical objects and makes them resilient to failures. For example, read/write operations frequently fail due hardware phenomena.
  
 ==== Software Abstractions ==== ==== Software Abstractions ====
  
-Here we will illustrate our model by presenting small code snippets that, in the end, will bring us to the RFID-enabled library application  above.+Here we will illustrate our model by presenting small code snippets that, in the end, will bring us to the RFID-enabled library application  above. We will not go in full detail, we merely want to give a look and feel of RFID programming in our model. Please refer to the [[:research:rfid#further_reading|further reading]] section for extensive documentation.
  
 == RFID tags as mutable proxy objects == == RFID tags as mutable proxy objects ==
  
-Physical objects are represented using a digital counterpart. This is done by simply defining an object with appropriate methods and slots.+Physical objects are represented using a digital counterpart. This is done by simply defining an object with appropriate methods and slots. The code example shows the definition of a book object in AmbientTalk.
  
 <code> <code>
Line 61: Line 67:
 } taggedAs: Book; } taggedAs: Book;
 </code> </code>
 +
 +In this example a book contains an ISBN, a title and a set of review messages. There are two methods that allow to change the title and to add a review. By annotating the message with //Mutator// the programmer specifies when the software object is to be synchronized with the RFID tag.
 +
 +Discovering books that are tagged with such an object happens by installing a discovery handler. To react upon disconnection or reconnection of a book, similar handlers are used:
  
 <code> <code>
Line 69: Line 79:
 </code> </code>
  
 +The example above uses //whenever:discovered:// to install a block of code that will be executed every time a book is discovered in the vicinity of the user. The variable //book// is a remote reference to the book object on the tag. Within this block, two more blocks are installed that are executed when the book disappears or reappears in range of the user. We will later use these blocks to show or hide books in a list in the GUI.
 +
 +The [[at:tutorial:actors#ambienttalk_actors_and_far_references|remote reference]] to a book can be used to asynchronously access its slots or methods. The snippet below shows a call to a method that retrieves the title of a book:
 <code> <code>
 when: book<-getTitle() becomes: { |title|  when: book<-getTitle() becomes: { |title| 
Line 75: Line 88:
 system.println("here first!"); system.println("here first!");
 </code> </code>
 +This method invocation is [[at:tutorial:actors#asynchronous_message_sending|asynchronous]], this means that the sending of the message immediately returns with a [[:at:tutorial:actors#futures|future]]. On this future we can install a block of code that is executed when the return value is ready. For the code above, first "here first!" will be printed, only afterwards the title of the book.
  
 +In case the book is not available at the time of the message send, no exception is raised but the message is simply buffered. When the book reappears in range the message is delivered and will be processed. The programmer can control the amount of time a message is buffered. For example, if the book does not respond within 10 seconds, the programmer might no longer be interested in the result. The code below exemplifies how this can be achieved by annotating the message send with a //Due// annotation.
  
 <code> <code>
Line 85: Line 100:
 }; };
 </code> </code>
 +
 +If the message send does not yield a result within 10 seconds, the catch block will be executed.
  
 == Ambient References == == Ambient References ==
 +
 +RFID tags very frequently appear in groups of the same kind of item. For example, the set of books, or in a supermarket a set of jars of jam, etc. Thanks to [[:research:ambientrefs|ambient references]] it is easily possible to address a set of items of the same type. Furthermore, we can specify a number of constraints the set of items has to satisfy:
  
 <code> <code>
Line 94: Line 113:
 }; };
 </code> </code>
 +
 +On the first line, we have an ambient reference //books// that designates the set of all books that are detected. Note that this set changes dynamically when the user moves about and books become available or unavailable.
 +
 +The last three lines define //computerScienceBooks//,  an ambient reference to the set of books that belong to the "Computer Science" category. This second ambient reference is a subset of the //books// ambient reference.
  
 <code> <code>
Line 105: Line 128:
  
 == Multiway References == == Multiway References ==
 +
 +{{:research:typesoftags.png?400|:research:typesoftags.png}}
  
  
Line 130: Line 155:
 ==== Conclusions ==== ==== Conclusions ====
  
-By implementing an example mobile RFID-enabled application, we have ob- served that the requirements that we set forward for programming mobile RFID- enabled applications are met in the following ways:+By implementing an example mobile RFID-enabled application using our model of aligning physical objects with mutable proxy objects we have observed that the requirements that we set forward for programming mobile RFID-enabled applications are met in the following ways:
   - **Addressing physical objects** The implementation of the application shows that mobile RFID-enabled applications can be written in an object-oriented fashion, where application-level proxy objects uniquely represent physical objects in one’s physical environment.   - **Addressing physical objects** The implementation of the application shows that mobile RFID-enabled applications can be written in an object-oriented fashion, where application-level proxy objects uniquely represent physical objects in one’s physical environment.
   - **Storing application-specific data on RFID tags** The data needed to con- struct these proxy objects is stored on the RFID tags themselves.   - **Storing application-specific data on RFID tags** The data needed to con- struct these proxy objects is stored on the RFID tags themselves.
Line 136: Line 161:
   - **Asynchronous communication** Interacting with physical objects is achieved by using the message passing metaphor on the proxy objects, by means of asynchronous message passing and asynchronous signaling of return values.   - **Asynchronous communication** Interacting with physical objects is achieved by using the message passing metaphor on the proxy objects, by means of asynchronous message passing and asynchronous signaling of return values.
   - **Fault-tolerant communication** Communication failures are considered the rule rather than the exception. Failures that must be considered permanent are detected and raise the appropriate exceptions.   - **Fault-tolerant communication** Communication failures are considered the rule rather than the exception. Failures that must be considered permanent are detected and raise the appropriate exceptions.
 +
  
  
 ==== Further Reading ==== ==== Further Reading ====
-  * Distributed Object-Oriented Programming with RFID Technology. Andoni Lombide Carreton, Kevin Pinte, Wolfgang De Meuter. In Lecture Notes in Computer Science, vol. 6115, Eliassen F, Kapitza R (eds.), 2010; 56–69. [{{:research:mobile_rfid.pdf|download}}((The original publication is available at [[http://www.springerlink.com|www.springerlink.com]].))].+  * Distributed Object-Oriented Programming with RFID Technology. Andoni Lombide Carreton, Kevin Pinte, Wolfgang De Meuter. In Lecture Notes in Computer Science, vol. 6115, Eliassen F, Kapitza R (eds.), 2010; 56–69. [{{:research:mobile_rfid.pdf|download}}((The original publication is available at [[http://www.springerlink.com/content/517t6667573653m2|www.springerlink.com]].))].
          
research/rfid.1280243717.txt.gz · Last modified: 2010/07/27 17:16 (external edit)