The concept of Web of Things (WoT) is to connect all sensors, actuators and other devices that are accessible through internet using open, standardized and widely used Web based protocols, interfaces and standards. This facilitates the use of these devices as everyday smart objects. SOAP and RESTful API, HTTP, WSDL among many others provide different approaches to meet the requirements of WoT. Similarly data management issues like, its representation, collection, storage, sharing, analysis, retrieval etc. also need proper investigation as in WoT, and it is known fact that data will be massive and heterogeneous. XML and JSON are some of the formats for data representation. These and other protocols and data formats are comprehensively in this document in next sections. Figure 3.9 provides overview of WoT concept.
Fig. 3.: Overview of WoT [WSAN69].
Reusing existing web architecture as platform, smart things act as web servers and are directly accessible as web services on the web. Two important issues to achieve this are how to integrate physical things to the web and how to make these physical things to offer web services.
Overall, WoT provides realization of IoT in a quick, easy to understand and open manner using standardized Web protocols and standards.
-
M2M communication allows machines (sensors, actuators) to perform specific tasks or relay information using different protocols (can be IP) over wired or wireless links. The machines can be static or mobile and usually have some intelligence mechanism in the form of program code. For example, interaction with smart meter, sensors inside a refrigerator or an IP camera using wired or wireless link (WLAN, Bluetooth, 6LowPAN, Zigbee, 4G, LTE, UMTS).
IoT allows us to interact with things around us, which can be intelligent or non-intelligent. With IoT it is possible to connect things using a gateway (e.g. smartphone, scanner etc.) and even make use of their contextual information in the form of time and location etc. For example, scanning a product bar code with a scanner, or checking validity of a movie ticket using NFC. IoT encompasses M2M communication but includes much more than that. There are more devices, protocols involved.
WoT is a means of connecting smart objects with embedded web services capabilities to world-wide-web. WoT allows reuse of existing web technologies to build new applications and services by attaching smart objects to the web. In this way smart things are abstracted as web services and are seamlessly integrated in the existing world of web. Hence services are discovered, composed and executed as needed. For example, the radiation map for general public generated using Geiger counter readings and Google Maps web service after 2011 tsunami in Japan. WoT is one possible way of realizing IoT making everything as a web service using web based technologies.
Conclusion
In this section, communication concept, paradigms and technologies relevant to WoO project are discussed. Wireless Sensor Networks are important to WoO project as sensors nodes are prominent type the objects this project is focusing on. Issues related to wireless sensor networks such as middleware technologies, service and network management are also discussed. Enabling technologies for this project like M2M, IoT and WoT are also discussed.
4.Common Architecture
In this section, common architectures for object communication are presented that can be useful for WoO project.
Common Object Request Broker Architecture (CORBA)
CORBA is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate. The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers.
CORBA allows clients to invoke operations on distributed objects, using Interface Definition Language (IDL) from OMG, without concern for their location, the programming language of the remote service, its OS, hardware platform (32 bit or 64 bit word size) or communications protocols (TCP/IP, IPX, FDDI, ATM). In simple terms CORBA enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services.
CORBA is a support framework of applications, libraries and services for making distributed procedure calls. A program on computer "C" (CORBA client) calls a function which is computed and processed on computer node "S" (CORBA server) and passes to it the function arguments. The function/method passes arguments and returns values as with any other C/C++ call except that it may be distributed across the network so that portions of the program may be executed on a remote machine.
CORBA's strength is that it allows platform and programming language interoperability. The interface between the client and server is defined by the CORBA IDL language which can be processed to produce code to support a variety of languages and platforms. The CORBA communication protocol, the language mappings and object model are standardized to allow this general inter-operability.
The remote function/method may start programs (fork/exec) on the remote computer or run remote services uniquely available to the remote computer and then return data.
The main advantages of CORBA are:
-
Object Location Transparency: The client does not need to know where an object is physically located. An object can either be linked into the client, run in a different process on the same machine, or run in a server on the other side of the planet. A request invocation looks the same regardless, and the location of an object can change over time without, breaking applications.
-
Server Transparency: The client is, as far as the programming model is concerned, ignorant of the existence of servers. The client does not know (and cannot find out) which server hosts a particular object, and does not care whether the server is running at the time the client invokes a request.
-
Language Transparency: Client and server can be written in different languages. This fact encapsulates the whole point of CORBA; that is, the strengths of different languages can be utilized to develop different aspects of a system, which can interoperate through IDL. A server can be implemented in a different language without clients being aware of this.
-
Implementation Transparency: The client is unaware of how objects are implemented. A server can use ordinary flat files as its persistent store today and use an OO database tomorrow, without clients ever noticing a difference (other than performance).
-
Architectural Transparency: The idiosyncrasies of CPU architectures are hidden from both clients and servers. A little-endian client can communicate with a big-endian server with different alignment restrictions
-
Operating System Transparency: Client and server are unaffected by each other's operating system. In addition, source code does not change if CORBA-related code needs to be ported from one operating system to another.
-
Protocol Transparency: Clients and servers do not care about the data link and transport layer. They can communicate via token ring, Ethernet, wireless links, ATM (Asynchronous Transfer Mode), or any number of other networking technologies.
Some identified drawbacks of CORBA are
-
Describing services require the use of an IDL which must be learned. Implementing or using services require an IDL mapping to your required language - writing one for a language that isn't supported would take a large amount of work.
-
IDL to language mapping tools create code stubs based on the interface - some tools may not integrate new changes with existing code.
-
CORBA does not support the transfer of objects, or code.
Share with your friends: |