## 3 Conceptual Design
### High Availability and Scalability  
Despite the positive aspects of the IIP as an integration platform between things and services that provides information distribution convergence, as shown in Figure 1b, centralized service brokers, such as the IIP, are architecture-wise a single point of failure, since all information providers and information consumers communicate with and rely on it. High availability becomes a crucial factor for successful deployment of the IIP to ensure services receive information from devices in a timely manner and continue to work properly (_i.e._, reliable). High availability is not a new topic in itself, as typical client-server systems require servers to run 24/7, with uptime as close to 100% as possible, accepting requests from client applications. Redundancy is the key to high availability, where service components are duplicated in different nodes, so that if one service component fails, another similar component will take over its tasks. In general, high availability can be achieved in either master/slave or master/master mode. In master/slave mode, a server instance (_i.e._, the master) is in charge of providing services to the clients' requests, while another server instance (_i.e._, the slave) is running idle. When the master instance fails, a monitoring entity (_i.e._, the manager) will hand over the master's tasks to the slave instance. On the contrary, all server instances are treated as masters in master/master mode, all providing services to client requests. The manager is responsible for monitoring and handling any conflict that might arise between concurrent changes made by different master instances. A load balancer can be added in front of master instances, so that client requests can be distributed according to the processing capability of the master nodes (e.g., requests are evenly distributed among master nodes when they have similar processing capability).  
The IIP utilizes master/master mode for high availability with an additional load balancer as proxy for handling client requests (both from information providers and consumers). This will make the IIP seem to be a single entity from both the information providers' and consumers' perspectives, but its components are redundantly distributed among different nodes. This approach allows the scalability  
Figure 4: Allowed user lists of information channels belonging to an information provider.  
aspect to be incorporated, as well, enabling new nodes to be added when the current serving nodes are reaching their peak (_i.e._, fully loaded) in handling incoming requests. Scalability becomes important when the number of information providers and consumers using the IIP is not fixed. IIP nodes should be flexible enough to scale horizontally by the addition of new commodity servers when the number of participating information providers and consumers grows.  
With regard to high availability and scalability, a simple three-layer system architecture is used by the IIP for deployment, as shown in Figure 5.  
The load balancing layer acts as a proxy service, where both information providers and consumers send requests. The requests are then forwarded to one of the application servers in the service layer that hosts the main logic of the IIP (_i.e._, the IIP application) based on the load balancing criteria maintained by the load balancer. In the service layer, the IIP's functionalities, as shown in Figure 2a,b, are realized and exposed through RESTful web service interfaces. All information that needs to be stored, such as information channels, allowed user lists, information channel subscriptions and the actual information of the information channels, are persisted in the data layer. By adopting this three-layer architecture, the IIP's components can be made redundant and can be scaled up according to deployment needs (e.g., add application nodes when more processing capability is needed, add data nodes when bigger storage capacity is required).