National Online Examination System an Architectural Perspective

National Online Examination System: An Architectural Perspective

101


Pradeep Kumar, Pankaj Nirwan , P Govind Raj

Abstract- CDAC Noida has developed an online examination system as per requirement of NASSCOM and DIT. The system can cater to a large number of students for administering Multiple choice questions and True False Questions of various subjects. The system is developed using Flex, Spring, and Hibernate framework and is highly secure and fail safe. The system uses open source stack in its design and is extensible, reliable and scalable to handle future requirements. The paper presents the functional description of system and architectural design of the system.

Keywords: Online examination software, Flex, Spring, BlazeDS, Terracotta, Hibernate

1. Introduction Development of a National Online Examination System (NOES) within India was a NASCOMM recommendation which, Department of IT, Ministry of Communication and Information Technology is realizing through C-DAC. The purpose of such endeavor was to design and develop a robust, fault tolerant, secure, scalable and an adaptive system through which examinations can be delivered on an “on demand” basis in selected examination centers spread across the country. The project is being carried out in two phases namely, Phase-1 wherein the software for conducting the exam would be designed and developed and Phase -II wherein various colleges and partnering institutions would be roped in to collaborate in providing question to the question. Phase 1 of the project is nearing it's complementation whereas Phase II has been initiated and is on-going. Though various learning management systems (LMS) have got features to deliver online test , they are not tuned to handling large system loads . Further most of the LMS do not support features to include Computer Adaptive Tests wherein the system estimates the ability of a candidate in a particular subject matter and fine tunes the delivery of questions to the candidate based on his/her ability. These limitations in the current LMS were among the motivations to design and develop this system. The system utilizes various open source software framework. The integration of these frameworks to work as a cohesive unit has been one of the major engineering outcome of Phase 1 of the project. This paper presents an architectural perspective of the NOES. The paper also presents various issues faced during design implementation perspective. The paper is divided into the 6 sections. Section 2 presents the functional and non functional requirements imposed on the system. Section 3 presents the System Architecture. It also provides the mapping of the non functional requirements to the architecture. Section 4 presents some key design patterns that have been included in the system. Section 5 presents key problems faced during implementation and their solutions. It also presents Java Virtual Machine (JVM) level tuning that was done to handle large number of threads. Section 6 presents a conclusion and future work planned.

Proceedings of ASCNT – 2010, CDAC, Noida, India, pp. 101 – 114


102

2. Requirements of examination system The basic functions of online examination system include registration, user management, report generation, question paper matrix entry, question pool management, data entry, examination conduction etc. The figure 1 shows the process flow of the system.

Fig. 1: Process flow diagram of online exam system

Some key non functional requirements that had a strong impact on the architecture and the components used in the architecture included: Open Source Stack Scale out vs Scale Up Ease of Extensibility Performance/High System Throughput Reliability Security/Privacy/Escrow Accounts

All these functional and non-functional requirements have been considered while deciding on technology components in the solution, described in further sections. 3. System Architecture The NOES utilizes the following open source framework across it's various tiers ,namely, Adobe Flex[1] at the Presentation Tier , Blaze DS[2] at the remoting tier, Spring[3] at the


103

business tier, Jasypt[4] at the business tier , Hibernate[5] at the Object Relational Mapping Tier and Terracotta[6] for providing JVM Level Clustering for High Availability and better throughput. Fig 2 shows various system components of online examination software.

Fig.2: System Components in Online examination Software

