CAMPUS Architecture

Francesc Santanach1 – fsantanach@uoc.edu

Joan García Vila2 – joan.garcia@tecsidel.es
Marc Gener3 – marcgener@uoc.edu, marc.gener@cast-info.es

1 Introduction

The CAMPUS project (http://www.campusproject.org), promoted by the Government

of Catalonia’s STSI4, is the initiative of several Catalan universities, which came
together to create a virtual open source campus. This campus aims to enable higher
education in a completely online format, and combining online and offline.

Among other features, CAMPUS will support up to 10,000 users connected at the
same time. Its user interface will be designed following user-centred design
methodologies, and taking into account issues such as usability, accessibility and
content personalization. The project will therefore be an international reference in
the field of e-learning. CAMPUS was born within the Catalan university system, and it
will be open to the world. The Open University of Catalonia5 is responsible for the
coordination and technological leadership of the project, which will be developed
taking advantage of the knowledge and experience that each partner brings to it.

At present time, the project counts with more than 15 partners among who are
divided the tasks of the CAMPUS development as well as those of observation and
monitoring.

• Development partners: Universitat Autònoma de Barcelona, Universitat

Politècnica de Catalunya, Universitat de Lleida, Universitat de Girona,
Universitat Oberta de Catalunya, Universitat Ramon Llull, Universitat
Internacional de Catalunya.

• Monitoring and observation partners: Universitat Pompeu Fabra,

Universitat Rovira i Virgili, Universitat de Barcelona, Universitat Abat Oliba
CEU, Institut Joan Lluís Vives, I2CAT, Departament d'Ensenyament de la
Generalitat de Catalunya, Centre de Supercomputació de Catalunya, Escola
d'Administració Pública de Catalunya.

This project is part of the Digital University program promoted by STSI. The goal of
the program is to facilitate the transmission and sharing of knowledge through
information and communication technologies.

1
Learning Technologies – Universitat Oberta de Catalunya (UOC). http://www.uoc.edu
2
Tecsidel. http://www.tecsidel.es
3
Learning Technologies – UOC and CastInfo. http://www.cast-info.es
4
Telecommunications and Information Society Secretariat. Generalitat de Catalunya.
http://www.gencat.net/societatdelainformacio
5
UOC - Universitat Oberta de Catalunya. http://www.uoc.edu

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 1 of 14
CAMPUS is a technological solution for virtual learning that includes the
functionalities described by the Learning Management System (LMS) specifications.
These functions are centred on the virtual classroom and can be divided into four
groups:
• Planning the learning process

Tools that allow the organization of the student’s work, both individually and
within the classroom.
• Communication

Resources, areas and tools that allow students to communicate at different

levels (teamwork, communities, tutoring, etc.). The system will include people
directories, messages boards, email, forums, chats and blogs, among others.
• Resources management

Teachers will have access to tools and resources for the management of
different types of learning materials, which can be published in different
courses. Professors will have their own teaching area, independent of the
courses they are teaching.
• Evaluation

Tools to facilitate monitoring and evaluation of the students’ learning process.

Technologically, the architecture will be based on a central system, or basic

technological infrastructure, and on a set of modules or services that can be
developed separately and independently of the central system. Communication
between the central system and the modules will be done through calls based on OKI
OSID specifications (http://www.okiproject.org).

The central system will manage all the transversal aspects of the process, for
example, security and session control. The individual modules will be responsible for
managing their own functions and module specific information. The central system
could use either Moodle6 or Sakai7 platforms as a base, as the project guarantees
compatibility with both platforms, using OKI OSIDs.

It is a Service Oriented Architecture (SOA) with an open technological base that will
allow interoperability between heterogenic modules. Communication with the central
system will be principally based on web services, and each module will be able to
choose its own internal architecture and base technology. The architecture proposed
will be made up of four main layers:

1. Basic Platform: The platform that provides the core LMS services. It can be
either Moodle or Sakai.

2. OKI Adapter: This will allow the connection between the modules and the basic
platform, using OKI OSID specifications. Libraries will be provided using both Java
and PHP.

3. OSIDs: The set of service programming interfaces that will be available, as

proposed by the OKI specifications.

6
http://www.moodle.org
7
http://www.sakaiproject.org
Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org
February 2007 Page 2 of 14
4. Services or Modules: The modules or services themselves, which add value to
the project. The interaction between the basic platform and these services is via OKI
OSIDs only.

2 Aims

The CAMPUS project aims to develop a technological infrastructure with free

distribution tools for online teaching. The project must meet the following
requirements:

z Be based on open source and open standards.

z Interoperability
z Scalability
z High concurrence
z OKI OSIDs
z Using a Moodle or Sakai basic infrastructure.
z Service oriented architecture.

3 Problems posed by Sakai and Moodle

There are many existing services, developed both in Sakai and in Moodle. The
problem is that currently neither infrastructure incorporates OSID specifications,
although there are initiatives within both projects working to make this possible.

In order to meet our requirements, the best alternative at this point seems to
develop the necessary OSID interface, and to produce components to make it
compatible with Sakai and Moodle. We will call this layer the ‘Gateway’.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 3 of 14
4 CAMPUS Architecture Proposal

Explanation of the above figure:

z Java/PHP Application: An application will be developed using Java or PHP.

z OSID Interface: The client part has an OSID interface, through which they
make service calls.

z OSID Implementation: The implementation of the OSID interface in the

client part. The infrastructure generated by the web service in the client part
is used to call services that are really implemented in the server part.

z Proxy Web Service: A device generated by the web service, to communicate

with the implemented service.

z Web Service: The service is implemented in the server part.

z OSID Interface: The server part also has an OSID interface, through which
the calls for services will be made.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 4 of 14
 z OSID Implementation: The OSID interface is really implemented in the
server part.

z Sakai/Moodle Gateway: Makes calls to Sakai or Moodle platforms APIs. In

this way, it is possible to produce applications in PHP or Java, programmed
using OSID interfaces, and use either Sakai or Moodle platforms, even though
these do not currently support the interfaces.

It is worth noting that, thanks to remote infrastructure (in our case, web services), it
is possible to use heterogenic architectures. That is to say, it is possible to use a
Java application that uses the Moodle platform, or an application with PHP that uses
the Sakai platform.

4.1 Appliances to develop

● OKI-OSIDs implemented with Java (OKI bus for Java applications).

● OKI-OSIDs implemented with PHP (OKI bus for PHP applications).
● Sakai Gateway implemented with Java.
● Moodle Gateway implemented with PHP.

UML Diagram for Sakai:

UML Diagram for Moodle:

Reminder Note: OKI OSIDs (implemented with either Java or PHP) will be available
as Web Services.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 5 of 14
5 Vision of the physical architecture

The following figure shows where the different software layers mentioned above will
be situated. The architecture in the figure uses two machines for the application
servers, but it would be possible to put it all on the same machine.

Example using a Java application and Sakai, but which could also be PHP application
or/and Moodle platform:

1. The client (Java application) calls a particular service.

2. The service is implemented in the client part, but this is really just a series of
calls to the devices that have been generated to carry out the web service.
This implementation uses the OKI-OSID interface.

3. The service call is made, using the web service proxy, in the server machine,
which is where the service is really carried out.

4. The implementation of the service itself also uses the OKI-OSID interface
specifications.

5. The gateway calls the necessary Sakai APIs, to carry out the operation.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 6 of 14
6 The Gateway concept

We understand Gateway to mean an appliance that will act as a bridge between the
operations requested by the application through OKI OSIDs, and the operations that
will finally provide the service through the Sakai or Moodle API.

To give a practical example, let us imagine that an application requests an

authentication, using the OKI OSID interface and using Sakai platform. If what is
really required is to confirm whether it is a Sakai user, it will be necessary to use the
Sakai API. Something to act as a bridge between OKI OSIDs and Sakai is therefore
needed, and that is what the Gateway does. The following figure demonstrates this
more clearly:

1. The application makes the call to an OKI-OSID method for authenticating a

user.
2. The implementation of the OKI OSID method masks that which will be a call
made by the Gateway to the Sakai API.
3. The Gateway makes the call to the Sakai method, to authenticate the user.
4. Sakai takes responsibility for validating the user.
Note: It is worth noting that this is not a real example. In our case, the user signs
up on moodle or sakai and the applications only have to validate if the user is
authenticated or not.
Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org
February 2007 Page 7 of 14
7 Usage Scenarios

The following section details a set of approximate usage scenarios that may help to
clarify the architecture.

7.1 Scenario 1: To have or want to use an application

developed with Sakai

In this case, nothing special needs to be done, there is a Sakai tool with the
functionalities we need, so it is necessary only to install and configure the Sakai
environment.

For this scenario, it is necessary to install:

● The Sakai platform.

7.2 Scenario 2: To have or want to use an application

developed with Moodle

In this case, nothing special needs to be done, these is a Moodle tool with the
functionalities we need, so it is necessary only to install and configure the Moodle
environment.

For this scenario, it is necessary to install:

● The Moodle platform.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 8 of 14
7.3 Scenario 3: To have or develop an application with Java
using OKI OSIDs, and to want to use it on the Sakai platform

In this case, there is a Java application or a plan to develop a Java application, using
the OKI OSIDs implemented by the CAMPUS project. In order to use it on the Sakai
platform, the application may need to use the Sakai API to carry out operations
specific to that platform, and therefore the application will also require the Sakai
Gateway.

All calls are done through OKI OSIDs, implemented with Java and available as a Web
Service, and the Sakai Gateway, which perform the necessary translation so that
Sakai can understand it. This process is illustrated in the figure below:

For this kind of scenario, it is necessary to install:

● The OKI OSIDs implemented with Java.

● The Sakai Gateway.
● The Sakai platform.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 9 of 14
7.4 Scenario 4: To have or develop an application with Java
using OKI OSIDs, and to want to use it on the Moodle platform.

In this case, there is a Java application, or a plan to develop a Java application, using
the OKI OSIDs implemented by the CAMPUS project. In order to use it on the Moodle
platform, the application may need to use the Moodle API to carry out operations
specific to that platform, and therefore the application will also require the Moodle
Gateway.

All calls are done through OKI OSIDs, implemented with PHP and available as a Web
Service, and the Moodle Gateway, which perform the necessary translation so that
Moodle can understand it. This process is illustrated in the figure below:

For this kind of scenario, it is necessary to install:

● The OKI-OSIDs implemented with PHP.

● The Moodle Gateway.
● The Moodle platform.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 10 of 14
7.5 Scenario 5: To have or develop an application with PHP
using OKI OSIDs, and to want to use it on the Sakai platform.

In this case, there is a PHP application, or a plan to develop a PHP application, using
the OKI OSIDs implemented by the CAMPUS project. In order to use it on the Sakai
platform, the application may need to use the Sakai API to carry out operations
specific to that platform, and therefore the application will also require the Sakai
Gateway.

All calls are done through OKI-OSIDs, implemented with Java and available as a Web
Service, and the Sakai Gateway, which perform the necessary translation so that
Sakai can understand it. This process is illustrated in the figure below:

For this kind of scenario, it is necessary to install:

● The OKI-OSIDs implemented with Java.

● The Sakai Gateway.
● The Sakai platform.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 11 of 14
7.6 Scenario 6: To have or develop an application with PHP
using OKI OSIDs, and to want to use it on the Moodle platform.

In this case, there is a PHP application, or a plan to develop a PHP application, using
the OKI OSIDs implemented by the CAMPUS project. In order to use it on the Moodle
platform, the application may need to use the Moodle API to carry out operations
specific to that platform, and therefore the application will also require the Moodle
Gateway.

All calls are done through OKI-OSIDs, implemented with PHP and available as a Web
Service, and the Moodle Gateway, which perform the necessary translation so that
Sakai can understand it. This process is illustrated in the figure below:

For this kind of scenario, it is necessary to install:

● The OKI-OSIDs implemented with PHP.

● The Moodle Gateway.
● The Moodle platform.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 12 of 14
8 Evolution and Optimization Criteria

This project is an initiative of different universities with their own specific

characteristics: a certain number of students, staff members, teachers and
professors, pedagogical methods of their own, e-learning use at different levels, and
capacity to develop and innovate. For this reason, scalability and flexibility are both
the most important goals of the project.

The architecture permits different degrees of scalability. It is possible to deploy not

only all the components and applications in the same machine, but also each
application and the core services in individual machines. The final decision will be
made in terms of system performance and the strategic point of view.

Another aspect to be considered is the integration between the virtual campus and
other enterprise applications. For example, under some enterprise architecture
policies, it could be necessary to change the virtual campus authentication method in
order to use an enterprise authentication and security service like Shibboleth. A SOA
and OKI OSID based approach reduces the complexity to do it. The following
diagram explains how to do it.

Independent Virtual Campus in enterprise architecture

Virtual Campus

e Applications
Applications
Applications
Enterprise Applications
Applications
Applications Applications
Applications s Applications
s Auth. OSID
Auth. OSID OSID
OSID OSIDs
OSIDs Enterprise Auth.
(Shibboleth)
Auth. Virtual Auth. OSID
Campus

Auth. Virtual
Campus

This diagram illustrates how to do the integration for the authentication and
authorization OSIDs, which can also be applied to the OSIDs as a whole.

The use of web services is a fine approach in terms of interoperability but may be a
problem in terms of performance. Anyway, the use of interfaces like OKI OSIDs
enables to increase the performance using caches or changing the communication
protocol whenever possible. The following diagram illustrates it.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 13 of 14
 Consumer Layer
Applications

OSIDs

Cache1 ... CacheN

Communication Layer

Protocol 1 ... Protocol N

Provider layer

Cache Example: an application needs recurrent access to the same user

information. If the call for the information is executed through an interface, then the
interface implementation can be changed in order to add a cache component. This
approach will be transparent for the application and increase the system
performance.

A similar approach is also true to increase the system security and other optimization
strategies. It is always possible and transparent for the applications to change the
OSID implementations.

Protocol example: there exist one consumer and one provider, both implemented
with java. In this case, a communication protocol like RMI could be better than
webservice. If the calls between the consumer and the provider are executed
through an interface, then the interface implementation can be changed in order to
replace the webservice calls with RMI calls. This approach will be transparent for
both, the consumer and the provider.

The last aspect in this document to be discussed is the application optimization. In

fact, the Campus project is about an integration project. Each application is
responsible for both its architecture and performance. Additionally, the project is
focused on how the applications interact with the basic platform and between each
other using OKI OSIDs. In the future, however, there will be more aspects to be
addressed - how to add new OSIDs and services, how to move functionalities from
the applications to the external services, among others-. For this kind of issues, the
SOA and OKI OSID based approach will be appropriate.

Copyright © 2007 Universitat Oberta de Catalunya Campus Project. http://campusproject.org

February 2007 Page 14 of 14