Software Requirement Specification

Transcription

1 Software Requirement Specification Publish/Subscribe System Group-03 Atul Jangra 2010CS50277 Dushyant Behl 2010CS50282 Shantanu 2010CS50295 Utkarsh 2010CS

2 1. Introduction Table of Content 1.1 Purpose Motivation Scope Glossary Overview Overall Description 2.1 Product Perspective System Interface User interface Hardware Interface Software Interface Communication Interfaces Memory Constraints Operations Product Functions Context Diagram Use Case Diagram Application Features User Characteristics Constraints Assumptions and Dependencies Specific Requirements 3.1 External interface Terminal Client Interface User Management Interface Account Creation Functional Requirements System Management System Monitoring Account Creation Account Removal Session Creation/Authorisation Message Sending Performance Requirements Logical Database Requirements

3 3.6 Design Constraints Software System Attributes Reliability Availability Security Maintainability Portability Organising Specific Requirements

4 1.0. Introduction 1.1. Purpose The purpose of this document is to present a detailed description of a publish/subscribe system,. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system Motivation of Project As the number of mobile devices is increasing, the number of users expressing interest in pub-sub system is increasing. To deal with the ever increasing demand of the users, a robust middleware software system is required which would be capable of handling the large number of users and, capable of scaling horizontally to keep the service cost effective Scope of Project This software system will be a middleware system for providing the pub-sub service. It will be designed to deliver published content to the users who have subscribed to it. The system will use a unique identification such as username to identify the users on terminal servers and then push content to the devices affiliated with that username. This project will enable users to get access to content which is according to their interest as well as it provides a platform to content publishers for reaching users. The project aims at developing this middleware independent of the operating system platform. The middleware is concerned with the content delivery aspect to the subscribers Glossary Java NIO: Java New I/O, usually called NIO, is a collection of Java programming language APIs that offer features for intensive I/O operations Pub/Sub: A publish subscribe system that delivers messages to a large group of users subscribed to a particular topic Middleware: Middleware is computer software that connects software components or some people and their applications Admin User: Administrator of the system 4

5 Terminal User: The subscribing user who will receive the messages and broadcast messages to specific rooms with permissions 1.5. Overview The next chapter, the Overall Description section, of this document gives an overview of the functionality of our system. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the system. Both sections of the document describe the same software system in its entirety, But are intended for different audiences and thus use different language Overall Description 2.1 Product Perspective This publish-subscribe pattern based middleware system relies on Java NIO API for implementation. This system will be used by enterprises for a variety of purposes such as data-push services, pub/sub broadcast services or any other service which needs multicasting messages to millions of users simultaneously. The system can simultaneously be used for a chat type application, where users would want to send real time text-based messages to each other. The system will be a layered-clustered environment capable of scaling each layer individually as depicted in the following schematic: 5

6 Figure 1: Schematic for the server design System Interface The system being developed will consist of the software application that will be running on the virtual/real hardware. The user of this system will need to follow the following steps: Arrange the desired hardware for the server system in the three layers, virtual or real. Connect the hardware together in an overlay network. Run the Java based programs on the terminal, data forwarding, and the data processing layers. Use an admin machine to monitor the working of the server system. 6

7 User Interface The primary user of this system will be the middleware administrator who will monitor the system s working and hence the user interface would be consist of the following. Options to view the live throughput across different data layers. Interface to view data throughput, connection counts and load monitoring for all the servers. Option to monitor a particular server periodically and also to take down a server in maintenance mode. Interface to replace a particular server with another server. Interface to add/remove new set of servers to a particular layer. Interface to control the connections of a server in any layer to the servers of the other layers Hardware Interface The Hardware involved in this system will be a set of real or virtual servers. This system will be compatible with virtual hardware services such as Amazon EC2 instances Software Interface The system has software interfaces spread across different layers of the system. The servers in different layers will be running software developed in JAVA on Linux based operating system. The administrator shall have a web based monitoring system so as to monitor the server system of Communication Interface The system will need a variety of communication interfaces: Communication between various parts of the clustered environment. This will be using TCP sockets to maintain the necessary communication. Communication of the system with the various users. More precisely, connection of the terminal server layer (Figure 1) with the users. This connection will be created by using java.net.serversocket and java.net.socket from the Java NIO API and will also be based on TCP sockets. 7

