Student:(Jose(García(Pérez(
Professor:(Hongying(Gu(
PFC(;(Final(thesis(
(
Zhejiang(University(; (
浙江大学（中国）
(
Facultat(d'Informàtica(de(Barcelona(((
Technical(University(of(Catalonia(
(
(
!
! !
! !
Zhejiang(University(Online(
registration(system(
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
online registration system, Assignments of Research Methodology
its good topic this topic is online student registration system this software
Typology: Assignments
2019/2020
1 / 38
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download online registration system and more Assignments Research Methodology in PDF only on Docsity!
Student: Jose García Pérez
Professor: Hongying Gu PFC -‐ Final thesis
Z h e j i a n g U n i v e r s i t y -‐
F a c u l t a t d ' I n f o r m à t i c a d e B a r c e l o n a
T e c h n i c a l U n i v e r s i t y o f C a t a l o n i a
Zhejiang University Online
registration system
Chapter:
Introduction
- Introduction Table of contents
- Current problem
- Proposal solution
- Description
- General scheme
- Registration process
- Scheme
- Design
- RMI
- Summary
- Decisions
- Security
- Implementation details
- Databases
- Summary
- Table details
- Web
- Summary
- Implementation
- Security
- Summary
- Password policy
- Parameter protection
- Private web zone protection
- Load balancing..........................................................................................................................................................................
- Summary
- Implementation
- Load tests
- Used software
- Used hardware
- Test design
- Results
- RMI
- Achieved objectives
Chapter: Introduction
Chapter: Proposal solution Proposal solution Description As described in the previous section, there are three problems to be solved separately. However, they are completely interrelated. For the problem of central servers, the solution is not simply to replicate them, since the problem cannot be simply the ability to process, but also the synchronization between them, the input data synchronization of the databases or the central server bandwidth. The solution is to make each faculty manage their registrations, which will free the loading process to central servers while the bandwidth is distributed to each faculty. There are some difficulties that must be taken into account: a) Security is an essential feature which has much more importance than others features. The system must ensure that the one who is performing the registration process is the one who is supposed to be. b) After the registration, the server will have the ability to connect with the central servers and insert information into their databases. This server-‐server connection will involve, apart from adding a security layer, a system of synchronization between servers. Again, all of this to avoid the collapse the central server connections, which is the main goal of the project. c) About the online registration: a. Due to the registration is done through the Internet, the system should take into account the high number of connections in a given time, which could become at most all the students that are supposed to be registered that day. Therefore, the implemented system cannot allow the collapse of the faculty servers. b. On the other hand, the implemented system must respect the pre-‐ established registration order (student priority). c. At any given time the load of a server that manages user access can be very high and therefore, the system implementation must divide the bandwidth and data load between one or more servers.
Chapter: General scheme General scheme Registration process
- A student accesses the URL of the Web application.
- This URL takes to a load balancing system that handles the request and redirects it to one of its servers.
- The student must authenticate him/herself.
- The student accesses the subject and group list available for him/her.
- Once the enrollment system is turned on, the student will access a website and his/her request will be inserted in the queue of that server respecting the registration priority order previously given by his/her faculty.
- This dynamic website will inform the student of the latest student which started the enrollment process and how many students are actually in the registration server. That will help the student to calculate the approximate time they must wait to finish the process.
- Once the faculty server checks that this student has the highest priority of all the queues (different servers, different queues), he/he will be allowed to freely decide which subjects and groups want to enroll (only if they are still available).
- The student will complete the registration once he/she has correctly chosen the subjects and groups to register. Now this data will be stored in the database of the faculty. This is the end of the process.
Chapter: Scheme Scheme The proposed solution to the current problem, according to the problems described above, has the following scheme: Insert image about scheme
Chapter: Desig n 1 (FrontEndListClient) as well as the common interface between two servers (FrontEndList). The client it’s only called when the front-‐end server is booted. -‐ Faculty server as client (StudentQueueFacultyServerClient) with threads, in order to be compatible with the service FrontEndList described above. The client performs a polling to all front-‐end servers checking who is the student with more priority and also, it generates 128 bytes tokens once it have free positions. -‐ Central server as client (InsertServiceClient), which performs a polling to the faculties servers.
Chapter: Design 1 Decisions The following decisions were taken for the implementation of these classes: -‐ The server and the implementation of the service StudentQueue is integrated in the init() function of the tomcat server. Considering the front end is both a client and a server, perform the implementation in this way it’s a good decision. -‐ To make an efficient connection between the tomcat and the registration server, and because in the faculty server the RMI is not integrated on the tomcat, there is a table in the database named registrations to manage the authorized students. Moreover, considering that the server should handle the power of a limited number of connections, the fact of using a table in the database does not subtract efficiency and nor pose threat to the integrity of the system. Finally, to control the timeout of a student who is waiting in a front-‐end server, the front-‐end server must notify the registration server that the student is no longer there. Thus, the database avoids the problem of using a servlet as an RMI client. -‐ A client can be connected simultaneously from 2 different computers, which may result in a client over more than a front-‐end. To ensure that the student is advised for all servers where is connected and to not spend more faculty slots of the registration server, when the registration server detects that the student has been already advised, it will send the same token as in the database.
Chapter: Design 1 Implementation details FrontEndListService The registration server is the responsible for publishing the service FrontEndList that allows the front end servers to announce themselves as news in order to be queried by the registration server. Sequence diagram
Chapter: Design 1 Add front end server (add_fe) This operation is executed from the front-‐end server once the tomcat server is booted. The goal is to announce that this server is an available server and that from now on the registration server as a client can make queries. The result of executing this function is that this server has been added to the server list on the registration server if none error has occurred. FrontendListClient The client implementation is simple:
- SSL authentication.
- Locate the FrontEndList service
- Call the add_fe function with its own ip and port address as parameters where its tomcat server has the service opened. FrontendListserver The implementation of the server is more complex, because the implementation is both a client and a server, which is only instantiated if there are one or more servers front-‐end servers available, so the system does not waste system resources unnecessarily. As a server only performs the following:
- Specify its key store.
- Publish the service. StudentQueueRegistrationServerClient Is the deployment of FrontEndListServer. As it is both a client that performs periodic queries, the operation add_fe has been implemented within a thread so that both operations can be performed without blocking each other. The deployment of the operation add_fe is as follows:
Chapter: Design 1 StudentQueue The front end server is the responsible of publishing the StudentQueue service, which is the server that allows the registration server to check who are the students with more priority in each front end server as well as send a token to the n students with more priority among all front end servers, so this one is advised by ajax. Sequence diagram
Chapter: Design 1 First client (first function) It is a call from the client (registration server) where each front-‐end server is asked for its first student in the queue. At the same time, it sends by parameter who is the last student allowed. Because the server is in fact the web server, ajax will update the waiting page of the student. As a result of the function, the student with more priority in this front-‐end server is got in order to be compared with the others so it gets the one with more priority in all the front-‐end servers. Registration Allowance It is a call from the client (registration server), which informs the front end that the student with the turn passed by parameter is now allowed to register. At the same time, a token is passed so tomcat using ajax, generates a button where the HTTPS petition includes it. The result of the function is a true if the student with that priority is no longer in the queue (exception) and false if everything worked as expected. StudentQueueRegistrationServerClient The implementation of the client is a thread that is periodically executed and does the following:
- For each front-‐end server in its list, execute the first function.
- Compare the obtained results and get the highest priority number.
- Query the authorizations database and check the count of authorized students. a. If the number is less than the max i. Check if the token for this student has already been created. If not, create a new one ii. Call the RegistrationAllowance function with parameters priority and student token.
- If everything is ok, insert token into the authorization database.
Chapter: Design 1 InsertRegistrations This operation is executed from the central server. It gives permission to the registration servers to insert a limited number of registrations; this limit is passed by parameter. InsertClient Obtain the list of faculties that are supposed to make tuitions with the time and date that is in the database. Identify itself as a secure client. For each obtained server, check if it has the InsertServer service on. InsertServiceImpl InsertRegistrations. _1) Open connection with the faculty database.
- Select the n smallest TuitionIDs that has not been yet synchronized.
- Open connection with the university database.
- Select all the data of these Tuitions
- Insert all this data into the university database.
- Close the connection with the university database. a. If everything is ok, update to true the sync field for each tuition that has been inserted._
Chapter: Design 2 Databases Summary To deploy the database server MySQL was chosen for being an Open Source product prestigious and powerful documentation and support. There are three databases: Faculty Core database of the faculty with the main information of students and subject availability for each of the students. Registration The database used by the registration server. Its function is to take control of the access of the students and their tokens as well as save the registration information for later be able to pass it to the central server. Central The database of the central server. It saves the information of the faculties that has to be connected and also the registrations of all the students of all faculties. The databases have been designed so that queries that have to do the different systems could be resolved by a single table, which make them more efficient. This is important due to, with all the features of the system, without this design, the database could result in a bottleneck. Also because of this, the queries launched by each front-‐end server to show the availability of places for each student, has been resolved by a single thread. This thread is executed every five seconds and updates the information about free places of all the groups on the front-‐end servers. After that, the front-‐end servers have the information ready to be shown to each student according to the subjects that can be enrolled by him/her. For security reasons, for each server and database, different users and passwords have been defined as well as read/write permissions for each of them. SHA encryption has been used to store the passwords.