Design document for content delivery tool Brahaspati 1

Size: px

Start display at page:

Download "Design document for content delivery tool Brahaspati 1"

Gordon Goodwin
5 years ago
Views:

1 Design document for content delivery tool Brahaspati 1 Y.N.Singh, A. Roy, Vijay Singh, A.P.Das, Aloukik Khuntia August 23, Guru of Devas

2 Abstract Design and development of platform independent, scalable, multi-server software system to conduct online courses and to delivery offline course material in variety of forms over a LAN and internet. This design document gives design goals and various design decisions and details of the system. Copyright (c) 2002 ETRG,IIT Kanpur. All Rights Reserved. Redistribution and use of this and other document, source and binary files in the Distribution of this software Brahaspati in any forms, with or without modification, is permitted provided that the following conditions are met: Redistributions must retain the above copyright notice, this list of conditions and the following disclaimer. Redistribution must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or other materials provided with the distribution. THIS SOFTWARE AND THE ACCOMPANYING DOCUMENTS ARE PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PAR- TICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ETRG OR ITS CONTRIB- UTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHER- WISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

3 Contents 1 Objectives What is to be achieved in long run? introduction Description of functionalities Authorization, authentication and access control Authentication Authorization XML document archiving, version control and publishing Archiving, and version control Publishing Profile customisation course area Interaction tools Study tools and evaluation tools Search Engines and Course specific calendar Log and users information at various points Issues Involved Naming System for files Document Authoring tools architecture Overall proposed system architecture Model View Controller View Implementation Functional Description Authentication in multiserver architecture Implementation Details The Web Application Server Session Tracking Data Storage System segments and interaction between them Authentication segment Psuedocode for methods

4 Chapter 1 Objectives 1.1 What is to be achieved in long run? This system should provide the online university. It should have users classified as students, instructors, tutors, deans etc.. The instructor can post lecture notes, learning material, which can be accessed by authorised students. The class members can interact and do academic discussion by various means. Live classroom session with interaction should be possible. There should be self evaluation mechanism to monitor the progress. It should be possible to conduct the examination and thereafter evaluation to certify the students. 1.2 introduction The software is proposed to be server side software providing access to user using web browser interface. In future, the server which uses the APIs generated out of this effort, as well as specific client will be built. Then the user need to have only client software. Also, client version which can run as applet will be built. The important features of the proposed software are Multiserver software system scalable platform indepedent The functionalities to be given in this system are as follows. Authorization, authentication and access control for each access to system. XML document archiving with version control and publishing. User screen customization Interaction tools: chat, whiteboard, , instant messaging, discussion boards. Log and users accounting information at various points; scripts to process the logs (management). Study tools (students presentation) and evaluation tools (quizzes and self test). 3

5 Search engine (course local and site global), calendars for time management for students and instructors. News and advertisement tinkers at the users screen. The software system can be broken down into the components on the basis of functionality and desirable features. There are many issues involved such as. Naming system for files. Document authoring tools 4

6 Chapter 2 Description of functionalities 2.1 Authorization, authentication and access control Authentication This is accomplished through the use of a shared secret. The shared secret is something both the server and the client know. The authentication data contains sufficient information to specify to which domain the user belongs Authorization After authentication, if the user is found to be genuine his profile information is accessible from a table in database. This includes registration number (user ID), apart from other personal information. The registration number now becomes our key for finding what can be accessed by the user. Each course is considered a resource. All the files in the directory heirarchy below a node are part of the resource owning the node, unless the node have access control list. In that the any subdirectories will have access list decided by the access list of node. There will be four type of access control related files which should be maintained. File 1 This is single global file. It will contain list as shown below. user1 resource1, resource2, resource3 user2 resource1, resource2, resource4 File 2 This is also single global file. It will contain list as shown below. user1 group1, group2, group3 user2 group2, group4, group5 File 3 This is also single global file. It will also cotain the list as shown below. group1 user1, user2, user3 grpup2 user2, user4, user5 File 4 This is one file for each resource. It will also cotain the list as shown below. group1 access permissions grpup2 access permissions The allowed permission can be read, write, execute, backup, restore. Various informations can be stored in mysql database. These are described below. Profile: This table has the fields User ID, password, registration no., first name, last name, address, ID, phone number. 5

