National%20 online%20examination%20system%20an%20architectural%20perspective

National Online Examination System: An Architectural Perspective


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
101


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

102


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.

103


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.
Functio Functio Functio
nal nal nal
Req 1 Req 2 Req n
Logging

Transaction Mgt.

Security

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].

104


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.

Application Logic

Security Subsystem

Database
LDAP Biometric storing
Authentication Credential

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 .

105


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

106


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

107


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.

Requirements Flex Spring Jasypt Spring Security T.cotta
Scalability   - - 
OSS Stack     
Expandability -  - -
Transparent - - - - 
Scale Out
High - - - - 
Availability
High Volume - - - - 
Transaction
Security - -   -

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

108


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.

109


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

110


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

111


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.

112


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.

113


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

114

National%20 online%20examination%20system%20an%20architectural%20perspective

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a National%20 online%20examination%20system%20an%20architectural%20perspective

Semelhante a National%20 online%20examination%20system%20an%20architectural%20perspective (20)

Último

Último (20)

National%20 online%20examination%20system%20an%20architectural%20perspective