The distributed pool of sensors senses the environment and transfers collected values immediately to the Application Server (AS) through the WoO gateway. After analyzing those real world environment data according to a predefined policy, AS detects an emergency fire situation. After the detection of a fire incident, the fire management team takes actions based on previously occurred similar types of fire incidents. These previous conditions data are retrieved from the log repository [9]. The emergency situation log is collected from ViOs and is stored in the log repository. We characterize a shopping mall fire incident to portray an emergency fire management system, but it is not limited to any specific type of organization or territory.

If simplicity and intuitiveness can be obtained for the end users��not only in using various applications while interacting with their physical surroundings, but also in creating new experiences via the same tangible real-world interactivity��then indeed, a potentially large market exists for actors in the service-enabling space, ranging from domain-specific application service providers down to Internet-of-things infrastructure interconnectivity providers and network operators. We expect that the dynamics of the long tail marketplace for applications (and application components) will result in the most relevant components become part of the enabling substrate. As such, today’s applications will evolve into tomorrow’s service infrastructure.2.?Related WorkSeveral attempts have been explored for incorporating applications and services into the real world.

Service Oriented Device & Delivery Architecture (SODA) [10,11] is an adaptation of a service-oriented architecture (SOA). The SODA approach for designing and building distributed software is to adapt a wide range of physical devices into disseminated IT inventiveness systems.SOA is a well-known IoT GSK-3 middleware solution approach. However, a widely recognized layered architecture is ignored in SOA and faces problems of abstracting objects’ functionalities and communications capabilities which are required for service composition. ITEA2 OSAMI commons [12,13] project have shown the basic design of SOA-oriented platforms. This knowledge can be applicable in the context of the global roadmap of the WoO.DiYSE [14,15] is another approach that is easy to use for normal users, but rarely suitable for professionals. Moreover, its object representation and business process model cannot handle complexity due to the lack of dynamicity in connecting objects as well as creating new services. Hence, WoO is intended to enhance that expertise to the professional level as well as to handle complex workflows for creating new services.