8 Memory Constraints Terminal Servers: The terminal nodes requires connecting to a target of over 1 Million clients simultaneously and hence the memory consumed in establishing connection to the clients must not be large so as to prevent overflowing the memory limit of the system. Data Processing/Data Forwarding Servers: The nodes in these layers should be memory efficient in such a way so as to handle maximum connections for the same memory limit. The memory limit here should be kept low so as to prevent the systems from thrashing. Admin End: The Administrator system will be running a simple web server for helping in management of the system, which will not be memory intensive and hence no specific memory requirements for this Operations 1. Terminal User Operations Create a new account - The user should be able to link existing third party accounts with his existing account, or create a new account in, using username and password as credentials. Manage Sessions - The user should be able to disconnect any existing session remotely, if he can t logout from the session from the Terminal Client. Authorize Persistent Socket - The user has to authorize himself on starting a new connection on a terminal server, using a service name, with his secret key (OAuth 2, in case of third party authorization). The user with this secret key must be already registered on the system. Send Message - The user can send message to another user, or a pub/sub room (if he has publishing permissions for the room). 2. Administrative User Operations Add a new server - Add a server instance in any layer on the already deployed system. Replace a server - Replace an existing server in the deployment for upgrading with zero-downtime. Get traffic information on any server Get number of clients connected on any terminal server 2.2. Product Functions The system aims to be a pub/sub system, and an XML based chat system at the same time. Any client that is connected on a terminal server is guaranteed to receive both types of messages, message published in rooms that he is subscribed to, 8

9 and messages sent to him directly. The client can have multiple simultaneous sessions, so that any message that is sent to him is received on all devices connected using his credentials Context Diagram Figure

10 Use Case Diagram: Figure Figure

11 Application Features: Terminal User The user can create a new account, or connect using a third party account like Twitter, Facebook or Google. The user can send messages to a specific user. The user can subscribe to various rooms which will be listed on the client-side application. The user can sign in using one of multiple third party accounts registered with his username. Admin Interface User The user can view the live throughput across different data layers. The user can view data throughput, and connection counts for all the servers. The user can monitor a particular server periodically and also to take down a server in maintenance mode. The user can replace a particular server with another server. The user can add/remove new set of servers to a particular layer.4 The user can control the connections of a server in any layer to the servers of the other layers User Characteristics The user in our system will be the System administrator of the enterprise using this system. This the user is required to know some basic shell scripting, networking and should be able to monitor the load of different servers used in the clustered environment. 2.4 Constraints The major constraints in this project would be the availability of hardware. Decent amount of hardware is needed for the testing of. 2.5 Assumptions and Dependencies We are assuming that the user will be able to tweak his Linux kernel to allow maximum number of sockets that can be created from the Machine. The software also depends on Java NIO APIs. If the API is modified then the developer will have to edit the software to make it compatible with the latest API. 11

12 3.0. Specific Requirements 3.1. External Interface The system has three primary interfaces - Terminal Clients - The users of the pub/sub system who will maintain a persistent socket connection to the deployed system. Any message that needs to be sent to the group of subscribed users, and / or a single user will have to be sent on this persistent socket connection. User Management Interface - This is a set of web APIs in system, through which new users may be registered, a particular user may manage sessions, a user may be unregistered, etc. Administrative Interface - The system will provide an administrative web interface, through which the administrator of the deployed system, will be able to manually change specific layer configurations, and also adjust parameters for individual servers, like maximum users to be connected to a particular server, etc Terminal Client Interface Authorization - Whenever a new user connects with the Terminal Client through a TCP socket, it is required to authorize itself for being able to send and receive any messages. The server will provide an XML interface that the Terminal Client will use for authorizing the socket connection. The server will authorize the Terminal Client on the credentials sent by the Terminal Client. Once a Terminal Client is authorized, the server will add that particular connection to the set of online connections associated a user, and any messages sent for this user will also be forwarded on this socket connection. Receiving Multicast Messages - The server will accept messages for subscription rooms by room administrators, through the terminal client s TCP socket. Every message that is received by the server should contain the target message room, or the usernames of target users. If the message is supposed to be sent to a room, the server checks if the sender has permissions to publish to a room, otherwise if the message is targeted to a set of users, the server checks if the sender has permissions to send to the targeted recipients, and then forwards the message. Sending Multicast Messages - The server will queue up the messages targeted for a specified username. If one or more Terminal Client instances associated with the username are connected, the message is immediately forwarded to the user on the Terminal Client socket connection. If no instance of a Terminal Client is connected for that particular user then the message may get stored in the 12

