The Reader Framework uses the Configuration Framework to expose readers at services to the rest of the edge server

Overview

In order for the edge server to be able to communicate with a particular kind of tag sensor (RFID reader, barcode scanner, etc.), a new reader plugin must be developed. The reader plugin consists of two main components: Readers and Commands. This section explains how Readers work. The next section will explain Commands.

Each Reader Plugin will have a ReaderFactory for that produces Readers for that plugin. For example, the Alien9800 Plugin will has an Alien9800ReaderFactory that produces Alien9800Readers. The ReaderFactory is a ServiceFactory (see the explaination on Configuration). Readers are configurations (and therefore extend RifidiService), so they are persisted into an ini file by the ConfigurationService and are exposed over JMX. Readers have properties (such as IP, port, and AntennaPower). Readers themselves do not represent a connection to a physical sensor device (such as a networked RFID reader). Instead Readers produce Session objects that handle the physical connection.

AbstractReader

The AbstractReader is the base class that all other readers should extend. The AbstractReader extends RifidiService, so it will be persisted using the ConfigurationService and exposed via the JMXService. The Reader's main purpose is to create and manage Sessions, as well as to act as a storage for properties. The most important methods in the AbstractReader is createReaderSession() which will produce a new Session and applyPropertyChanges() which will use a current session to send property changes to a reader. It is up to the particular reader as to how sessions are handled. For example, some reader devices (such as the Alien9800) only allow one physical connection to it at a time. Others (such as a Symbol) allow multiple connections. Similarly, the particular readers also decide how to handle the applyPropertyChanges() method.

AbstractReaderFactory

The AbstractReaderFactory is the base class that all ReaderFactories should extend. It provides no functionality beyond that of the AbstractReaderFactory

ReaderSession

The ReaderSession handles a single connection to a physical sensor device. It also acts like a command executor. Clients of the ReaderSession submit commands to the session for execution. Commands can either be submitted to run just once or they can be scheduled to run repeatedly. To submit a command that is only run once, use the single-argument submit method. If you want the command to be execute repeatedly, use the submit command that has a period and timeunit argument.

The ReaderSession provides the base abstract method signatures The AbstractReaderSession class implements the methods that have to do with managing commands (i.e. submit, kill, status, and currentCommands). The connection functionality is left up to the concrete reader.

Because many readers will use a TCP connection to connect to a reader, a base class called AbstractIPReaderSession is provided. This class implements the necessary code to open up a socket, set up read and write threads to read and write from the socket, and monitor the socket for connection failure. To use the AbstractIPReaderSession, the concrete session will need to implement a method called onConnect() which is called after a socket connection is made and allows the session to take required whatever required actions are necessary to establish a logical connection, such as sending a username and password. In addition, the isMessage() method must be implemented. This method is called whenever a new byte is read from the socket. This method should return with a logical message object for that kind of reader if the byte is the last byte necessary to form a complete logical message. It should return null otherwise.

Session State

Sessions have four distinct states in which they can be: Created, Connecting, OnConnect, and Processing. Each reader can decide for itself what the session states mean for that reader. For the TCPSession, the meaning is as follows: When a session if first created, it is in the Created State. After the connect() method is called, the onConnect() method may be called (if the session is an AbstractIPReaderSession). If that succeeds, the reader is in the processing state and will execute commands that are submitted to it. If at any time the connection fails, the session will go back to the conecting state where it enters the retry loop, as goverened by the retry count and retry wait variables. If the retry count eventually runs out of attempts, the session will move back to the created state.