3.1 Presentation Tier The software interface is designed and implemented as a Rich Internet Application (RIA). RIA is a web based application that has most of the characteristics of desktop applications. They are typically delivered by standard web browser plug-ins or independently via sandboxes or virtual machines. RIA has interactivity features which are often difficult to implement using normal HTML based applications. Adobe Flex, a framework for designing and developing Rich Internet Application (RIA), was used to implement a RIA at the Presentation tier. By using Flex, a state full application running on the browser was developed for activities like student registration, payment of fees through online payment gateway, etc. The design of a web based state full application running on a browser could be considered as major paradigm shift as opposed to conventional web application, which is usually stateless. As the sessions are created on the server for each user, the more the number of session variables per user, the larger is the overhead at the server to maintain the session variables. In our design, application state is completely managed at the Presentation Tier using Flex thereby relieving the server the overhead of managing sessions. Use of Flex as a Framework also helps in creating HTTP based applications that run on the user desktop as opposed to the conventional browser using Adobe AIR framework. This was required in situations wherein a complete “control” of Desktop was required e.g. when a user is giving an examination using the software, he should not be allowed to interact with browsers and other applications. Such requirements were realized using Adobe AIR framework. 3.2 Business Tier One of the major considerations while designing the system was that to ensure that design should be agnostic to underlying Application Server. Enterprise Application Technologies like Enterprise Java Beans(EJB) , though based on Java are required to be coded in certain way so that they are portable across various applications servers of different vendors.


104

Moreover, EJB's are considered to be heavy weight as compared to a Plain Old Java Object (POJO). Our business tier design uses Spring Framework to utilize the simplicity of POJO programming and at the same time relieves the application developer from concerns about issues like Transaction, Persistence etc. These “concerns” are managed by Spring Framework itself. Apart from being a replacement to EJB, spring also provides features and programming paradigms used by the design such as: 3.2.1 Aspect Orientation Any software would have non-functional requirements like logging, security, transaction etc. that can cut across different modules and are called cross cutting concerns as opposed to core concerns (functional requirements). Earlier, with only classes and interfaces as programming elements, the traditional object-oriented approach cannot modularize crosscutting concerns well as programmers need to mix them with core concerns in the same modules. As a result, these crosscutting concerns are spread out in different modules of an application and are thus not modularized. This results in lesser maintainability and readability of the code resulting in code tangling. Another problem caused by non-modularized crosscutting concerns is code scattering wherein the same piece of code is scattered across the application. The problem with code scattering is that, if the module whose code has been scattered changes, then all instances of the code which is there in multiple modules would also require a change.

