Programming Model for Internet of Things

Introduction:

A large number of physical items are being associated to the Internet at an exceptional rate figuring it out the possibility of the Internet of Things (IoT). A fundamental case of such objects incorporates indoor regulators and HVAC (Heating, Ventilation, furthermore, Air Conditioning) observing and control frameworks that empower keen homes. There are likewise different spaces and situations in which the IoT can assume a striking job and make strides the nature of our lives. architecture standardization is core of the IoT to create a interoperability between the different architecture approach. In addition, the traditional Internet architecture needs refinement to match the IoT challenges. Programming models needs to be generalised to increase scalability. In following sections issues in IoT are addressed and possible solution to the problems are proposed by doing research survey in the field of IoT. Trends in IoT is enumerated to introduce futuristic trends available in field of IoT.

Approaches to distributed system:

Designing the software for distributed system requires to follow methodologies. This methodology comprises of the several fix phases regardless of design approach chosen by the software architect. From capturing the requirement to maintenance of the system it must go through several phases. In traditional approach common phases of the software development are listed below.

Requirement: requirement capture is  about finding what is going to accomplish with new bit of programming and has two viewpoints. Business modelling includes understanding the setting in which programming will work. A system requirement modelling implies choosing what abilities the new programming will have and recording those abilities.

Analysis: it means understanding what are managing. Prior to planning an answer, it should be clear about the significant elements, their properties and their connections.

Design: in this, problem solving strategies are developed by dividing system into process and hardware subsystem. Decision to solve the communication problem and right technology choice is carried out.

Specification: desired behaviour of system once the requirements are finalised.

Implementation: piece of code is written for each subsystem. After this combing the pieces of written code to form a complete system.

Testing: Testing will confirm that written code is valid and performing as intended.

Deployment: it deals with providing the software and hardware to the end users along with this training manuals.

Maintenance: after deployment of system, it is monitored to observe its life cycle. Bugs developed are replaced by applying patches or bug fixes so that durability of system increases (Munassar(2011)).

“Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating web services. Web services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. RESTful web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations. Other kinds of web services, such as SOAP web services, expose their own arbitrary sets of operations”. REST has been developed by giving more emphasis on restraint and taking system context into consideration. (En.wikipedia.org. (2018)).

REST Architectural Elements

 REST style is about abstracting the details of architectural elements within the distributed system. REST focuses more on component roles, interaction with the other component, and their interpretation of significant data elements. It incorporates the important constraints on components, connectors, data that define the root of the Web Architecture. Distributed hypermedia architect has three fundamental options to provide a data to the processing agent. Out of these, first one provides the data in the form of fixed-format image from the point it is located. Second one summarizes the data with rendering engine and send both to the recipient.

Last option, it sends the raw data along with metadata which describes the data type, so that rendering engine choice will be made by recipient. To cover the disadvantages of above three options REST come up with hybrid of all three by focussing on a shared understanding of data types with metadata but also limiting the information that is to be revealed on standardized interface.

REST data elements are summarized in tabular format.

REST architectural style is not a protocol it’s an architecture which define the set of constraints for designing a system. When all the constraints applied correctly, it enables following advantages:

• Performance
• Scalability
• Reliability
• Simplicity
• Modifiability
• Visibility
• Portability

The following sub-sections briefly summarize the REST constraints and explain how they enable the listed properties.

Client Server:

In RESTful system components perform the desired role in every interaction. Clients issue the requests to the server, intermediaries forward requests, and server responds to the request, origin servers are the decisive recipient of the request which intends to modify the resource state.

This improves simplicity and visibility, as it is manifested from the process that which component has started an interaction. Furthermore, it improves modifiability through a clear separation of concerns.

Stateless:

As defined in the architectural style messages are self-contained. They must contain all the required information to process it, with no dependency to previous message. This allows strictly to separate resource state from the client state.

This improves the scalability, reliability. Servers can be scaled individually as well as can be replicated. Through the message tracing mechanism all the information regarding logged interaction can be made available to the client. Furthermore, it enables caching.

Cache:

