com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_link3' is unknown.

Architecture

WSO2 IoT Server offers an extensible framework for:

  • Device manufacturers to write plugins for various types of devices.
  • Device owners to enroll their devices and start managing them.
  • Enterprises looking to manage employees’ mobile devices (enterprise mobility management). 

WSO2 IoT Server is built on top of WSO2 Connected Device Management (CDM) Framework, which in turn is built on the WSO2 Carbon platform.  The following sub sections explain the WSO2 IoT Server architecture and how it functions.

WSO2 IoT Server component architecture

A WSO2 IoT Server deployment comprises of the following high-level components:

The following table explains how each component in the WSO2 IoT Server architecture functions as depicted in the above figure. 

Connected Device Management Core

The Connected Device Management (CDM) core manages and controls all the functions of WSO2 IoT Server. It is designed with many extensions. Therefore, you can extend and customize most of its functions. The CDM core consists of the following components.

Click on a component and navigate to the respective documentation section for more details.

Device Management Plugins

WSO2 IoT Server is designed as a pluggable architecture. Therefore, it is easy to introduce new device types to WSO2 IoT Server.

A plugin is not mandatory when creating a new device type. You can connect most of the IoT devices to WSO2 IoT Server without using an external plugin. A plugin is useful when you need to perform complex operations.

You can write a new device type using any of the following methods:

  • Want to create a device type in one go? You can now create your own device type that includes the APIs, transports, UI and more, using the device management console or APIs. For more information, see  Creating a New Device Type.
  • Does your device have common functionalities similar to our sample device types? If yes, see  Writing Device Type via the Template.
  • Does your device require special functions and need to be customized to meet a given requirement? See  Writing Device Plugins via Java Code.
Transports

Transports are required for the server to communicate with the devices and for the devices to communicate with the server. For example in WSO2 IoT Server, the server communicates with the iOS devices via the APNS transport and the devices communicate with the server using the HTTP transport. For more information on how the transports work, see Writing Transport Extensions.

The server uses push notifications to communicate with the device. By default, WSO2 IoT Server has implemented push notification providers for MQTT, XMPP, FCM, and APNS. You can write your own push notification provider too. For more information, see Adding a Push Notification Provider.

API

WSO2 IoT Server is fully API driven. All the APIs are equipped with industry standard swagger annotations. Therefore, stub or client generation can be done easily.

The APIs are fully secured. If you want to carry out an operation on a device, two levels of authorization take place:

  • Checks if the user is authorized to access the APIs.
  • Checks if the user is authorized to carry out the operation on the selected device.

The diagram shown below lists out the REST APIs provided by default in WSO2 IoT Server. That's not all, you are able to write your own APIs for your device type using WSO2 IoT Server due to its pluggable architecture.

Authentication and Authorization

When using WSO2 IoT Server in your enterprise, security, and integration are important as you need to store all the user data and device data in the server, and the devices store confidential information about your business. Further, security is a must when integrating WSO2 IoT server with other applications, user interfaces, and when exposing its capability to the outside world.

WSO2 IoT Server provides the following security protocols for authenticating and authorizing users and devices:

Further, to authenticate and authorize the APIs, WSO2 IoT Server uses scopes. A scope has a permission assigned to it. For more information, see Device Management API Scopes.

Analytics and Analytics Plugin

Analysing the data gathered by your devices is important for you to identify patterns and predict future trends. Therefore, by default WSO2 IoT Server combines real-time, batch, interactive, and predictive (via machine learning) analysis of data into one integrated platform to support the multiple demands of the IoT solutions. Using WSO2 IoT Server, you can write your own methods to gather the data from your device and analyze the data that was gathered.

WSO2 IoT Server has the capability to analyze the data gathered from the device on the device itself. This is achieved via the edge computing capability in WSO2 IoT Server.

Applications

Applications and external system applications are able to connect with WSO2 IoT Server without any hassle as all its functions are exposed via secured APIs. It also provides secure communication between the devices and the applications through the authentication methods, such as SSO, SAML, and XACML, when connected with WSO2 Identity Server.

  • Try out the Mobile Application Management tutorial to get a quick understanding of how to create, manage and install applications using WSO2 IoT Server.
  • Want to know more about how to install an application on many devices at once and the mobile application life cycle, see Managing Mobile Applications.
Devices and SDKs

WSO2 IoT Server provides SDK support to build and connect your device with the WSO2 IoT platform. As all of the functionalities are exposed through APIs, the SDK support makes it easier to create new agent applications that run on the device. All the basic functionalities required to connect the device to the server are supported in the SDK itself.

WSO2 IoT Server user scenarios

To understand how WSO2 IoT Server functions, let's take a look at two real world scenarios.

Sensor data processing

To understand the concept clearly consider the scenario where your fire alarm is connected to WSO2 IoT Server.

  1. The fire alarm sensor detects the outbreak of a fire and notifies the Device API.
  2. The Device API calls for the respective operation needed to be carried out from the fire alarm device type plugin.
    Example: Notify the fire brigade of the fire.
  3. The device plugin sends the details of the fire outbreaks to WSO2 Data Analytics Server (DAS) where the data will be analyzed to derive useful information.
    Example: Analyze the frequency of the fire outbreaks and based on it identify the reason and pattern of the outbreaks.
  4. Next, DAS sends the analyzed information to the database and the system. The information will be made available to the end user who will access it via their mobile devices using the respective app.

Device access via the apps

With technology connecting individuals to devices, you are now capable of getting your devices to perform various operations for you. Consider the scenario where your gate is connected to the IoT Server.

  1. A request is sent to open the gate at your arrival through the respective mobile application.
  2. The application sends the request to the configured device plugin using the Device API.
  3. Next, the plugin communicates with the gate via a transport protocol, which can be MQTT/CoAP/XMPP/DDS/Sigfox, in order to trigger the specific event of opening the gate.

What's next? 

To know more about the WSO2 IoT Server architecture, check out the article on An Introduction to WSO2 IoT Architecture.

com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_links2' is unknown.