research:rfid
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
research:rfid [2010/07/27 17:56] – kpinte | research:rfid [2011/09/12 18:50] (current) – kpinte | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
// | // | ||
[[http:// | [[http:// | ||
+ | < | ||
+ | This page is under construction, | ||
+ | </ | ||
==== RFID-enabled Library ==== | ==== RFID-enabled Library ==== | ||
- | The RFID-enabled library is a //mobile RFID-enabled application// | + | The RFID-enabled library is a //mobile RFID-enabled application |
== Towards naturally expressing RFID applications == | == Towards naturally expressing RFID applications == | ||
Line 31: | 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, | + | 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, |
- | - **Addressing physical objects** RFID communication is based on broad- casting | + | - **Addressing physical objects** RFID communication is based on broadcasting |
- **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. | + | - **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. |
- | - **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 | + | - **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 |
- **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. | ||
Line 125: | Line 128: | ||
== Multiway References == | == Multiway References == | ||
+ | |||
+ | {{: | ||
Line 156: | 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. [{{: | + | * 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/rfid.1280246186.txt.gz · Last modified: 2010/07/27 17:57 (external edit)