Constraint requires responses to have the clear and understandable cache-control metadata. This will provide the client and intermediary with functionality to store the responses and reuse them to answer the locally generated request. Cache-control metadata will decide whether the information in the caches response is still fresh or stale and needs to be discarded.

This improves performance, as the cache-control metadata information is stored on intermediary so that response time can be reduced significantly. Less data transferred from server in turns improve the scalability. Reliability of the system can be increased as the request will be answered locally even if the origin server is temporarily not available. Fielding(2000)

Uniform Interface:

All RESTful APIs use the same, uniform interface independent of the application. This simple interaction model is enabled by exchanging representations and modifying state locally, which simplifies the interface between clients and servers to a small set of methods to retrieve, update, and delete state – which applies to all applications.

A REST interface is fully defined by:

• URIs to identify resources
• representation formats to represent (and retrieve and manipulate) resource state
• self-descriptive messages with a standard set of methods (e.g., GET, POST, PUT, DELETE with their guaranteed properties)
• hypermedia controls within representations

The origin server inserts the controls for interface into its representations and informs the client about the possible requests. Web linking is most commonly used control in RESTful system.

This improves the simplicity as uniform interfaces are easier to understand. Visibility of the system improves because of self-descriptive messages. This constraint improves modifiability, uniform interfaces allow client and server to evolve independently.

Layered System:

This constraint imposes limitation on the client interfaces so that client cannot see beyond the server it is interacting.

This allows easier modifiability as topology changes become transparent. Furthermore, it helps in scalability. Separation between client and server improves simplicity of deployment.

Code-on-demand:

Origin servers provide the codes to the client when demanded. This improves modifiability, since the modification or deployment of new features can be implemented during runtime. As the server is shipping the code to the client so that client can answer the request locally. (Keranen(2015)).

Challenges in REST:

Rest offers single interface to all resources. In contrast, SoA provides separate interface to every resource. In SoA Web service definition language defines the operations to be performed in terms of input and output messages. REST doesn’t provide any information on its interfaces. It is based on self-descriptive message. SoA provides metadata along with the information which allow developers to automate programming. Automation is the main concern in IoT due to disparity in sensors. Hence metadata needs to be added in REST API to eliminate the automation problem (Namiot (2016)).

Programming model for IoT:

Choosing a language for IoT

Selection of programming language is independent of the hardware platform in IoT system design. Even the change in the hardware wouldn’t put much burden on programming model as it is being developed independently. Programming standards in IoT are described as the vertically facing downward to cope up with device connectivity and upward facing standard to provide a unique interface to all application end user. Generalisation of programming language is the main problem when defining the programming model for IoT. It is merely possible to define the specific standard for IoT model as excessive unification leads to biggest source of problems. There is no constraint on choosing the language for programming as raspberry pi is running on Linux, will do the same function on windows desktop also. According to the eclipse survey different languages reported by many of the IoT developers. “Our Internet of Things effort at Eclipse is polyglot” said Skerrett. “It’s not one language.”

Emergence of dynamic language is catching attention of all the IoT developers as it deals with event driven scenarios. Classic example of dynamic language is JavaScript. There are many reasons to use this programming language for IoT. One of them is big team of developers. Secondly it covers client as well as server-side programming. Internet is using JavaScript for most of its application. Using the same language across the whole project will make sense if we further extend the system. JavaScript supports the event driven programming which is most of the use case scenarios in IoT. Event driven models can be easily implemented using JavaScript. Dart programming developed by google is new programming language which works with the idea of portability. (Namiot (2016)).

Challenges in IoT:

