Command Framework

From RifidiWiki

Jump to: navigation, search

Overview

In addition to ReaderFactories and Readers, a reader plugin for the edge server will need to implement a CommandConfigurationFactory and CommandConfigurations.

Commandoverview.jpg

The basic structure of the command framework is similar to that of the reader framework. The biggest difference is that ReaderFactories only produce one type of Reader. In contrast, A CommandConfigurationFactory can produce multiple kinds of CommandConfigurations. This is because there may be many kinds of commands that could execute on a session. For example, one command might get tags from a reader. Another command might set a GPI line to high. Since these are fundamentally different commands, it is necessary to have separate CommandConfigurations. Like with the reader framework, the CommandConfigurationFactory is a ServiceFactory (this time it extends AbstractMultiServiceFactory). The CommandConfiguraitons are RifidiServices, and therfore are exposed via JMX and are persisted.

CommandConfiguraitonFactory

The CommandConfigurationFactory produces CommandConfigurations. It extends AbstractMultiServiceFactory so that it can produce multiple kinds of CommandConfigurations. It adds one method to the base AbstractMultiServiceFactory: getReaderFactoryID(). This is method returns the ID of the ReaderFactory that produces readers which commands produced from the reader factory run on. This allows CommandConfigurations to be associated with a particular kind of Reader. For example, suppose there are two reader plugins available: Alien9800 and SymbolXR400. This makes sure that Alien commands can be associated with Alien readers and Symbol commands can be associated with Symbol readers.

CommandConfigFactory.jpg

CommandConfiguration

The AbstractCommandConfiguration is the base class that all concrete CommandConfigurations should extend. CommandConfigurations produce configured Commands. Like Readers, they extend RifidiService and have properties that are exposed via JMX. The important method in this class is getCommand() which creates a new configured Command which can be given to a Session for execution.

CommandConfig.jpg

Commands

Command is the base abstract class that all Commands should extend. It extends Runnable, but does not provide an implementation for the run method, so that needs to be provided by the author of the concrete Command. One important convention that should be followed is that the run method should execute quickly. For example, it should not contains a while loop that continuously executes a command to get tags from the sensor device. In order to achieve such functionality, commands should be submitted to sessions with a repeat value and therefore will be repeatedly executed. Commands will have access to two objects inside the run method: The first is the Session that the command is executing on. This is because the command will need to communicate with the physical sensor device, and the session provides that functionality. The other object is the JMSTemplate which the command should use to place any tag data that it reads.

Command.jpg

An Example Command:

public class ExampleCommand extends Command {

	public ExampleCommand(String commandID) {
		super(commandID);
	}

	@Override
	public void run() {
		try {
			// create a new message
			ByteMessage message = new ByteMessage("get tags".getBytes());

			// send message to sensor
			((AbstractIPReaderSession) super.readerSession)
					.sendMessage(message);

			// receive response
			final ByteMessage response = ((AbstractIPReaderSession) super.readerSession)
					.receiveMessage();

			// put message on JMS Queue
			super.template.send(super.destination, new MessageCreator() {
				@Override
				public Message createMessage(Session arg0) throws JMSException {
					return arg0.createTextMessage(response.message.toString());
				}

			});
		} catch (IOException e) {
			System.out.println("IO Exception while executing");
		}

	}

}
Personal tools