13 database temporarily (only if the message is directly targeted for the user, and not targeted for a room) User Management Interface User Registration - Any new user of the application will be prompted to create a new profile or login using any existing Gmail / Facebook / twitter account. The server will receive requests for registering the user and adding him to the database of existing users. Manage Session - A user may wish to log in (using the Gmail / Facebook / twitter account he registered with) and end existing user sessions. The server system will abruptly close the Terminal Client TCP socket on receiving such a request. Remove Account - The system will also provide APIs to allow the user to remove an account. When the user wishes to remove the account, the server will make him authorize again for security purposes Administrative Interface Connect Terminal Server System to Data Processing Server - The Administrative Web Interface will provide an option to add a Data Processing Server to the Terminal Server, so that the terminal server can load balance incoming traffic in Terminal Server Layer. Connect Data Processing Server to Data Forwarding Server - The interface will provide an option to connect a Data Forwarding Server with a Data Processing Server, so that the data processing server can forward the message body, after authorization, and finding specific Terminal Servers to which the message data is to be forwarded. Connect Data Forwarding Server to another Data Forwarding Server - The administrator should be able to connect different data forwarding servers with each other so that they may be able to send a message from any single terminal server to any other terminal server. 13

14 3.2. Functional Requirements Use Case: System Management: Introduction: Allow the system administrator to manage the system. This includes upgrading a particular server with another server, add/remove new set of servers to any layer and controlling the connections of a server in any layer to servers of the next layer. Actors: System Admin. Pre-Conditions: Administrator must be logged in to the web-based management system of. Post-Conditions: The action specified by the admin is performed and the system state is updated accordingly. Basic Flow: Action starts when the administrator issues a request. If the admin requests to upgrade a server then will start the node upgrade process which will acknowledge the admin after process completion accordingly. If the admin requests to add/remove new set of nodes to any layer then will ensure the process completion with proper acknowledgement. If the admin requests to reorder the connection of a node with other nodes in the next layer then also will ensure the connection reordering with proper acknowledgement Use Case: System Monitoring: Introduction: Allow the system administrator to monitor the state of the system. This includes monitoring any server / layer etc. Actors: System Admin. Pre-Conditions: Administrator must be logged in to the web-based management system of. Post-Conditions: The data asked by the system admin is provided to him through the same web-based interface. Basic Flow: Action starts when the administrator issues a request. 14

15 The data asked by the admin about any server / layer is passed on to the admin through the web based monitoring system. 15

16 3.2.3 Use Case: Account Creation: Introduction: Allow the terminal user to create a new account with. Actors: Terminal User. Pre-Conditions: None. Post-Conditions: A new user account would be registered with. Basic Flow: Action starts when a new user wants to create an account with. The Terminal user issues a request to create a new account with with user credentials. adds the new user to the registered users database. acknowledges the user that a new account has been created. Alternate Flow: User Already Registered If the user is already registered with the system send the user acknowledgement that the account is already registered with system state unchanged. Registration failure If the registration fails in between due to any reason then will tell the user about registration failure and simply ask him to register again Use Case: Account Removal: Introduction: Allow an already registered terminal user to delete account from. Actors: Terminal User. Pre-Conditions: User should be already registered with. Post-Conditions: The user account should be deleted from. Basic Flow: Action starts when a new user wants to delete his account from. The Terminal user issues a request to delete his account from. asks the user for user credentials to verify the actual user. The User provides the asked user credentials to verify his/her account. authenticates the user and delete his account from the system. 16