7 Access Control Access control is implemented at the system level. For example whenever an instructor uploads a file in a particular course, this file s access control will determine that it can be modified only by the instructor/ administrator. 2.2 XML document archiving, version control and publishing Archiving, and version control The material can be uploaded by instructor. The instructor can upload the material with a switch option enabling or disabling version control. We are planning to use CVS (concurrent versioning system) implementation in java (Slide) to do the version control. It is possible that more than one person can modify the content and then accept the changes to create final copy Publishing The archived course material has to be published in some standard format. For this we need some mechanism by which the content is transformed to the desired format which can be interpreted by the browser. Desired format for publishing will be xml. But publishing in html will also be supported. At the time of publishing, all the local reference will not be converted to reference to appropriate servlet with appropriate parameter. Only the copying of appropriate files from the CVS repository to publish area will be done. This is done by allowing the browser to send path parameter attached to to servlet name as if servlet name is the directory. Since the directory servlet name does not exist and only servlet can access the filename passed as parameter, no direct access is possible. This will make all the access via servlet keeping the system secure. 2.3 Profile customisation When a user is authorized in a particular domain (due to multiple server architecture, there is a domain associated with each server.) customized interface is generated for him. This interface is customized for this particular user according to the customization profile obtained. All the profiles, configuration information can be put in XML format. But for our development, we are keeping it with LDAPserver. This customized interface will generate the user desktop. The desktop will contain 1. Common calendar - same calendar will also be visible in each course contents page which is available after entering into a course. for students, the calendar will provide the appointment information, things to do list, planned activities for the day. The student can do personal entries. for instructor, the similar things will be provided. Additionally, he will be able to make entries for all the people registered in his course. 2. News - news area will contain the latest news update loaded by the site administrator. News and advertisement tinkers at the users screen There should be news relevant to the users which will be flashed on the users screen from time to time. This will include latest news on e-learning and things related to a particular course. If there is any important announcement from the administrator this can be flashed to the user screen. 3. Mail notifier - Will notify the arrival of new . On clicking the general mail utility will be accessed. 6

8 2.4 course area Various functionalities will be needed once a user logs into the course area Interaction tools We are planning to support chat, whiteboard,instant messaging (asynchronous) and (synchronous) for providing interactivity among instructor and student groups.offline storage of chat sessions and whiteboard discussions will be supported to help learners analyse interaction as latter stage Study tools and evaluation tools Study tools help the students and the instructors to learn new domains by self study and presentation. These include tools like student presentation. Evaluation tools help the students evaluate their performance during the process of learning. Evaluation tools include methods like quizzes, self tests etc Search Engines and Course specific calendar The users page should include search engine. The search engine has the option of searching a particular course depending on the key words provided during search. There should also be facility for searching a document in the web. The course specific calendar will not be there. Instead the links to user specific calendar tool will be provided. The user will have the facility of scheduling his work for a particular day. The user can edit or delete the entries to his calendar. 2.5 Log and users information at various points The log information about various users at various points should be stored in log files. This information should include time duration for which the user remained logged on.the amount of bytes (from course contents) downloaded by user. 7

9 Chapter 3 Issues Involved 3.1 Naming System for files As the whole system is developed for a distributed multi-server model there is need to have a unique naming scheme so that a name resolution implementation can be achieved. This can be achieved using several techniques. One way is to use the Andrew File System which provides for a distributed file system over a network. 3.2 Document Authoring tools We need a document authoring tool for authoring XML documents. This will provide the instructors with an interface to author their course material in XML form. This course material can then be archived on the server. 8

10 Chapter 4 architecture 4.1 Overall proposed system architecture The fig 4.1 shows the overall conecptualized system architecture. Initial target is to build single server system. Please go through the whole document to find what is to implemented and what not be in initial target implementation. 4.2 Model View Controller View Implementation The view functionality will be implemented using Velocity, which is a template engine. It takes in the templates written using velocity template language (*.vm). The assignment of values to various tags is done. The tag value pairs and templates are processed and html page is given out by velocity, which is passed to httpserver for onward transmission to browser. Velocity will provide a template service that will allow web applications to be developed according to a true MVC (model view controller) model (meaning that web page designers can focus solely on creating a well-designed site, and programmers can focus solely on writing top-notch code.). Before presentation on the screen, a template need to be processed (shown in Fig. 4.2) In addition, there will be different kind of templates for displays at different kind of browsers (e.g., netscape, lynx, wml browser, voicexml browsers etc.). In other words the templates will be selected according to the capabilities of the browsers. This need to be implemented by defining another template selection layer between view and controller (see Fig This capability will be built in the second version.) In first version only one set of templates will be used. The content published in some standard format will be transformed to the desired display format which can be interpreted by the browser. The possible display formats can be WML Html VoiceXML 9

11 Figure 4.1: System Architecture Figure 4.2: Velocity as view implementation 10

12 Figure 4.3: Template selection according to browser 11

