Chapter 4 Design Issues
4.1. Integration of Home Networks
4.1.1. A Universal Development Procedure
To provide a universal procedure to control household appliances, we have designed an interface, which is mentioned above as IAController Interface. The interface defines the specification of the abstract objects; it abstracts the service properties, action, and state variable objects and provides mapping information. No matter which original protocol the service belongs to, IAC Platform could map the physical service into the abstract service of the interface. Thus, developers write applications without taking care of the protocol details.
IAController Interface mainly provides the suitable API for programmers to develop interaction application of home appliances. We first define the interfaces of service, action, and state variable, and the relationship of them, and then design how to map these objects to physical services. At last we design a model to handle the event messages. In addition, IAController Interface also regulates the procedures of service discovery and descriptor locating. The issues of descriptor locating and service discovery would be taken up in Section 4.1.1.1.
IAController Interface is used to integrate services. To design flexible interfaces,
we have studied several network protocols first, focusing on the similarity of capability and the difference of their implementation. The steps of accessing the home network service could be classified into four parts.
z Discovering the required Service:
Search for the desired service by matching the attributes or capabilities of the service.
z Getting service information:
The service information contains action details, state variable name, and etc.
z Invoking action:
Clients send command to execute functions.
z Event model:
Service sends notification to clients actively, the major goal is to inform the change of the service state.
According to the conclusions we got above, we have designed the class diagram of IAController Interface indicated as Figure 5-1. In the beginning, developers could use Discovery object to search for services, and get the required abstract service objects. The abstract service object usually contains two lists, ActionList and StateVariableList, which include Action and StateVariable objects. These two types of objects are also abstract objects, described in service descriptors. Developers could use above three objects (Service, Action, StateVariable) to invoke basic operations, as the steps described in Section 5.2.2. Now we discuss the concept of each interface.
Figure 4-1 Class diagram of IAController Interface
4.1.1.1. Discovery
Now we come to the issues about steps of service discovery. First, we get the service descriptor with descriptor locator. After obtaining the descriptor, IAC Platform would parse it and produce a abstract service object. The procedure of service discovery is illustrated as Figure 4-2.
Main Discovery DescriptorLocator ServiceBuilder
getService(DescriptionLocator)
getDescription()
Document
parse(Document)
Service
Service
Figure 4-2 Sequence diagram of discovering service
There is a method getService in class Discovery. The method needs a parameter which’s type is DescriptorLocator; the class DescriptorLocator contains a method named getDescriptor which return an org.w3c.dom.Document object. After getting the
Document object, developers could use class ServiceBuilder to parse the service
descriptor and create abstract objects, and then deliver the service object as return value of method getService.4.1.1.2. Service
Service object contains the abstract information of service properties, such as
service ID, service type, and so on. Bedsides, it also has two lists which contain abstract action and state variable objects. The relationship of Action, StateVariable, and Service is indicated as Figure 4-3.It deserves to be mentioned that we designed Service with an abstract concept.
The properties of the service mainly come from the service descriptor. With Service
objects, developers could design application to control appliances without carrying about the implementation of the protocols. Therefore, it could reduce the development effort for the developers. They could use the unified interface to access all appliance services.
Figure 4-3 The relationship of the Service, Action, and StateVariable
4.1.1.3. Action
The most significant method in class Action is invoke. It is used to send action command to service in order to interact with home appliances. Before sending an action command, developers have to collect all parameters the action requires, and put these parameters into a Dictionary object.
The difference between Service and Action is that the implementations of Action would be implemented according to varied protocols. Because the procedure of invoking action depends on protocol mechanisms, each protocol should have its own action implementation. Figure 5-4 indicates the relationship of the interface Action and its implementations.
<<interface>>
Figure 4-4 The relationship of the Action and its implementation
4.1.1.4. StateVariable
The design of StateVariable is similar to Action. The main function of
StateVariable object is getting the current state of the service. Similarly, developers
could change the state of the service by setting the state variable value.4.1.1.5. Listener
We also have to design a mechanism to handle the event messages sent from services. Events are mapped and delivered to ARTApps according to the whiteboard model. The ARTApp interested in receiving the events registers an object implementing the Listener interface (referring to Figure 4-1). A filter could be set to limit the events for which ARTApp is notified.
If an ARTApp is registered with a property named art.iacontrol.filter with the value of instance of a Filter object, the listener is only notified for matching events.
If an event is generated, the notify method is called on all registered ARTApps for which the optional filter matched for that event. If no filter is specified, all events
must be delivered. If the filter does not match, the IAC Platform must not notify the ARTApp.
One or multiple events are passed as parameters to notify (String, Dictionary) method. The Dictionary object holds a pair of StateVariable objects that triggered the event and an Object for the new value of the state variable.
Event model is an optional mechanism of IAC Platform. It is implemented for those protocols that are suitable for event model.