Fig.3: Aspect Orientation and separation of Cross Cutting Concern Our design uses Aspect Orientation to solve this problem in a better way [Fig 3]. By using Aspect Orientation, programmers can express cross-cutting concerns in stand-alone modules called aspects. Aspects can contains advice (i.e. code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module included as an aspect can include advice to perform a security check before accessing a particular record. Since the security module is separated as an aspect , joined using an advice and joined to specific points in code as required the problems of code tangling and code scattering is solved. We have used aspect orientation to implement Role Based Access Control[7] and Transaction management[8].

Functional Req 1

Functional Req 2

Functional Req n

Logging

Transaction Mgt.

Security


105

3.2.2 Declarative Transaction Management Enterprise applications based on Java usually write their own code to management transactions using JDBC. Writing the boiler plate transaction code is both time consuming and error prone. Further, when managing transactions programmatically, programmers need to include additional transaction management code in each transactional operation, adding to code scattering and tangling. For managing transaction in NOES, we have utilized Spring Declarative Transactions. Spring separates transaction management code from the business methods via declarations and uses Transactions as Aspect. Further, a programmer just needs to provide suitable annotations to methods to make it transactional. Various transactional attributes like propagation behavior, isolation level, rollback rules, transaction timeout etc can be specified using annotations. This relieves the programmer from worrying about issue of transaction management and helps in concentrating more on developing functional requirements. However, the team faced issues while implementing transaction management as discussed later. 3.2.3 Security Sub System architecture Security was one of the key non functional requirements of the NOES. When architecting the security sub system, a major consideration was a complete transparency of the application from the underlying security infrastructure. This means that application logic should not be tied down to a particular set of infrastructure implementing security e.g Application should be able to work with an LDAP or a Database or a Biometric identification sub system transparently [Fig 4]. Moreover, security is a crosscutting concern and has to be treated as an aspect.

Fig.4:.Separation of Security Implementation and Application Logic The security subsystem of the NOES provides Authorization, Role Based Access Control (RBAC) and cryptographic functions for storing user credentials for authentication. Spring Security was used to implement these functions. For providing cryptographic functions like encryption Java Simplified Encryption (Jasypt) was used. Jasypt had to be integrated with Spring Security and Hibernate, so that Spring Security used password encoders etc from Jasypt. Fig 5 shows hashing using Jasypt .

LDAP

Database storing Credential

Biometric Authentication

Security Subsystem

Application Logic


106

Fig.5: Hashing with Salt using Jasypt

Using the Security Subsystem, access control can be provided at the URL level, Method Invocation Level, domain object level and view rendering level. The authorization is implemented with the help of Spring Security as a set of Intercepting Filters as shown in fig6.

Fig.6: Intercepting Filters for Authentication

For making Access Control Decisions the Spring Security' Access Decision manager were used. All these access decision managers require a group of voters to be configured for voting on access control decision. NOES utilize Role Voters and Authenticated Voters. Role Voters votes for an access control decision based on a user’s role. It votes to grant access if the user has the same role as required to access the resource. It votes to deny access if the user lacks any role required to access the resource. Authenticated Voter votes for an access control decision based on a user’s authentication level. It votes to grant access if the user’s authentication level is higher than the required attribute. From highest to lowest, authentication levels are “fully authenticated,” “authentication remembered,” and anonymously authenticated.” 3.3 Object Relational Mapping Tier NOES was designed to be agnostic to Database Implementation at the back end and reduce the object relational impedance mismatch between Object Oriented Design and Relational


107

Design. The term object-relational impedance mismatch is derived from the electrical engineering term impedance matching. There are various concepts in OOP's which do not have direct relation to Relational Model. E.g. includes Inheritance, Polymorphism, and Encapsulation etc. To map these concepts from an object oriented domain to the relational domain, Object Relational Mapping paradigm has been used in NOES. Hibernate has been chosen as the implementation framework for implementing OR Mapping. Apart from providing OR Mapping, Hibernate also relieves the programmer from writing SQL's thereby improving his productivity. 3.4 Remoting Tier Since the Presentation Tier is RIA based on Flex Framework (implemented using Action Script 3) and the business tier is based on JAVA, a remoting tier was required to convert Value object from Action Script 3 to Java. Blaze DS is an Open Source remoting server, used for communication between the presentation tier and the business tier which is implemented in spring using JAVA. The communication between these two tiers is using a open source messaging Framework called AMF (Adobe Messaging Framework). AMF was preferred over XML based communication mechanism because AMF offers speed benefits better than XML based communication mechanism. 3.5 JVM Level Clustering One of the key features envisaged during the design phase was to scale out the application without requiring changes in application level code. Terracotta is used to provide Scalability and High Availability (HA) features in the design. In a conventional enterprise application scalability is usually handled at various layers e.g. At application level and Database Server End , making the design difficult to implement and manage. Our design incorporates HA right at the Java Virtual Machine Level. The advantage of this approach is that HA is available just like any other service provided by the JVM (e.g. Garbage Collection), therefore the developer just needs to concentrate on the developing business logic and worry about implementing scalability and high availability.

Fig.7: Terracotta running application instances


108

The figure 7 shows applications running on top of Terracotta. In this configuration an application does not stop running until the objects are flushed Terracotta’s memory and disk. This is how Terracotta ensures high availability as a runtime service Using Terracotta also allowed to us to scale out the application by just increasing the number of JVM's in the setup. Therefore, we could achieve, transparent scaling as source code need not be changed for the purpose of scaling. Terracotta is also used to implement various design patterns like Write behind to System of Records (SOR), Asynchronous Commit etc with intent to minimize Database I/O during an examination. The details of these design patterns are mentioned in Section IV. Terracotta also provides a transparent Hibernate 2nd Level Caching which increases the throughput of NOES and further reduces Disk I/O.This results in improving the performance by decreasing the load on the system. The deployment architecture of the system is shown in fig 8:

Fig.8: Deployment Architecture

Table 1 shows mapping of non-functional requirements of system with various technology components used in the design.

Table1: Mapping of non-functional requirements to various technical components .

Requirements Flex Spring Jasypt Spring Security T.cotta Scalability - - OSS Stack Expandability - - - Transparent Scale Out

- - - -

High Availability

- - - -

High Volume Transaction

- - - -

Security - - -


109

4. Key Design Principle and Patterns Incorporated NOES utlizes lot of major design patterns and principle presented in [9] .This section describes some of the major design patterns used in NOES. Throughout the application , we have used the principle of programming to an interface, which allows design to be completely decoupled from implementation. For example, for testing purposes , we can replace a heavy database implementation with a lighter-weight mock implementation. Use of an interface also leads to dynamic binding and polymorphism, which is consequentially important to object-oriented programming. 4.1 Model View Controller using Cairngorm Microarchitecture MVC is an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each. NOES has it’s presentation layer implemented in Flex. The presentation tier utilizes Cairngorm micro architecture to implement MVC. Cairngorm [10] is specifically designed to facilitate complex state and data synchronization between the client and the server, while keeping the programming of the View layer detached from the data implementation. The role of the View layer in a Cairngorm application is to throw events and bind to data stored in the Model. Components on the View can bind to Value Objects or other properties in the Model (data) layer. In a Cairngorm Model, related data are stored in Value Objects (VOs), while simple variables can be stored as direct properties of the ModelLocator class. A static reference to the ModelLocator singleton instance is used by the View layers to locate the required data. The Controller is the most sophisticated part of the Cairngorm architecture. The Controller layer is implemented as a singleton FrontController. The FrontController instance, which receives every View-generated event, dispatches the events to the assigned Command class based on the event's declared type. The Command class then processes the event by running the Command class' execute() method, which is an ICommand interface method. The event object may include additional data if required by the developer. The execute() method can update the central Model, as well as invoke a Service class which typically involves communication with a remote server. The IResponder interface, which is also implemented by the Command class, includes Result and Fault methods to handle responses returned from the invoked remote service 4.2 Proxy Pattern Proxy Pattern can be used to separate crosscutting concerns (like transaction, security etc) from core concerns (functional requirements). The principle of the proxy design pattern is to wrap an object with a proxy and use this proxy to substitute for the original object. Any calls that were made to the original object will go through the proxy first The proxy object is responsible for deciding when and whether to forward method calls to the original object. The proxy can also perform additional tasks around each method call. So, the proxy is a good place to implement the crosscutting concerns and can be used to implement various types of advice like beforeAdvice , afterAdvice and aroundAdvice to implement crosscutting concerns.


110

4.3 Write behind to System of Records (SOR) Usually enterprise applications persist state data in a database These data may not be required for meeting business requirements , but are persisted so that in case of an application restart , the state could be reconstructed. For example, during an examination a candidate may change his answer many times, however only the final answer may be required for evaluation purposes. These intermediate answers may be saved in the database to recover from a eventual system crash. This results in low performance as each and every change in the answer produces a disk I/O. SOR is a design pattern which suggests that , data needs to be committed to the database only at the final stage. With Terracotta, it is now possible to store data in the memory without the fear of data being lost due to system crash. Since data is stored in the memory and not on the disk, data can be updated quickly. This is helpful in situations wherein data might be changed lot of times, before finally being committed. For example in a typical examination , when an examine changes his answers , instead of generating a disk I/O , NOES updates collections in the memory and only commits the answers at the end of the examination. Since Terracotta's memory is highly available, therefore data in the memory will not be lost even in cases of full Terracotta cluster restarts. 4.4 Asynchronous Commit Committing to a database is usually a synchronous operation. In other words , the client that requests to persist a data waits till the data has been fully committed. In a typical examination situation , maximum users would be committing their result in a single point in time i.e. at the time when the exam time is over. Also in a typical Objective type paper , the number of questions are large in the order of 102 . This produces a performance bottleneck as all clients would be required to wait until data is persisted NOES utilizes Asynchronous Commits to remove the above mentioned bottleneck. It uses Terracotta to implement Asynchronous Commits. Each Node in the NOES application cluster maintains a processing bucket which holds data to be committed. All the intermediate changes to the data in the processing bucket are done in memory without producing Disk I/O. When a request to commit data is received by the Business Tier of NOES, it sends a reply at the same instance to the client about the commit “being” done and lazily commits the data to the database. This approach, reduces disk I/O and increases throughput. If a requirement of scaling comes, NOES can be configured to increase the number of processing buckets thereby further throttling the Throughput. 5. Issues faced during implementation 5.1 Integrating Flex and Spring At the first instance, it appears that since Flex can access java object and Spring beans are nothing but java objects therefore there are no issues in integration Flex and Spring. However, taking a closer look , one can infer that whole idea behind Spring is to let the container instantiate components (and inject their dependencies). By default, however, components accessed remotely by a Flex client are instantiated by BlazeDS on the server. The key to the Flex/Spring integration, therefore, is to configure BlazeDS to let the Spring container take care of instantiating Spring beans by the use of suitable factory classes provided by BlazeDS. In the first version of NOES , we designed and developed a SpringFactory and configured BlazeDS to use this factory class to let Spring to instantiate


111

the classes and perform dependency injection when needed. Later the Spring Community came up with Spring BlazeDS Integration Components[11]. The current version of NOES uses this new scheme to integrate Flex and Spring. 5.2 Integrating BlazeDS Channel Security and Spring Security BlazeDS has got methods to authenticate Channel sets between Flex Client and the Server Side Code. NOES however use Spring Security to implementing security. The issue here again was that, BlazeDS should allow Spring Security to manage security. For this purpose, we extended the functionalities of BlazeDS and designed and developed a Login Command Class which allowed, BlazeDS to use Spring Security functionalities. Later when Spring Integration Components [12] were released, we shifted our code base to use this. 5.3 Issue faced during Implementing Transaction Management using Spring NOES use MySQL as a database server (though the design is agnostic to the database at the backend). The default database engine of MySQL in Linux is MyISAM [13]. Transaction management provided by Spring does not work with MyISAM. The solution to this problem was to change the database engine from MyISAM to InnoDB[15]. Spring uses the Proxy Pattern to implement Aspect based Transaction management. Therefore, methods called using Proxy were only advised for transaction management. In our service class there were situations when a proxy method (f1) called another method (f2). Java calls method f2 using “this” pointer. In such cases the method f2 is not advised for transaction management. Therefore if , some exception happened while execution was in f2 , it had to manually handled. To get around this, we have taken a reference of the interface type implemented by the service and we have created a bean post processor which assigns the proxy to the reference. This is called self reference. Now whenever, a function is called inside a method which has advised for transaction, we use self reference instead of this pointer to work around this issue. NOES sends automated E-mails to candidates triggering a successful completion of an event such as registration successfully done, admit cards generated etc. Most of these situations involve a database operation to either Insert, Update or Delete records. Such methods are required to advise as Transactional. In such scenarios, the sending of email is typically the last scenario after the successful database operation. However, Spring buffers the database operation and performs it at the end of the Transactional Method i.e. after sending the mail. This can lead to a situation wherein the database operation was not successful, however, the e-mail was sent. To get around this issue, we flush hibernate session right after issuing a command to save, update or delete an object. Doing this throws an exception immediately on failure of a Database operation and thus prevent sending of mails in case of exceptions. Whenever a Transactional method is called from the Flex end and it fails, nothing was returned from the Business tier to the presentation tier and the transaction was not rolled back. The reason for this was that, Transactional method did not throw out an exception to the calling method and the Spring Transaction manager only rolls back an exception if the transactional method throws out an exception. To solve this issue, a service method was introduced such that it was not treated as transactional and this method was exposed to the presentation tier. The service method internally called this Transactional method. This transactional method did not handle exceptions and threw out exception to the service method. In this case, Spring Transaction Manager rolls back the Transaction and the


112

service method can be used to handle the exception and send relevant message to the presentation tier. 5.4 Integrating Flex and Terracotta Terracotta has defined several classes which it treats as non-portable. These non-portable classes cannot be used in clustered mode across different JVM’s. Flex uses some such classes pertaining to HTTPServlets in its messaging session thereby making clustering Flex Sessions using Terracotta incompatible. Since the application at the front end was a stateful one, reliance on sessions was not necessary and therefore we could configure Terracotta to ignore these non portable classes which were put by Flex in its messaging session. Further we had used a load balancer based on Apache to use sticky sessions. This allowed HTTP request to be routed to the same application server where it was first originated, this helped in non sharing of sessions across the cluster. In case of a node failure, the user just needs to re-login and he can continue from where had left as since his progress is stored across cluster using Terracotta. 5.5 Concurrency Issues with Terracotta Asynchronous Committer Terracotta AsynCommitter allows to commit records in a asynchronous manner. To do this, we need to configure processing buckets which are at each application server. Now in cases when two or more processing buckets tries to commit a data element at the same time and the primary key of such a data element is a numeric increment , then there will be will be Data Integrity Violations as two data elements may have the same number. Further, the application can enter an infinite loop since, in case of an error in committing while committing in the database, terracotta tries to recommit the values. While recommitting again the same situation of Data Integrity may arise. This situation can go on till a serial schedule is found. To overcome this issue , we have used UUID as the primary key of data items which are stored asynchronously. This prevents Data Integrity Violations in asynchronous commit mode. 6. Conclusions Using the NOES, C-DAC has conducted three PG Entrance Examination and one national level entrance examination successfully. The National Level Entrance Examination was conducted across 10 centers of C-DAC for a period of 10 days each day having 3 slots. Therefore the total number of live runs of the system are more than 300. Further The National Level Entrance examination for PG/JRF was done using a Computer Adaptive Test. The details of design and the mathematical model has been mentioned in [14].DOEACC has also expressed it’s interest in conducting it’s CCC examination. The initial stress testing result shows that we can conduct an exam for 5,000 users using just 2 Tomcat server instances. We plan to scale the application to support around 10,000 users in a single session. NOES uses Hibernate in its ORM Session. One of the criticism of ORM technologies, is that generates non-optimized SQL Queries for databases. We plan to tweak the ORM layer and use frameworks like AutoFetch to generate Optimized SQL.


113

Acknowledgment Authors would like to thank Sh. GV Ragunathan Sr. Director DIT , Sh. Anil Pipal Addl Director, DIT for their constant motivation and support throughout the project life cycle. Authors also express their sincere thanks to Sri D K Jain , Sh R K Singh , Sh V K Sharma, Dr P R Gupta and Dr George Varkey for their constant support in executing the project . Authors express their acknowledgement to their team members Kartikeya , Vikram , Kanti Singh , Neha Sharma, Soumya Sengupta , Parag for their efforts to make this software a reality. References |1| Adobe Flex www.adobe.com/mena/products/flex/ |2| BlazeDS http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/ |3| Spring Framework [www.springsource.org] |4| Jasypt [www.jasypt.org/] |5| Hibernate [https://www.hibernate.org/.] |6| Terracotta [www.terracotta.org/] |7| www.terracotta.org/confluence/display/docs/JMX+Guide |8| www.artima.com/lejava/articles/spring_clustering.html |9| Design Patterns: Elements of Reusable Object-Oriented Software (ISBN0-201-

63361-2) |10| Cairngorm [opensource.adobe.com/wiki/display/cairngorm/] |11| www.springsource.org/spring-flex |12| www.springfuse.com/.../spring-security-integration-tutorial.action |13| dev.mysql.com/doc/refman/5.0/en/full-table.html |14| Soumya Sengupta, Vikram Vijh, Kartikeya Vats “Design and Implementation of

Adaptive Assessment System using Item Response Theory Model” Proceeding, ASCNT-10, CDAC, Noida

About Authors

Mr. Pradeep Kumar did his M. Sc. In Informatics from Delhi University. He has work experience of 3.5 years. Currently he is working as Project engineer on National Online Examination Project at CDAC, Noida.

Mr. Pankaj Nirwan is a Computer Science graduate (B.E) from NIT Durgapur, having an experience of 3 years and 9 months. He has worked on various mobile platforms such as J2ME, BREW for around 2.5 years. At present he is working as a Project engineer on National Online Examination Project at CDAC, Noida.


114

Mr. P. Govind Raj is working as Senior Project Engineer at CDAC, Noida. He is coordinating the development activities of Online examination system at CDAC, Noida. His research interest includes Ubiquitous computing, e-Security and Open Source Systems. He is also involved in coordination of BOSS PRC at CDAC , Noida

National Online Examination System an Architectural Perspective

Documents

Transcript of National Online Examination System an Architectural Perspective