17 Alternate Flow: User Not Registered If the user is not registered with the system the authentication will fail and will send the acknowledgement that the account is not registered with leaving system state unchanged. Account deletion failure If the account deletion process fails in between due to any reason then will tell the user about process failure and simply ask him to restart the process again. Figure Use Case: Session Creation/Authorization Introduction: This use case corresponds to the creation of a new session by an already registered user. Actors: Terminal User. Pre-Conditions: User should be already registered with. Post-Conditions: A new user session would be established with the system. Basic Flow: Action starts when a new user wants to connect to. 17

18 The Terminal user issues a request to create a new session with. asks the user for user credentials to verify the actual user. The User provides the asked user credentials to verify his/her account. authenticates the user and establishes a new session with the system by creating a new TCP connection with the user through one of the terminal servers. Alternate Flow: User Not Registered If the user is not registered with the system the authentication will fail and will send the acknowledgement that the account is not registered with leaving system state unchanged. Session creation failure If the session creation fails in between due to any other reason then will close the sockets opened to connect to the user to free any stale used resources Use Case: Messaging Sending: Introduction: Allow the terminal user to send a message to another user registered on, or a publishing room in. Actors: Terminal Users. Pre-Conditions: The User sending the message should be connected to a terminal server, and authorized on the server. Post-Conditions: The message sent by the user will be delivered to intended recipients. If the recipient is offline the message is saved for room targeted messages, otherwise discarded for direct user messages. Basic Flow: Action starts when a connected user sends a message to be broadcast on a room. The Terminal User sends a message, along with the intended target. checks if the sender is authorized to publish the message in the given room, and publishes the message in the room accordingly. Alternate Flow: Intended target is another user checks if the sender has permissions to send the message to the intended recipient user, and sends the direct message accordingly. Intended target is not present will discard the message altogether. 18

19 Figure Performance Requirements Number of Users: Each terminal node is targeted to connect to 1 Million number of end users and maintain a persistent TCP connection to each user. Minimizing Latency: should also ensure that the latency between sending and receiving message through this system should be minimum, no matter how many recipients. Maximizing Throughput: should ensure maximum throughput through each of the nodes in the system, i.e. the data flow through each node should be maximized keeping latency as small as possible. Upgrading Nodes: should also ensure zero downtime upgrade for every node in the system. 3.4 Logical Database Requirements 19

20 For the process of authorisation at the terminal server, we need to store the user ID and the corresponding secret key for all the registered users. When a new user is registered, we need to add to database the new user ID and its secret key. For a particular user, we need to create columns for the different accounts which user could be using with our system. For each account, we need to store the login credential, which may be of following forms: Username and password in case of a simple account(not using OAuth). Username, appid, and secret authorisation key in case of services which using OAuth 2.0 such as Google, Facebook, and Twitter. For the case, when the user is not connected to the terminal server, we may need to store the message that is needed to be sent. The information about all the devices connected to a specific account is also needed to be stored in a database. The internal information about the different server will be stored. This will include the IP address of different machines, category (Terminal server, data forwarding layer, Data processing layer), and virtual ID of the machine. The message history of each room will also be saved in a database. Message history storage will not be done on the system in case of the direct messages. In this case, the history will be saved on the client side, so that it is available to the user. A table for different rooms will also be present. This table will contain all the necessary room-related information such as room administration, room members, room status messages, etc. 3.5 Design Constraints Not applicable 3.6 Software System Attributes Reliability Any message that is sent to the user has to be necessarily received by the user (provided that the user is connected). If the user is not connected then he may only receive the messages published to rooms instead of direct messages sent to him. 20

21 3.6.2 Availability The terminal users are supposed to maintain a persistent TCP socket connection with Terminal Servers, and the servers may receive messages to broadcast at any time. So, the complete system must be up and running always. Any upgrades to the system should have zero downtime Security The system must make sure that the users who are broadcasting messages to the rooms have publishing permissions for the room. If the user is sending a direct message to another user, he must have permissions to send direct messages to that user Maintainability The system has to provide an administrative interface so the layers can be connected with each other. The system should also allow upgrading with minimum downtime (for Terminal Servers), and zero downtime for other servers Portability Portability is not a requirement of this system, as the system is to be deployed once on any machine that can support Java Organizing specific requirements Not applicable. 21