3.3.1 Operations
In the proposed platform, device functionality is expressed in terms of unique operations. The Operation class and its subclasses are used to encompass device functionality as a logical abstraction. This class has appropriate mem-bers and getter-setter methods for passing in the necessary arguments for the operation as well as extracting the result of the operation. For example, the source code for theSetOperationStateoperation can be seen in figure 3.2.
Using this operation, a smart service may turn off or on a device.
public class SetOperationState extends Operation{
private OperationState requestedState = OperationState.UNKNOWNERROR;
OperationState resultingState = OperationState.UNKNOWNERROR;
public SetOperationState(OperationState newState) { this.requestedState = newState;
}
public OperationState getOperationState(){
return this.resultingState;
}
public void setOperationState(OperationState newState){
this.resultingState = newState;
}
@Override
public SetOperationState applyToDevice(DeviceInterface aDevice) { aDevice.doOperation(this);
return this;
}
public OperationState getRequestedState() { return requestedState;
} }
Figure 3.2: Operation Example
The passing of appropriate arguments for this operation can be achieved during the creation of an instance of this operation i.e. pass the desired opera-tion state as an argument to the constructor. Then, when the device processes this operation, it can extract the desired state using thegetRequestedState() method. After this operation has been processed, the resulting state is stored using the setOperationState()method and can be later retrieved by the application using the getOperationState() method.
For each function provided by the device an appropriate subclass of the Operation must be created. However, since these operations are used to describe the functionality of devices, great care must be taken in their design and usage. Each operation subclass must express a unique and well-defined functionality of a device. Device implementers have to select the appropriate set of operations to express the functionality of their devices and be careful not to misinterpret the meaning of an operation.
3.3.2 Device Implementation
A device that is part of the home service platform is associated with sev-eral pieces of information such as location, position and others. However,
public interface DeviceInterface {
public void doOperation(Operation operation);
Access getNeededPermissions(Operation operation);
Collection<Class<? extends Operation>> getSupportedOperations();
}
Figure 3.3: Device Interface and its main methods.
the main implementation of a device relies heavily on the three methods 1 presented in Fig. 3.3.
These three functions constitute the core of the implementation for a device. A smart service may interact with a device by:
1. performing an operation,
2. getting the required access rights necessary to perform an operation, 3. getting a list of all the currently supported operations for this device.
The generic doOperation()method is the main method through which a device performs a given Operation. This method may throw exceptions in case the following cases:
1. the device does not support the requested operation, 2. insufficient access rights for the requested operation, 3. network communication failure,
4. operation timed out.
Internally, each device implementation registers operation handlers for the types of operation it supports. If present, the appropriate operation handler will be invoked for the requested operation. If such a handler does not exist, an UnsupportedDeviceOperation exception will be thrown. With this modeling approach, to implement a new device it is enough to implement and register the appropriate operation handlers to a subclass of DeviceImpl, an abstract class used as the base for all device implementations.
The getNeededPermissions() method is a way to inquire about the necessary access rights in order to perform an operation. It is used internally by the platform in order to ensure that the smart service which invoked an operation on a device has sufficient access rights to perform it. Furthermore,
1The interface presented here is actually spread into several interfaces and the excep-tions that can be thrown have been removed.
public class PowerStateAdapter extends DeviceAdapter{
public PowerStateAdapter(){
requiredOperations.add(GetOperationState.class);
requiredOperations.add(SetOperationState.class);
}
public void turnOff(){
this.doOperation(new SetOperationState(OperationState.OFF));
}
public void turnOn(){
this.doOperation(new SetOperationState(OperationState.ON));
}
public OperationState getOperationState(){
return new GetOperationState().applyToDevice(this).getOperationState();
} }
Figure 3.4: Adapter Interface Example - Power State Adapter
it can also be used by smart services to find out if there is a need to elevate their access rights before invoking that specific operation.
Finally, the getSupportedOperations() method is used to inquire a device about the operations it supports. This information can be used as criteria by a smart service to select appropriate devices for use or filter un-wanted devices during search.
3.3.3 Adapter Interfaces
Although the API offered for interacting with devices is simple, invoking an operation on a device requires several steps: create an instance of the opera-tion, set the appropriate arguments, perform the actual invocaopera-tion, check the results and handle any exception that might have occurred. All the above steps are, although necessary, a tedious and sometimes error prone task. Fur-thermore, due to the fact that a large number of operation subclasses exist, it is easy to invoke an unsupported operation on a device if due diligence is not exercised.
To simplify interaction with devices, a special set of adapter interface classes have been introduced. The platform provides a number of typical adapter interfaces. If an appropriate adapter interface is not offered by the platform, a smart service is free to implement and use its own adapter in-terfaces. A simple example for a service that is interested in controlling the power state of a device can be seen in Fig. 3.4.
This power state adapter interface offers three methods intended to be
used by a service: a turnOff() method, a turnOn()method and finally a method to get the current operation state, named getOperationState(). Before it can be used, a device must be set as the “backing device” for the adapter interface. After this step is complete, the smart service is free to invoke any of the method provided by the adapter. Adapters are reusable and the backing device can be changed at will, at any time.
The major bulk of the implementation of adapter interfaces happens in-side the DeviceAdapter class. This class is responsible for the error han-dling. The programmer has a choice regarding the handling of exceptions:
either handle them through traditional try/catch blocks as it is common in Java, or perform “C style” error checking with the help of adapter inter-face. Even a mixed approach is possible; have only specific exceptions be
“silenced” and let important exceptions propagate through the stack until handled.
Finally, another important aspect of an adapter interface is that it main-tains a list of the necessary operations that a device must support in order to be usable by the adapter interface. This supported operation list can also be used as a search criteria; a smart service can query the platform for a list of devices that can potentially be used through the specified adapter interface.
Although the use of adapters is, strictly speaking, not necessary, their use is highly encouraged as they simplify smart service development sub-stantially. More details regarding the usage of the adapter interface APIs will be introduced in section 3.5.