This is an old revision of the document!
What are the biggest problems in IoT? Where do current market IoT solutions fall short? How should IoT be considered? 
Put another way, “What are the most common issues preventing companies from fully realizing the benefits of IoT?” This question was answered at DZone by 23 executives involved with the Internet of Things.
Most important observations:
The IoT industry, across numerous market verticals, is at an impasse where customers are demanding increasing sophistication at lower prices. Given the complexity and importance of IoT, no single company can or should be dictating the path forward for the entire industry.
The only viable path forward is collaboration between companies and market verticals to collaborate on developing, testing and standardizing the non-differentiating functionality. The Open Connectivity Foundation is currently working to achieve that, however the device-cloud communication represents a unique challenge for the engineers involved because there has never been a historical need for engineers to become knowledgeable in both embedded systems and cloud native application development. The proposed solution to this problem is to emulate the container runtime interface (CRI) architecture and embody Conway’s law to establish a loose coupling between the “IoT code” (CoAP/iotivity cloud interface) and the portions of the system that are much more familiar to the cloud developers (ex: db/messaging/auth) which will also vary more depending on the use case.
<WRAP center round info 90%> “Throughout our history, it has always been standardization of components that has enabled creations of greater complexity” –Simon Wardley </WRAP>
<WRAP center round info 90%> The Internet of Things (IoT) is the network of physical devices, which are embedded with electronics, software, sensors, actuators, and connectivity for the purpose of enabling these things to connect and exchange data. Thus creating opportunities for more direct integration of the physical world into computer-based systems, resulting in efficiency improvements, economic benefits and reduced human intervention. (Wikipedia, Internet of Things) </WRAP>
In other words, an IoT device is regularly subject to change, since it represents the world around itUnderlined Text. It's up to the developer, how the world is represented through the device and processed by the application for your specific domain. Technology should support the transfer of data in a standardized and secured way. The IoT platform can't limit you and can't set boundaries, which would limit evolution of your system.
Domain is a sphere of knowledge, influence or activity.
IoT itself is most likely not a domain of your business, it is a group of technology achievements from the last decades of the 20th century, which open the door to new possibilities for your business domain. Allowing for the modelling of the external world specific to your needs, in the form of resources and events, which will be transferred in a secure and traceable manner to your application, located off-premise or even on-premise. The goal is for developers to focus primarily on the domain of their business.
<WRAP group> <WRAP half column>
<WRAP half column>
Missing events, delays, invalid values, unreliable networks, depleted batteries… An IoT device is unreliable by nature. It's exposed to the real world, and your system has to account for that. Depending on the domain, many compensations might be expected within your system. That's a risk you face when dealing with the outside world from your warm silicon farm. Retroactive Events and Parallel Models are challenges you will face. In such a case, it might be important for you to know what led to a certain state, reproduce it event by event, debug it or just explore the path leading to the state.
Quality drivers, domain, and other IoT related facts are calling for CQRS and Event Sourcing patterns.
<WRAP center round info 90%> Using the OCF Native Cloud does not force you to use Event Sourcing throughout your whole system. Actually, doing so would be a bad idea. </WRAP>
<WRAP group> <WRAP half column>
Servers (IoT Devices) which are OCF enabled are represented in the form of resources. (similar to REST) Resources are hosted by a server and if it is connected to an OCF Native Cloud, it is able to publish those resources, which should then be accessible “remotely” through this decentralized component. That means, the OCF Native Cloud works both as the gateway and the resource directory for all connected and authorized servers / clients. If the connected client wants to find a specific resource hosted by a specific device (resource directory) and CRUDN that resource hosted by that server (gateway), OCF Native Cloud will take care of it.
<WRAP center round info 90%> To understand more about what a resource is, read chapter 7 - Resource model </WRAP>
Connected server / client can:
<WRAP half column>
EEvery client (application interested in data) connected to a server (IoT Device) should be able to perform an action on the device or access data published by that device (resource directory), if authorized. That means, not every connected client and server should be able to find / CRUDN any resource published to the Resource Directory.
When the server / client are connecting to the OCF Native Cloud, these entities are required to successfully sign-in and sign-up. Only after a successful sign-in operation they are allowed to use the Resource Directory - Resource Bounded Context.
<WRAP center round info 90%> As detailed in this specification, token based authorization should be used. </WRAP>
During the sign-up process, which can be thought of as a registration, a one time use authorization code is verified by the Authorization entity and the access token is issued by the Authorization entity. This token is then used exclusively by this server / client pair and uniquely represents this pair in the OCF Native Cloud.
The connected server / client has to belong to the user of the Authorization entity, which requested the one time use authorization code. When an access token is retrieved by OCF Native Cloud from the Authorization entity, it will register that device locally and link it with that user - or specific attribute of that user, for example tenant id.
An example to make it more clear (Note: this is not a complete workflow, there are some missing attributes, but as this bounded context is about authorization, it's skipped for ease of reading):
Then an owner has access to only their devices. In this example, that means user A can access, by default, only devices registered through the user A's account.
Connected server / client can:
The following list defines the key domain-related terms.
A server hosting resources has to be accessible through the OCF Native Cloud. After successful connection, authentication and authorization, the server has to publish its resources, which are discoverable by other connected and authorized clients and servers. Clients should then be able to discover resources based on resource type or by the identifier of the server which is hosting them. A client should also be aware of the information, if the server hosting resources is online and the client performs CRUDN operations on resources published to the resource directory. Requests should be consumed by the server hosting the resources (*), and the client informed of the result.
(*) In case of the OCF CoAP Gateway, through which servers are connected to the OCF Native Cloud, commands should be consumed and processed by the gateway where the requested server is connected.
An Aggregate is a resource hosted by a server. Concurrent requests to one server are not an issue and do not raise concurrency conflicts, until the same resource is requested concurrently. Most concurrency conflicts can be solved without informing the user, by applying optimistic locking with aggregate versioning.
Authorization is the business invariant, which has to be validated within each issued command to the Resource Aggregate.
<WRAP center round info 90%> The component that implements the IRepository is responsible for persisting the aggregate and publishing any events raised by the aggregate on the event bus, all as part of a transaction. (e.g. event store) </WRAP>
OCF Servers and Clients communicate over CoAP and support CRUDN.
The OCF Native Cloud observes the published resources of OCF Servers and tracks all changes to these resources. A representation of the current state of resources is maintained in the form of a Resource Shadow. The OCF Native Cloud does not act as a gateway between device and client, and does not handle CoAP requests directly. Instead, the OCF CoAP Gateway handles these requests and transforms them into commands accepted by the Resource Bounded Context.
OCF Clients and Servers are able to invoke CRUDN operations on the OCF Native Cloud through the OCF CoAP Gateway, but the way these CoAP commands are handled differs.
<WRAP center round info 90%> Retrieval of a resource representation is not querying the device directly, as the OCF Native Cloud contains an up-to-date Resource Shadow based on ResourceRepresentationUpdated events. </WRAP>
A frequently cited advantage of the CQRS pattern is that it enables you to scale the read side and write side of the application independently to support the different usage patterns. The Resource Aggregate, write side of the Resource Bounded Context is emitting events which are used for the building of the Resource Directory view model. The Resource Directory is therefore queried directly and can be scaled independent of the write side.
<WRAP center round important 90%> As the Resource Directory is built from Resource Aggregate events, it is not immediately consistent, but will be in time. </WRAP>
<WRAP center round info 90%> This approach also allows OCF Native Cloud users to build their own view model based on the Resource Aggregate events (e.g. flat resource structure where a root element is a device), which might make more sense for their domain. </WRAP>
The Command Handler for the Resource Directory Aggregate has the business invariant Authorization - which has to be validated within each issued command to the Resource Aggregate. Resource Directory, the read side has to return only those resources a user is authorized to receive. As each client / server is identified by the token, this token has to be used in the communication with the read side - Resource Directory.
Within the OCF Native Cloud, the resource shadow provides the latest representation of resources, because it is in sync with the physical devices. Through the use of the CQRS pattern, the resource shadow is the independently scaled, and the read side will eventually be consistent with the devices represented. It is not immediately consistent, since it takes time for the Resource Aggregate events to be handled, which it is built from.
<WRAP center round important 90%> As the Resource Shadow is built from Resource Aggregate events, it is not immediately consistent, but will be in time. </WRAP>
<WRAP center round info 90%> This approach also allows OCF Native Cloud users to build their own view model based on the Resource Aggregate events, and enrich it appropriate to their own domain. </WRAP>
The Command Handler for the Resource Directory Aggregate has the business invariant Authorization, which has to be validated within each issued command to the Resource Aggregate.
The read side of the Resource Shadow will return only those resources a user is authorized to receive. As each client / server pair is identified by a token, this token has to be used in the communication with the read side of the Resource Shadow.
The following list defines the key domain-related terms.
To be able to communicate through the OCF Native Cloud, an OCF Server / Client has to first sign-up and sign-in. The Sign-up (registration of the entity), to the OCF Native Cloud requires a unique, one-time-use authorization code which is issued by an OAuth Server for a logged-in OCF Native Cloud user and transferred to the device. (The way the code is set on the device is not part of the OCF Native Cloud). The OCF Native Cloud will ask the OAuth server to verify the issued authorization code, if it is still valid and not yet used. After successful validation, the OAuth server returns an access token for further communication between the onboarded device and the OCF Native Cloud.
<WRAP center round info 90%> An access token is personalized, as it was issued by the subject (OCF Native Cloud User) for the specific device. </WRAP>
User/Device Management Component communicating with the OAuth Server (might be one component) assigns the device to the user who started the onboarding process - asked for authorization code and returns sign-in data back to the device as a response to the sign-up.
<WRAP center round info 90%> The OCF Native Cloud user who onboarded the device becomes the owner of this device. </WRAP>
When the OCF Server / Client is signed-up, it can continue with the sign-in process. A successfully signed-in device might publish its resources and be requested (CRUDN) through the OCF Native Cloud without limitation. The OCF Native Cloud itself is responsible for authorization requests from different OCF Servers / Clients. OCF Servers / Clients can communicate with each other, if they have the same owner (onboarded by the same user).
<WRAP center round important 90%> This is a simple default scenario, which will usually be modified by the companies using OCF Native Cloud. Management of users and devices is completely business specific and has to be modeled on your own. </WRAP>
Each request to a resource is validated with the Authorization Bounded Context and provides information, which user has permission to which OCF Client / Servers identified by the id.
<WRAP center round info 90%> Each request session must be backed by an access token, so the OCF Native Cloud can authorize that request. In case of the OCF Servers / Clients, a TCP session must be backed by the access token and validated through the sign-up process. Each command issued by the OCF CoAP Gateway is then backed by the validated token. </WRAP>
To be able to clearly identify if the OCF Native Cloud User or the OCF Server / Client onboarded by them is authorized to make a request to another OCF Server, a concrete claim from the token of the requester must be mapped with the requested server id in the component responsible for the User / Device Management.
Candidate for the sample business invariant validation is the claim SID, which would identify an OCF Native Cloud User. The User / Device Management component would then provide information, which server IDs can be accessed by this user, identified by SID. As the OAuth Server would be most often provided by you, custom claims can be introduced and used for mapping with server IDs. For example, each OCF Native Cloud User belongs to a certain tenant, identified by a unique id. If the granularity of having devices accessible by tenants is enough for you, you're free to model it in this way and specify which claim should be used for validation inside the Command Handler of the Resource Bounded Context.
OCF Servers / Clients communicate over TCP / UDP using the CoAP application protocol. Communication within the OCF Native Cloud shouldn't be restricted to the CoAP protocol, implementation should allow the use of whatever protocol might be introduced in the future. That's why the gateway is the access point for CoAP over TCP, and further communication is OCF Native Cloud specific.
TCP connection to the OCF Native Cloud is by its nature stateful. The OCF CoAP Gateway is therefore also stateful, keeping open connections to the OCF Servers / Clients. The goal of the Gateway is to translate between the OCF Servers / Clients (CoAP) and the protocol of the OCF Native Cloud and communicate in an asynchronous way.
In case of a deployment with many OCF Clients / Servers, a single instance of the OCF CoAP Gateway is not enough. Scaling and load balancing of connections is required. More options are available:
As load balancing can be very user specific (e.g. OCF CoAP Gateway per tenant), OCF Native Cloud will not include this functionality. Users may already have a preferred solution in their infrastructure to handle load balancing or their needs may be excessively complicated (high performance, low lantency, many clients, etc.). That is why this topic is out of scope and will not be solved by OCF Native Cloud.
The market is missing a remote system allowing OCF enabled devices to be connected so a device owner can see their state and control them. There are multiple use-cases for such a system (e.g. smart home, processing plants, hospitals, universities). Companies developing such systems want to support as many devices as possible without need for protocol adapters and device specific implementation, which might be provided by the OCF standard in the future. OCF Native Cloud should be open enough to allow companies who want to introduce such a system to do it without limitations, not forcing them to use specific technologies, but leave it up to them as much as possible. Integration with their existing system will become easier, resulting in a growth of users and increasing the number OCF enabled devices.
A company integrating the OCF Native Cloud based on the new design is not forced to use CoAP for communication with the OCF Native Cloud. OCF Devices are currently communicating with the OCF Native Cloud over CoAP, but that's a limitation to be overcome. To build a business case with OCF enabled devices and Native Cloud, user services have to be introduced and should be able to communicate with the OCF Native Cloud. As mentioned before, with no need for the use of CoAP. Services within the same deployment should effectively communicate in the same way the OCF CoAP Gateway is communicating with the rest of the system - Resource and Authorization bounded contexts.
Let's assume a company is already providing simple device management for their devices, but would also like to support an OCF enabled system which will guarantee more customers for their software. Their Device Management (DM) service exposes a REST API and allows users to configure them and see current readings of sensors attached to those devices. The company already has an OAuth based authorization server and User Management. What would the integration look like?