Despite of wide spread emergence, IoT is still in its early stage of development where there are many areas like standardization of protocol, scalability, interoperability, programming model, design approach, integration of heterogenous devices requires more research. Among them ‘Interoperability’ is the important one to focus on. By resolving this issue, IoT devices will be able to communicate among themselves to produce a cost-effective system. Many companies, organisation, educational programs are promoting this issue to bring out the solution to this problem. C4ISR architecture working group (AWG) developed the LISI (Levels of Information Systems Interoperability) approach in 1997. The purpose of LISI model is to provide maturity model to US Department of Défense (DoD) and to specify interoperability needs and selecting pragmatic solutions for enterprise interoperability. The IoT Forums from worldwide are Constantly conducting research to develop a common model to all IoT devices so that interoperability can be resolved. Also, Open Internet Consortium (OIC) is currently focusing on the IoT interoperability to define specifications, uniform interface and integration of billions of smart objects, and scalability issues. The Grid-Wise Architecture Council (GWAC) mission is to enable interoperability among the objects that interact with the electric power system. To tackle this issue, they have presented the context-setting framework which will identify the interoperability issues. Solution to this will ease the job of customers to work in heterogeneous environment (Soursos(2016)). Primary problem due to which interoperability arises is there huge number of competitor in this game. Everyone is developing the solution independently using different platform and frameworks due to which communication and integration between different devices becomes cumbersome. The company Chirp has proposed a solution to this differentiation concern, by proposing interconnectivity through the universal language of sound. Open source frameworks and machine-to-machine (M2M) service layers are also attempting to solve the challenges facing IoT interoperability. Only once these interoperability challenges are solved, will we see the true potential of IoT revealed. The Chirp company has come up with the solution to eliminate the interoperability problem among the competitors by introducing interconnectivity through universal sound language, Open source frameworks and machine-to-machine service layers. They believed that real potential of IoT world will be revealed after interoperability issue is addressed. They have introduced the following ways to tackle the interoperability issue.

Data over sound technology:

 It converts data into pitches and tones having different levels of amplitude to create a unique barcode, which is then transferred to the devices where it can be decoded. Devices having the small computational power is compatible with technology proposed by Chirp. Chirp also proposed the common interface so that different devices can communicate with each other. The interoperability suite is available in software development kit (SDKs) which is significant to solve the interoperability. This facilitate IoT in scalability, cost-effectiveness and mainly interoperability.

Open source framework:

Cloud platform which provides the open source framework are getting popular day by day.

Various companies are trying their efforts to come up with solution which will provide framework for IoT devices. For example, AWS cloud has included the IoT suite in their services so that IoT based projects can be hosted on cloud with almost 100% probability. This will fasten the IoT development and provide flexibility across various platforms. Interoperable feature is also achieved arising from the same source of framework

Common IoT service layer:

By implementing the common centralized service layer, developers can develop their application independently without worrying about their interoperability with other devices. It combines M2M and IoT middleware layer, common services layer, which is compatible globally and allows networking between devices.

This allows multiple IoT devices and sensors to be shared across different applications, essentially eliminating the proprietary inter-compatibility difficulties. (Eastwood, G. (2018)). 

TRENDS IN INTERNET OF THINGS:

Internet of Things is newly and booming paradigm that has a power to connect the surrounding things. It results in huge amount of data generation. To process this data, we require powerful tools that can handle large amount of data generated by the sensors every millisecond. Cloud computing is the one of the feasible solution which provides more storage, powerful processing, data analytics and much more. This approach tackles some of the IOT implementation problems but not all as IOT is a blend of different system using different platform. To tackle this newly developed microservice architecture is capturing the attention as it addressed most of the IOT implementation problem. (Campeanu, G. (Jun 2018)). The term “Microservice Architecture” has sprung up over the last few years to describe a way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data (Lewis, J. & Fowler, M. (2014)).

MICROSERVICE ARCHITECTURE:

Microservices term has recently evolved but the idea behind it is still not implemented. From best practise one can draw a possible conclusion about the microservices. Some of the basic technologies that led to the microservices architecture are mentioned in the Sam Newman.

Domain driven design: business domain knowledge is the main idea in the software development process. Experts of the domain should be placed closely to the software development loop in software engineering.

Continuous delivery: keeping every code repository for further development release which includes the unit, integration, performance testing as well as different software metrics. Continuous delivery also covers the automated deployment of applications.

