## 4 Prototype Implementation
### The IIP Prototype
#### 4.1.2 High Availability and Scalability  
In order to provide a high availability of service, the IIP must run multiple redundant instances of service-providing entities, so that, if one instance stops functioning, other instances can still serve client requests. In relation to high availability, the IIP must also be able to scale to larger deployments in order to accommodate an increasing number of clients using its service. Application server clustering, which is supported by the Glassfish application server, can address the needs of both high availability and scalability. All application instances in a cluster, which can reside in different hosts, can be administered as a single unit, and user sessions can be automatically replicated between application instances in a cluster. However  
database. From this point of view, clustering at the service layer (following Figure 5) does not give much advantage, except simpler administration.  
The open-source Apache web server with the mod_jk module is used for load balancing requests coming from clients (both information providers and consumers, as shown in Figure 5), acting as a proxy. The load balancing factor is currently set as equal for all IIP instances (hosted in different hosts), so that requests are forwarded equally (_i.e._, evenly distributed) among all IIP application instances. New IIP application instances in different hosts can be added (scaled up) in the service layer and the load balanced through this proxy.  
In the data layer (following Figure 5), MySQL Cluster is used for storing all of IIP's information. The IIP application instance in the service layer is responsible for handling requests from clients, but it does not store any state or information. Instead, it communicates with the back-end database to store information. MySQL Cluster follows a master/master architecture with no single point of failure, providing high availability and scalability of data storage and access. It makes use of a specialized storage engine, called _NDBCLUSTER_, which is not used in the standard MySQL server, and employs a synchronous replication to guarantee that data is written to multiple nodes upon committing the data. Unlike in the service layer, data replication in the data layer is essential to maintain high availability of data, which, in turn, will make the IIP run properly (_i.e._, reliable). Three node types of MySQL Cluster are used in the prototype, namely _management_, _data_ and _SQL_. Management nodes are utilized for managing the entire cluster. Data nodes are mainly responsible for storing and retrieving data from memory and disk. SQL nodes are used for providing application access to the cluster. Application instances communicate with the MySQL Cluster through the SQL nodes by using JDBC, which is  
Figure 8: (**a**) Pending information channel access requests listing sequence diagram; (**b**) Adding an information consumer user to the allowed user list of an information channel sequence diagram.  
responsible for load balancing queries across the SQL nodes. Figure 9 shows the current prototype's deployment architecture to accommodate high availability and scalability aspects.  
The current prototype consists of seven hosts (virtual machines) for deploying different nodes of the IIP: one for the load balancer, two for application nodes, two for data and SQL nodes and two for management nodes. By following the deployment architecture in Figure 9, new nodes can be added when needed.