# A Web of Things-Based Emerging Sensor Network Architecture for Smart Control Systems
## 4 Proposed Framework
### Service Representation over the Web  
The Web provides ubiquitous application layer functionality to the smart home objects. Therefore, it is essential to provide a communication medium which directly links a home user to the smart home objects. In this section, we provide a Web-oriented architecture for smart home objects enabling them to speak the same language as other resources do on the Web. We have also thoroughly described the working mechanism of the restful API and show how the RESTful API can be used to integrate the smart home services with the Web. The dramatic rise of the connected devices coined the concepts of IoT and WoT. In general, the devices in the WoT adhere to two basic conditions i.e. : (1) implementing TCP/IP protocol stack over Ethernet or Wi-Fi networks and (2) implementing a Web server supporting the HTTP 1.1 protocol [3]. However, not all the embedded devices comply with the aforementioned  
Figure 2: Event management system for in-house controls and remote smart home user controls. two requirements due to computational, memory, and bandwidth limitations, despite the fact that the feasibility of adopting TCP/IP protocol in resource-constrained devices is increased with the recent research conducted on embedded devices, i.e., 6 LoWPAN architectures, sensors, and devices with Wi-Fi support, embedded devices with built-in HTTP servers, and embedding Web servers on constrained devices. Nevertheless, the seamless integration of embedded devices into the Web is not guaranteed, since not all the embedded devices can meet the HTTP and TCP/IP demands. Thus, we propose a smart gateway architecture to compensate the HTTP and TCP/IP requirements of the non-adhering embedded devices, i.e., ZigBee coordinators, ZigBee sensors, and Bluetooth sensors. The smart gateway acts as a mediator between the Internet and smart things. Subsequently, the smart gateway provides transparent web processes, while hiding the internal details of the network from the remote smart home user. The proposed smart gateway consists of two layers, namely the Transport Module (TM) and the Device Service Module (DSM). The combination of TM and DSM creates the device controller for embedded devices operating on proprietary protocols such as ZigBee and Bluetooth. The bottom layer of the architecture enables the gateway to communicate via the appropriate communication protocol. In the proposed smart home scenario, coordinators and sensors use the ZigBee protocol for communication. ZigBee is a proprietary communication protocol that has been developed based on the IEEE 802.15.4 protocol. The DSM of the architecture resolves the proprietary service protocols of the devices and sensors. Further, device functionality mapping to RESTful APIs take place in the DSM layer. The smart gateway uses RESTful APIs to share ZigBee sensor data, which reports either environmental parameters, i.e., temperature, humidity, motion or data and functionalities of the attached embedded devices, i.e., device status or current energy consumption. Thus, the RESTful API architecture (RA) is introduced into the proposed architecture. The RA is responsible for binding the URI to the functionalities of virtual smart things on the Web, so that the remote smart home user can request home services, which generates a self-describing HTTP request via the MS of the house. The HTTP-enabled Web server is the other component of the proposed framework. The remote user request is received by the Web server and passed to the RA and smart gateway, respectively. Indeed, the smart gateway plays a vital role in the proposed WoT architecture along with RA and Web server, to ensure that non-web devices connect with the remote users via the Web. For example, the remote smart home user makes an HTTP request to get current temperature of the kitchen. The web server passes the HTTP request: /system/MS/coordinators/4/sensors/3/get_temp() received via the RESTful API. Sequentially, the appropriate sensor is located from the self-describing HTTP request.