LOVELY PROFESSIONAL UNIVERSITY
SRS OF CAPSTONE PROJECT
TOPIC : ENTERPRISE WEB SERVICE ARCHITECTURE
Submitted by: Md. Mehtab Khan Kwatra 10802698 RK18E1B41
Submitted to : Ms. Chetna
Software Requirements Specification Document
Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations. 1.4 Overview 2. The Overall Description 2.1 Product Perspective Figure: Web Architecture based on LAMP Architecture 2.1.1 System Interfaces 2.1.2 Interfaces 2.1.3 Hardware Interfaces 2.1.4 Communications Interfaces 2.1.5 Operations 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 2.6 Apportioning of Requirements. 3 Best Performance Requirements 3.1 Reliability 3.2 Availability 3.3 Security 3.4 Maintainability 3.5 Portability 4 4 4 4 5 5 6 6 6 7 7 7 7 8 8 8 8 9 9 9 9 10 10 10
1. Introduction
The Enterprise Web Infrastructure is an infrastructure to run websites on multiserver web-hosting platform. This infrastructure would provide better resource availability. This platform is equipped with best available load sharing tools,which will make it more effective than other available web architectures.
1.1 Purpose
This web architecture would provide higher uptime and resource availability than other web architectures. It would provide best functionality than others with the common servers systems in use with the help of load sharing and better configuration and with reprogrammed software-specific modules.
1.2 Scope
Following is the scope of the architecture: (1) this architecture would be called as eXtremely Lite Enterprise Web Architecture (2) Enterprise web architecture is the web architecture which will provide ligher control panel specifically designed for the slow connections, easy file transfers, and with quite simple usability than others. (3) This architecture would be designed differently for every different kind of web hosting customers, starting from small or novice ones to big and advanced users. (4) This infrastructure would be specifically designed for best performance with the ordinary server systems in use and to provide the simplest functionality.
1.3 Definitions, Acronyms, and Abbreviations.
World Wide Web (Web) A widely used information system on the Internet that provides facilities for documents to be connected to other documents by hypertext links, enabling the user to search for information by moving from one document to another. Website A location connected to the Internet that maintains one or more pages on the World Wide Web. Web Server A web server is a computer program that delivers (serves) content, such as web pages, using the Hypertext Transfer Protocol (HTTP), over the World Wide Web. The term web server can also refer to the computer or virtual machine running the program. PHP (Preprocessor HyperText Programming)
PHP is a programming language used almost exclusively for creating software that is part of a web site. The PHP language is designed to be intermingled with the HTML that is used to create web pages. Database Management System (DBMS) Database management system is a software system that facilitates the creation and maintenance and use of an electronic database. MySql MySQL is a relational database management system (RDBMS) based on SQL(Structured Query Language). First released in January, 1998, MySQL is now one component of parent company MySQL AB's product line of database servers and development tools. Apache Apache is a freely available Web server that is distributed under an open source license. It is the most widely-installed Web server. LAMP ARCHITECTURE LAMP is an acronym for a solution stack of free, open source software, originally coined from the first letters of Linux (operating system), Apache HTTP Server, MySQL (database software) and Perl/PHP/Python, principal components to build a viable general purpose web server
1.4 Overview
(1) It would contain all the specification of this architecture (2) This document would contain description, minimum system specifications, best performance system specifications, and software-specific requirements.
2. The Overall Description
Web architecture is an approach to the design and planning of websites which, like architecture itself, involves technical, aesthetic and functional criteria. As in traditional architecture, the focus is properly on the user and on user requirements. This requires particular attention to web content, a business plan, usability, interaction design,
information architecture and web design. For effective search engine optimization it is necessary to have an appreciation of how a single website relates to the World Wide Web.
2.1 Product Perspective
This architecture is specifically designed for web hosting for different kind of users (From novice to advanced users). Control Panel would be designed with simple features for the novice users and would be highly customizable for the advanced users. Properly configured Load Balancing between web servers would be increasing the performance output of the architecture. This architecture would be dependent on LAMP architecture, so its development requires good knowledge of Linux Systems, Web Servers, Website development, PHP, Apache, Database, Mysql (Specifically), Website Control Panel development, Database Mining, etc.
Figure: Web Architecture based on LAMP Architecture 2.1.1 System Interfaces This architecture includes completely independent development of all of its components and needs no system interfaces to interact with any foreign systems for any kind of inner functionality. For Web users some of the system interfaces (API) can be provided, but
they are also easily available to the users from web, like Google Maps API, Facebook Apps, etc. 2.1.2 Interfaces (1) Architecture would provide three kinds of Website Control Panel Components. Control Panel would be differently designed for Novice, Mediocre and Advanced users. (2) For New users, Control interface would be simplest, easy to use and option would be designed and pronounced in simple english and technical names would be almost avoided in that. (3) For Mediocre and Advanced users Control Panel would be equipped with all technical options. Only thing which varies would be density of technical features. For mediocre ones, it would be less and more for the advanced users. For the users the interaction with the system would be designed in the form of GUI control panel for the normal website hosting and a dedicated web server CLI interface for the advanced users would be also available. 2.1.3 Hardware Interfaces It would be a linux systems based architecture and would require at least 1 GB of RAM and 8 GB of HDD Space for Minimal Installstion of RHEL5/CentOS5. For best performance as a web server RHEL5/CentOS5 would require 2 GB of RAM and 80 GB of HDD Space, out of which 50-60 GB would be provided to the web root. For the minimal installation of RHEL6/CentOS6 it would require at least 12 GB of HDD space and 1 GB of RAM, but for best performance it would require 120 GB of HDD space and 4 GB of RAM with at least 80 GB of HDD space given to web root. For the best performance of this Architecture it would require at least two web-hosting servers with 120x4 SCSi HDD Drives with RAID level 3 configuration and Intel Xenon Core 2 Duo 2.0 with L2/L3 512Kb/2Mb and with 4 GB of RAM for each of the systems. 2.1.4 Communications Interfaces This architecture would require Internet Protocol (IP) addresses to communicate with web clients. In addition it would require HTTP/HTTPS for web transport, SMTP/POP3 for mail send/receive, SSL/TLS for web security and some transport layer protocol for load balancing.
2.1.5 Operations This architecture would requir some normal and special operations required by the user such as: (1) The various modes of operations in the website control panel (2) Periods of interactive operations and periods of unattended operations (3) Data processing support functions
(4) Backup and recovery operations
2.2 Product Functions
This architecture would provide following specific component and user interface dependent functions: (1) Easy Website Management with simple and advanced Control Panel features (2) Avoidance of useless functions in the Website control panel (3) Better performance with load balancing act between web servers (4) Improved Apache/Linux Performance with fine tuning and reprogramming of some featured components (5) Well designed database to increase the performance and to minimize the query time (6) Easy to use mysql console. MySQL would be accessible through GUI and CUI console options. (7) Better system security through TCP wrappers and IPTABLE firewall equipped in linux systems. (8) Better web security through optional HTTPS and SSL/TLS security protocols
2.3 User Characteristics
Management of the server systems would require technical expertise on the website hosting configuration and other related technical skills. Server side management would be done by the highly technical and experienced professionals.
2.4 Constraints
There may be some items that will limit the developer's options. These can include: (1) (2) (3) (4) (5) (6) (7) Regulatory policies Hardware limitations (for example, signal timing requirements) Interface to other applications (if required) Parallel operation Audit functions Control function programming Higher-order language requirements (8) Signal handshake protocols (for example, XON-XOFF, ACK-NACK) (9) Reliability requirements (10) Criticality of the application (11) Safety and security considerations
2.5 Assumptions and Dependencies
This architecture would be dependent of linux systems. In case linux server would fail, this architecture would be able do nothing, and would be provide less accessibility than the normal performance. Software failure can also cause whole system failure or lower performance. This architecture is completely dependent of the network and in case of network failure, this architecture would automatically get failed.
2.6 Apportioning of Requirements.
Some linux system code improvements, apache and mysql server fine tuning or recoding, and network performance enhancements may be delayed until future versions of the system. Time or technical knowledge may create the hinderance in development of these features. In the case of timely delivery, some research cases may get pending till the future version or until next service pack for the same version.
3 Best Performance Requirements
This section specifies both the static and the dynamic numerical requirements placed on the software or on human interaction with the software, as a whole. Static numerical requirements may include: (a) The number of linux system to be supported in one setup would decide the performance of the architecture (b) The number of simultaneous users may be limited or large number of users may affect the performance (c) Performance of the architecture would be dependent on the kind and amount of information (d) 95% of the transactions shall be processed in less than 1 second (e) An operator shall not have to wait for the transaction to complete.
3.1 Reliability Reliability of this infrastructure would depend on various components. These Components includes software and hardware specifications. Hardware components would include Server Hardware, Network Hardware and Load Balancer (in case a hardware load balancer would be used). Software components would include Linux, Apache, Mysql and other programmed interfaces. 3.2 Availability The degree to which a system, subsystem, or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an
unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition. This is often described as a mission capable rate. Mathematically, this is expressed as 1 minus unavailability. The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval. For example, a unit that is capable of being used 100 hours per week (168 hours) would have an availability of 100/168. However, typical availability values are specified in decimal (such as 0.9998). In high availability applications, a metric known as nines, corresponding to the number of nines following the decimal point, is used. In this system, "five nines" equals 0.99999 (or 99.999%) availability. 3.3 Security WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security. The factors that would protect the architecture from accidental or malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to: Utilize certain cryptographic techniques Keep specific log or history data sets Assign certain functions to different modules Restrict communications between some areas of the program Check data integrity for critical variables
3.4 Maintainability Specify attributes of software that relate to the ease of maintenance of the software itself. There may be some requirement for certain modularity, interfaces, complexity, etc. Requirements should not be placed here just because they are thought to be good design practices. If someone else will maintain the system 3.5 Portability Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include: Percentage of components with host-dependent code
Percentage of code that is host dependent Use of a proven portable language Use of a particular compiler or language subset Use of a particular operating system
Once the relevant characteristics are selected, a subsection should be written for each, explaining the rationale for including this characteristic and how it will be tested and measured. A chart like this might be used to identify the key characteristics (rating them High or Medium), then identifying which are preferred when trading off design or implementation decisions (with the ID of the preferred one indicated in the chart to the right). The chart below is optional (it can be confusing) and is for demonstrating tradeoff analysis between different non-functional requirements. H/M/L is the relative priority of that non-functional requirement.