13 Chapter 5 Functional Description This is proposed functional description for multiserver architecture. implementation) comm ctrlr is not implemented.) In first phase (single server 5.1 Authentication in multiserver architecture The authentication information repository contains information such as Login name which includes domain name and password. Authentication module at server A (see Fig.??) first determine if the user is local or from other domain. If the user is local, the authentication information is retrieved from local LDAP/ database/ file (We have used LDAP for this purpose.) In case, user is from other domain, authentication information about user is retrieved from remote site. In this case the authentication module at server A now sends a request for authentication using communication controller to communication controller in remote domain to which user actually belongs. This request is received by communication controller at site B. This module accesses the LDAP/ database/ file and find the authentication information. Then it sends back the information (Login ID, Domain name, password) to site A s comm ctrlr. Which in turn gives result of querry to calling servlet. In case the login is authenticated, then the flag that session is active, in local or remote database as the case may be is set. This will be used to disallow multiple sessions using same login name. 12

14 Chapter 6 Implementation Details 6.1 The Web Application Server In order to run servlets and JSP we need a servlet engine. The servlet engine has to be coupled with the web server to provide the full functional capability of a web application server. For this we have chosen Apache HTTP server and Tomcat servlet engine 6.2 Session Tracking HTTP is a state less protocol, so we need to keep track of the user session using session tracking techniques. Some of the techniques commonly used are the following. 1. Persistent cookies 2. SSL 3. URL rewriting 4. Hidden form fields. After analyzing the pros and cons of SSL and persistent cookies mechanism it was agreed that session tracking should be implemented using persistent cookies mechanism. The password information will be sent to the server using digest authentication mechanism. 6.3 Data Storage Data about the users profile and customization information can be stored in a relational database, XML file or in a directory service like LDAP. A directory service is a special type of database that is designed to be read very quickly through various indexing, caching, and disk access techniques. Directory services also presume a specialized set of search services as opposed to RDBMS system like Oracle or Microsoft SQL server which allow us a more generalized set of querying services. The Light-weight Directory Access Protocol (LDAP) (developed in the early 1990s as a standard directory protocol) defines how clients should access data on the server. It does not specify how the data should be stored on the server. However LDAP can become a front-end to any type of data store. Because of this most popular directory services including NIS, NDS, Active Directory and even Windows NT domains implement an LDAP front-end of some type. At the moment, we have decided to use mysql based user profile. For all the other configuration information, we have decided to use xml format. As a consequence, following configuration files are 13

15 Figure 6.1: Various segment of the system needed. mysqlconf.xml- It stored the URL of mysql Server alongwith the login and password to access mysql server. metadata will be maintained in metadata file format (xml) in each directory in course area. main configuration file - telling about the courses (resources) and whhere they reside on the file system. student s configuration file - contains what was the last accessed page in each course. - contains student s preferences for GUI. course configuration file - What tools are available to students and instructors. Access control files (see 2.1.2) messages.xml - contains the messages which are displayed on the screen. 6.4 System segments and interaction between them The figure 6.1 show the various segement which need to be implemented. Also how the control flow will happen between them is also shown. The segment shown in green will be implemented for the first release. 14

16 Figure 6.2: Servlets needed for Authentication module Authentication segment The figure 6.2 show the servlets to be implemented for Authentication segment. The psuedocode for the Login is as follows login.txt Copyright (C) 2002 Y.N.Singh, Ambika, Aloukik will invoke - desktop servlet Invoked from - main.view try { Verify the login-password Authenticator.verify() } catch (on failure gives LoginFailureException){ try { get user name. Authenticator.getUserName() } catch ( NoUserNameException ){ set message = Invalide username Messages.getMessg() Invoke main view } set message=username+get authentication failure messg. Messages.getMessg() invoke main view. } Check for any previous Session. if there is old session clear old session // // The lower one to used for the time being. Display to user that there was an old session which is cleared by system. // This is what is desired to be implemented. get the of the user from database. Authenticator.get (userid) send mail to user that duplicate session were tried, contact admin for password modification if needed. MailAgent.sendMail(String , String messg) // create new session, set loginid in session object set expiry time on no activity. Store the (loginid, Start time) in log redirect to desktopservlet. 15

17 Figure 6.3: obects needed by Login servlet The Fig. 6.3 shows the objects used by Login servlet. The psuedo codes for methods for classes are shown in next section. 6.5 Psuedocode for methods 16

StorageGRID Webscale NAS Bridge Management API Guide

StorageGRID Webscale NAS Bridge 2.0.3 Management API Guide January 2018 215-12414_B0 doccomments@netapp.com Table of Contents 3 Contents Understanding the NAS Bridge management API... 4 RESTful web services