Ports and adaptor patterns: by Alistair Cockburn, also known as hexagonal architecture provides an approach to separate the business logic from external technological considerations. This approach suggest that application have several ports e.g. for cloud connection, databases, front-end, integration and further. Each port has a mediation layer that handles crosscutting concerns like monitoring and has several adapters that connect to different technologies e.g. an adapter to a specific MySQL database at the database connection port.

Machine to machine communication: data exchange without human intervention.

Virtualization platforms: advances in virtualization, especially application containers.

Microservice architecture is an approach that incorporates with scalable, changing business models in cloud. Several big players like Netflix or Amazon have already adopted this approach and have shown that this architectural pattern fits their needs. To tackle the deployment problem and ability to choose the better technologies for separate application parts in IoT, best practises were performed, and conclusion drawn out of them is investigated below. We will be covering self-containment of services, monitoring and the prevention of fault cascading, choreography and orchestration, container technologies and the handling of different service versions.

In self-containment the services should contain everything needed to fulfil their task on their own. It also includes not only business logic but also front and backend, as well as required libraries. keeping it this way services can be scaled independently by starting multiple instances. Main objective of the microservices is to keep services dependencies to other services as small as possible so that services can evolve independently. In internet of things many SOA stick to the self-containment principle. Adopting self-containment in the internet of things might create the following benefits.

Back- end as part of services we need not to worry about dependencies for data storage. Outside world should not be able to access the data kept by the service this enforces to use the service API and hence stops the external data consumers from accessing internal representation of the data. This allows independent evolution of services and interoperability is maintained.

• Keeping required libraries together with the services makes the deployment easier, as installation dependencies are no more required. Furthermore, if containers used then required libraries can be updated easily as they do not interfere with each other.
• Less dependencies leads to decoupling between services, increase independency and reduces the required communication time in overall network.

Monitoring and Prevention of Fault Cascading:

In monitoring capabilities, each service should be able to provide an interface to display their monitoring information.to check whether service is ok or broken is of high importance. By this way other services can check continuously for the health status and avoid calling broken service. In case of circuit failure “Circuit Breaker” pattern has been developed from the practise. It checks health status of the services or the number of unsuccessful calls been made to the service. Once the circuit breaker is triggered after reaching threshold value it will return the error message instead of sending a call to the services. After certain amount of time circuit breaker again checks for the health status of the failed service to test if the services have recovered or not and enters the half open state after successful test. It is not open fully to prevent services from getting fail again due to high traffic. Furthermore, it works perfectly when implemented with “Load Balancer”. Load balancer distributes the traffic to the services having ok health status. In internet of things load balancer can be used with circuit breaker or independently. Both patterns are good in handling fault in remote services. Due to constrained nature of many internet of things appliances these patterns provide additional benefits like circuit breaker prevents unnecessary messages being sent to the failed services which reduces overall traffic and saves energy. Lifetime of the sensors can be increased due use of load balancers as it shares workload among several devices to keep them in low power mode. In microservice architecture it is recommended to use the common logging format for all the services to capture the whole picture of the overall system. However, in IoT system it is impossible to use the same logging format as no one is in control of services hosted. Yet IoT developers should concentrate on how common logging formant can be used to avoid the faults occurring while logging of services.

Choreography over Orchestration:

When it comes to putting services together there are multiple ways to do it. Orchestration means for every instance a conductor is created which is responsible for controlling the service to be called in centralized way. In choreography instead, each participant does its part on its own and the resulting application is created by the sum of the individuals. Individual performs the activity on event driven basis. From IoT point of view one should opt choreography technique as it gives freedom to services to evolve independently. Today, IoT services are combined using orchestration style because protocols like HTTP doesn’t support event driven communication except Message Queue Telemetry Transport protocol (MQTT) which enforces to use event-based communication.

Container:

In microservices a term docker is often found. Docker is a computer program that performs operating-system-level virtualization, also known as “containerization”. It was first released in 2013 and is developed by Docker, Inc. Docker is used to run software packages called “containers”. In microservice architecture this is useful as container supports self-containment and includes required libraries and data to host an individual service on single container. It has several advantage out of them some are summarized below.

Better testability: Whole container can be tested so to prevent the faulty software putting into the operation.

