Threads is a distributed application which facilitates inter-computer and inter-personal communication requirements of a grid of computers assigned for a specific development process.
Summary of scope
- Adding projects
- Live group chat
- Real-time notifications
- Progress and productivity graphs
- Project/Step/Task item and responsibility management
- Employee management
- Developing ZeroMQ based request-reply functionality for processing application specific objects
- Mapping the distributed substructure into classes and interfaces to ensure cohesion and reusability
- Progress and productivity graphs
Detailed Functionality
Authorization
Each node automatically logs in to the grid at the system start up. Application would run in the background and user will be able to open the application dashboard through the taskbar icon. In initial login user or node can log into the system after entering username and password.
Project Initiation
Project manager would be able to add multiple projects to the application for tracking. Upon adding a project he will be asked to add members to the project and divide it into any number of major sections that needs to be completed and assign a member to each. The tasks would require to be given a deadline. It would be divided again to sub tasks the member need to perform in a specific order, and each would also have the function to be given a deadline. The weight of the task in consideration with the entire project, and the weight of a subtask in consideration with the parent task would be also added to track the project completion status in future.
Node Computer functionality
In case a new member is assigned to the node computer, they will be required to logout and log in to the application with the new credentials. Members will be given the option to submit the issues that arise during their development process and other members would be able to answer those questions. The computers will be connected to the group chat at all times for ease of communication.
Projects assigned to each member and their respective tasks would be loaded at the startup. Member would be able to divide these tasks in to simpler subtasks and give personal deadlines or priorities to them. Members will also have the ability to add “Sticky notes” for reminders and other important notes.
The major task deadlines would be notified to the user at reminder times specified by the user.
These members will also have the ability to view their own performance reports and track their assigned task progression.
File synchronization/ sharing
The system generates real time notifications after task completion and transfer necessary information to the node responsible for next task. The end product files of the first task would be transferred to the file server and the next node will be informed of their location.
Charts
Analysis charts are displayed in the expanded views of Project and Step view items. Also few more customized charts regarding employee involvement is also displayed in the dashboard.
Application Distribution
The client computers do not necessarily have to be in the same network, they will be communicating with the application server at all times and therefore would not have any peer-to-peer connection. The application server and the database server however, would require a more point-to-point communication link since the database access is purely limited to the application server.
The Application Server would receive requests from clients for various data requirements. Application Server would connect to the database server, retrieve data and send back to clients. This enables users to communicate over long distances, spanning over a large physical area.
Clients and Application Server both has access to the file server over the network, which is defined by the users of both sides upon configuration.
Threads Project Management Application is designed for maximum of 40 users, who work in small groups, possibly in a computer grid capacity with their own hosts having individual resources to a certain extent. If a new application server instance is hosted in a separate machine, the application could be used by any number of groups. This is to decentralize the project information and server certain security and privacy purposes.
In the network diagram hosts are arranged in a star topology and the Application server is placed in the middle of the network. Between Database server and Application server there is a point to point connection. Node access to database server is restricted.
Implementation
Message Queue based communication
For reliability purposes we decided to use ZeroMQ socket implementaions. ZeroMq is a light weight Message Queue kernel which extends the functionality of standard socket interfaces and supports host connectivity in a wide range of platforms. In context of Java language, JeroMq, a pure java implementation of ZeroMq core libraries, was used in the project.
Port Utilization
The application uses multiple ports to distinguish the object types in its functionality.
Clients use 3 ports in this application
- Object Request and Retrieval port
- Notification Listener Port
- Message Listener Port
Apart from those, Server also has two more ports
- Notification Retriever Port
- Message Retriever Port
Object Request and Retrieval port is singular, since each data need of a person could possibly affect the next request. Therefore in using the message queue technology, every request is processed in order without causing conflicts.
However, Messages and Notifications must have the push-up notification function, and must be immediate, therefore those functionalities are implemented with the use of separate ports.
Object and Method Recognition
The application handles multiple unique objects that were defined for the application at both client and host ends. Therefore a separate class library was created for serializable objects which could be converted into Byte Arrays and transferred over the network. The class library was included in both Server and Client projects and the project was implemented on this basis.
A singular object, “Requester” was defined with a HashMap variable within, helping the application to mimic the functionality of a POST data submission in a webpage through putting key, value pairs into the hashmap. This object was retrieved, checked for the label (“callingMethod”) of the object that it’s carrying and forwarded to the respective object service processing class.
The Object Service Processing Class would then switch upon the label (“callingMethod”) of the object and forward the data to a particular function inside the class.
This was achieved through Switching on the labels upon each retrieval.
Limitations and Future Work
There were certain performance anomalies in application development which made the practicality of it uncertain. The request response time between client and server varied in different scenarios such as Google Cloud SQL database connection and local host MYSQL connection. This will be optimized in the next release of the application.
The amount of data that should be stored in the memory was also a controversial aspect, due to this data being prone to change and yet being required for the group chat and notification purposes. This issue will also be addressed in future. A few currently excluded features originally intended such as report and email functionality will be also implemented in future.