1 Contextualization

This practical assignment is split in two phases.

In Phase I, the students are given the opportunity to learn/review concepts about concurrency and sockets in Java. The proposed exercises will not be evaluated. In Phase II, students have the opportunity to develop, from scratch, a platform based on quality attributes. 2 Phase I Phase I is important for giving all the students the opportunity to remember or to have an initial experience with concurrency and sockets before facing Phase II. Java provides several mechanisms to implement concurrency (https://docs.oracle.com/javase/tutorial/essential/concurrency/). Among them, the use of synchronized and Locks are emphasized. Please read the tutorial carefully. Java provides sockets (https://docs.oracle.com/javase/tutorial/networking/sockets/index.html) to allow standard communication between processes. Please read the tutorial carefully. Download the NetBeans project AS from the e-learning. Package ReentrantLock has an example using a monitor where several threads share the variable count. Package Sockets has an example where a server listens and echoes messages sent from clients. Please study these two examples carefully.

Phase 2 Performance, Availability and Scalability are three of the most relevant Quality Attributes in most of the Software Architectures. The main goal of this assignment is the design and development of a platform the Software Architecture of which relies on those three Quality Attributes. 3.1 Requirements Suppose that a Customer X needs an infrastructure (cluster of servers) to provide mathematical computational services to its clients. From the defined requirements, the following tactics were selected to be implemented. A. Performance 1. Replicas of computation: requests must be fairly distributed among the servers; 2. Concurrency: each request runs on its own thread in a server; 3. Bound queue size: limit number of simultaneous running threads in each server. B. Availability 1. Heartbeat: to detect if servers are up; 2. Redundancy: to reallocate requests in case a server goes down; 3. Monitor: to supervise the clusters status (up/down servers, threads, service allocation, clients, etc.). C. Scalability 1. Horizontal scalability: add new servers whenever necessary. 3.2 Constraints 1. For simplicity, you can consider that all components have 100% availability and no failures take place - unless components/servers are intentionally killed/shut-down 2. Services are made available to clients through TCP/IP sockets 3. Clusters will be implemented in a simulation environment: each server is one running process 4. Define a load-balancer (one process) to fairly distribute the requests among the servers 5. Heartbeat service and monitor service share the same process (eventually also with the load-balancer) 6. Clients can only send requests to the load-balancer which sends the answers back to clients. 7. For simplicity, consider that there is only one type of request/service (calculation of ? (pi) with a parametrized precision): o request: | client id | request id | 01 | precision | delay | o result: | client id | request id | 02 | precision | delay| pi |

o result: | client id | request id | 03 | precision | delay | client id (Integer>0): client identification request id (Integer>0): unique request identification (by client id) 01 (Integer): code for pi calculation 02 (Integer): code for pi calculation 03 (Integer): code for request rejection precision (Long>0): number of iterations delay (Integer>0): delay in seconds to simulate computational time pi (Double): value of pi 3.3 Demo The demo is carried out through a set of use cases. Each use case can be slightly modified to address some additional not conflicting issues. Use Case 1 - basic functioning Environment: 3 servers, 1 load-balancer, 2 clients, queues size with no limit Stimulus: send requests to compute pi with several delays Expected response: correct values of pi Use Case 2 replicas of computation Environment: 3 servers, 1 load-balancer, > 6 clients, queue size with no limit Stimulus: send 1 request by client with enough delay Expected response: the monitor shows that requests are fairly distributed Use case 3 concurrency Environment: 2 servers, 1 load-balancer, > 6 clients, queue size with no limit Stimulus: send 1 request by client with enough delay Expected response: the monitor shows that each request is allocated to a different thread in a server (threadId). Use Case 4 bound queue size Environment: 1 server, 1 load-balancer, > 4 clients, queue size = 3 Stimulus: send 1 request by client with enough delay

Expected result: monitor shows a maximum of 3 threads and additional requests are rejected Use Case 5 - heartbeat Environment: 0 servers, 1 load-balance Stimulus: servers are added and killed Expected response: monitor is updated in conformity Use Case 6 redundancy Environment: 3 servers, 1 load-balancer, 2 clients, queue size with no limit Stimulus: 1 request per client with enough delay and then 1 server goes down Expected response: monitor shows that the service is fairly reallocated and all results are sent to clients User Case 7 scalability Environment: 0 servers, 1 load-balancer, 1 client, queue size with no limit Stimulus: add new servers while sending requests (without any delay) Expected response: new requests are fairly allocated 3.4 Implementation You can build a unique NetBeans project or one project for each type of process. A GUI is necessary for each relevant type of process in order to help on analyzing and validating the evolution and status of each Use Case. Load-balancer ? the load-balancer must comprise a GUI to log the relevant events, namely: requests, replies, service allocation to servers. ? the GUI must allow the definition of the port number in which it is listening to clients. Monitor ? the monitor must comprise a GUI where the status is always logged: state of servers, service allocation to servers, rejected requests, etc. ? the GUI must allow the definition of the port number in which it is listening to servers. ? the heartbeat tactic can be implemented as one of the Monitors functionalities. ? the Monitor and the Load-balancer can share the same process and, as such, they can share a unique GUI. Servers ? server must comprise a GUI where every request and answer must be logged. ? the GUI must allow the definition of the IP and port where the Monitor is listening to servers

GUI must allow the definition of the port where a server is listening to requests (from the load-balancer) ? the GUI must allow the definition of the queue size to be used Clients ? client must comprise a GUI where every request and answer must be logged. ? The GUI must allow the definition of the IP and port where the load-balancer is listening ? The GUI must allow the definition of the requests to be sent to the cluster 3.5 Report The report must include: ? A block diagram representing the main entities (including the tactics) and the interactions between them ? A detailed description of how each UC was implemented. Must include source code snapshots to prove the description. ? A description of what has not been accomplished, partially and totally.

NOTA: the diagragrma dver be based on Client / server