Ease of service deployment: container can be deployed independently as each container contains all the required libraries packed with its corresponding service. Deploying the container also eliminate the problem of interference between different libraries as they are isolated from each other. Furthermore, docker supports automatic deployment of containers hence the process can be automated.

better scalability: Every service is deployed independently which increases scalability. Each service can evolve independently by just start/stop multiple instances. As overhead of container virtualization is much lower it helps in executing start up script very fast.

Handling Different Service Versions:

In the microservices approach, deploying application has been simplified greatly. Immutable server pattern is used to make sure that application was tested before putting into the operation. Instead of emphasizing on providing the user credentials when something needs to be changed just replaced it with the new version of it. If something in new version turns out to be faulty, old version of that application can be replaced easily by redeploying it at the place of faulty new version application. Blue-green deployment is another pattern to handle the multiple versions of services. During deployment of new version of application older version is also kept running in parallel. At the beginning all the service requests are routed to the old version till the newer one gets configured.

After the successful deployment routers will triggered the request to the newly deployed version. By this way service downtime can be eliminated. In case of rollback router again triggered the request to older version of application.

In the internet of things, the pattern immutable server and blue green deployment are not yet employed. If deployed with container technology enable to update the application services with minimum downtime. (Campeanu(2018))

Conclusion

After completing this survey, it is concluded that traditional approaches are not suitable for constantly changing IoT environment. It involves heavy documentation, time to market is more which is not suitable for dynamic environment. Applying RESTful approaches to IoT provides statelessness, client server decoupling, uniform interface along with this it provides greater flexibility, scalability, simplicity. Future work is needed to carry out on REST API to eliminate automation problem. Using the programming model techniques code size, complexity of IoT application is reduced. Reduced code size, complexity enforces greater security. JavaScript seems to be good choice as most of the application on internet runs on the JavaScript. Also, the emerging technologies like cloud computing, open source platform, Dart programming are also possible solution to ‘Interoperability’.

REFERENCES: –

• Campeanu, G. (Jun 2018) A Mapping Study on Microservice Architectures of Internet of Things and Cloud Computing Solutions. : IEEE, pp. 1.
• Eastwood, G. (2018). IoT’s interoperability challenge. [online] Network World. Available at: https://www.networkworld.com/article/3205207/internet-of-things/iots-interoperability-challenge.html [Accessed 17 Nov. 2018].
• En.wikipedia.org. (2018). Representational state transfer. [online] Available at: https://en.wikipedia.org/wiki/Representational_state_transfer [Accessed 17 Nov. 2018].
• Fielding, R.T. & Taylor, R.N. (2000) Architectural Styles and the Design of Network-Based Software Architectures. : University of California, Irvine Irvine, USA.
• Keranen, A., Kovatsch, M. & Hartke, K. (2015) RESTful Design for Internet of Things Systems. Internet Engineering Task Force, Internet-Draft Draft-Keranen-T2trg-Rest-Iot-04, Mar.2017, Work in Progress.
• Lewis, J. & Fowler, M. (2014) Microservices: A Definition of this New Architectural Term. Mars.
• Munassar, N.M.A. & Govardhan, A. (2011) Comparison between Traditional Approach and Object-Oriented Approach in Software Engineering Development. International Journal of Advanced Computer Science and Applications. 2 (6).
• Namiot, D. & Sneps-Sneppe, M. (2014) On Micro-Services Architecture. International

Journal of Open Information Technologies.

• Namiot, D. & Sneps-Sneppe, M. (2016) On Internet of Things Programming Models. International Conference on Distributed Computer and Communication Networks. : Springer, pp. 13.
• Namiot, D. & Sneps-Sneppe, M. (2016) On Internet of Things Programming Models. International Conference on Distributed Computer and Communication Networks. : Springer, pp. 13.
• Soursos, S., Žarko, I.P., Zwickl, P., Gojmerac, I., Bianchi, G. & Carrozzo, G. (2016) Towards the Cross-Domain Interoperability of IoT Platforms. Networks and Communications (EuCNC), 2016 European Conference On. : IEEE, pp. 398.