The Fenixedu Project:: An Open-Source Academic Information Platform
The Fenixedu Project:: An Open-Source Academic Information Platform
The Fenixedu Project:: An Open-Source Academic Information Platform
The FenixEdu
Project: an
Open-Source
Academic
Information
Platform
Copyright Instituto Superior Tcnico, March 2011
The FenixEdu Project:
an Open-Source Academic
Information Platform
Project Founder, Chief Architect
and Project Director (20022008)
Antnio Rito da Silva
Project Directors (20082011)
Fernando Mira da Silva, Carlos Ribeiro
Chief Architect
Joo Cachopo
Chief Developers
Joo Luz, Joo Mota, Lus Cruz
Software Developers
ngela Almeida, Anil Kassamali,
Artur Ventura, Cludio Gil, David Santos,
Diogo Simes, Fernanda Quitrio,
Gonalo Luiz, Hugo Querido, Ivo Brando,
Joo Antunes, Joo Figueiredo,
Joo Mota, Lus Cruz, Lus Egdio,
Manuel Pinto, Nadir Tarmahomed,
Nuno Ochoa, Paulo Abrantes,
Pedro Santos, Ricardo Rodrigues,
Ruben Carvalho, Shezad Anavarali,
Susana Fernandes, Tnia Pouso
Identity Management Subsystem
and e-ID Interoperability
Carlos Ribeiro, Daniel Almeida,
Fernando Mira da Silva, Jorge Matias,
Miguel Cabea
System Administrators
Bruno Fernandes, Cludio Martins,
Daniel Almeida, Filipe Almeida,
Jorge Matias, Jos Pereira,
Miguel Cabea, Paulo Andrade
User Support Team Lead
Jos Lus, Tnia Nunes
User Support
Alexandra Alves, Armando Almeida,
Carla Amado, Helder Leite, Jos Lus,
Rosa Barbosa
4
Web Designers
Bruno Monteiro, Carla Penedo,
Gustavo Pimenta, Joo Alfaiate
Grants
Artur Ventura, Bruno Santos,
Carlos Jacinto, Carlos Pereira,
Daniel Ribeiro, Diogo Figueiredo,
Francisco Paulo, Jaime Jorge,
Joo Marques, Joo Neves, Joo Pereira,
Lus Cruz, Lus Egdio, Nuno Diegues,
Pedro Amaral, Raquel Guimares,
Srgio Silva
External Cooperation
Gonalo Luiz, Joo Luz
Students
Amin Amirali, Ana Gouveia,
Andr Fernandes, Anil Kassamali,
Bruno Almeida, Carlos Pereira,
Catarina Simes, Ctia Martins,
Danilo Camargo, David Santos,
Fernanda Quitrio, Francisco Passos,
Francisco Paulo, Joana Mota, Joo Brito,
Joo Fialho, Joo Figueiredo, Joo Neves,
Joo S, Joo Simas, Joo Sitefane,
Leonor Almeida, Lus Cruz, Lus Egdio,
Manuel Pinto, Nadir Tarmahomed,
Nuno Anto, Nuno Barbosa, Nuno Correia,
Nuno Nunes, Nuno Ochoa,
Patrick Da Fonte, Paulo Abrantes,
Pedro Santos, Ricardo Lopes,
Ricardo Nortadas, Ricardo Oliveira,
Ricardo Rodrigues, Rita Carvalho,
Rita Ferreira, Rui Figueiredo, Sara Oliveira,
Sara Ribeiro, Srgio Montelobo,
Srgio Nunes, Srgio Patrcio,
Shezad Anavarali, Sofa Rodrigues,
Tnia Pouso, Telmo Frias,
Tiago Rodrigues, Ximena Gento
SOTIS Project Supervisor
Jos Lus Borbinha
SOTIS Developers
Miguel Coxo, Pedro Carloto, Pedro Santos
Contributions
Past and present
project staff
Text
Antnio Rito Silva, Artur Ventura, Carlos
Ribeiro, Fernando Mira da Silva, Joo
Cachopo, Lus Cruz, Susana Fernandes
Editor
Fernando Mira da Silva
Editorial Design
Tiago Machado
Infographics
Telma Baptista
The Fenix project started at Instituto
Superior Tcnico (IST), Lisbon, Portugal,
with the aim to develop an integrated
academic information system for higher
education. Today, that system is the
basis of all academic processes at IST,
from high-level scientifc and academic
management to daily communication
between students, teaching and
administrative staff. It provides a powerful
Content Management System (CMS),
Student Management System (SMS) and
Learning Management System (LMS),
control and archive of all academic
records, overall academic management
from degree design and approval to
room scheduling and many other related
academic tasks.
The Fenix project was developed using
an Object Oriented approach based
on a Rich Domain Model that attempts
to model all academic entities and
processes. The infrastructural level is
based on an innovative approach to
Software Transactional Memory (STM), in
order to enable large-scale concurrency
with minimal interlocking transactions.
5 The FenixEdu Project: an Open-Source Academic Information Platform
The platform is integrated with an
advanced identity management
subsystem, which provides single sign-on,
federation support, strong authentication
based on a national e-ID Card and
supports European e-ID interoperability.
The project was developed from scratch
adopting a Lesser General Public Licence
(LGPL). It is used today by several higher
education institutions, with maintenance
and support often being provided
by independent private companies.
This approach contributed to extend
technological support and increase the
long-term project sustainability.
Abstract
A
6
Contents Introduction
Project Overview
IST overview
Organization
The Fenix Strategy
IS Development Models
Integration of Business Goals
Fenix Features and Functionalities
Role based approach
Multi-language support
Course support
Academic management support
Administrative support
Scientifc support
Building and infrastructure management
Admissions and on-line application support
Website management
Other functionalities
Roles and associated functions
An Innovative Technological Approach
The original software architecture of Fenix
A software architecture for applications with a rich domain model
The Fenix Framework
The Bennu Framework
A visual representation of the Fenix domain model
Identity Management
Identifers
Global Perspective
LDAP
Kerberos
Single Sign-on
Portuguese National e-ID Card
European e-ID support
SAML 2.0 Federation Support
Project metrics
Code size and evolution
Development team size
Performance
Third party implementations
Conclusion
Discussion
Ongoing and future developments
References
8
8
10
13
14
14
15
18
18
21
22
23
24
25
26
26
27
27
28
36
37
38
39
40
42
44
44
45
46
46
47
47
49
49
50
50
52
52
52
54
54
55
56
1
1.1
1.2
1.3
2
2.1
2.2
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
4
4.1
4.2
4.3
4.4
4.5
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
6
6.1
6.2
6.3
6.4
7
7.1
7.2
8
The Fenix project
1
started in 2002 at IST,
Lisbon Portugal, with the aim to develop an
advanced academic information system for
Higher Education Institutions (HEI).
The system was designed from the start
to be fully web based, in order to provide
wide availability and easy user interaction,
independent of client software and
operating systems, while assuring the high
security standards, tight access control
and log action control required by a critical
information system.
Project Overview 1.1
The Fenix system is an integrated platform
that works at all levels of the academic
process. It implements a powerful Content
Management System (CMS), which can
be used at course, degree, department
or institution level, an advanced Student
Management System (SMS), a complete
Learning Management System (LMS) and
it also integrates all components required
by a standard academic management
platform.
This includes management and support
of all academic tasks, including on-line
student applications and admission
processes, on-line enrolment and
registration, evaluation and grade records,
degree planning, design and aproval, full
management of academic records (at
graduation and post-graduation level),
publication registration and archive of
grades and student curricula, room,
course and teacher scheduling and
distribution, fee and payment control,
quality control through on-line surveys
and many other tasks. At the course
level, the system provides an information
board and an easy to use CMS, planning
and scheduling tools, publication of class
summaries, publication of bibliographic
references, documents and exercises,
e-learning support and evaluation,
student management and communication
channels, RSS feeds, registration of the
number of attendents and many other
functionalities.
As stated before, the system also provides
full support to all academic back offce
and management, including the workfow
required by most processes. This
includes design, planning, and approval
of degrees and courses (including
contents, bibliography, structure and
planning), European Credit Transfer and
Accumulation System (ECTS) validation,
formal approval by the scientifc board
of courses, degrees and teaching staff,
issue of diplomas and certifcates, etc.
The platform also handles the publication
of thesis theme proposals, support for
applying for a thesis theme and supervisor
Introduction 1
Project Overview
IST overview
Organization
1
1 FenixEdu is the registered trademark of the Fenix project. For sake of simplicity, we will however keep
the simplifed designation Fenix Project through out the remainder of this document.
9 The FenixEdu Project: an Open-Source Academic Information Platform
and academic tasks related with thesis
management and supervision. Moreover,
it integrates a complete curriculum
management platform for teaching and
research staff, enabling the assessment
of scientifc production at individual,
departmental and institutional level.
The current version of the system
encompasses a wide range of
functionalities related to almost every
component of the academic process.
The complexity of the business model
and of the underlying information system
poses signifcant challenges from a
software engineering perspective. As
such, the system is often used both
as a source of research problems
and as a testbed for validating new
research approaches that address
the development of highly complex
applications with rich domain models.
One result of this tight integration
between research and development was
the introduction of an innovative software
architecture for developing applications
with persistent and transactional rich
domain models. This new architecture
combines a Domain Specifc Language
(DSL) for implementing the structure
of the domain model with a Software
Transactional Memory (STM) to control
concurrent access to the applications
data. Both the DSL and the STM used in
this new architecture were designed and
developed from scratch to suit the needs
of the Fenix project. However, since they
are independent from the application layer,
they were already adopted by several
other applications in different contexts. In
this sense, the Fenix project turned out
to be one of those rare cases of software
systems that change the technological
environment surrounding them.
The Fenix academic platform is
integrated with an advanced identity
management subsystem, which provides
user authentication to all computer
and network services. The identity
management backend is powered by
Kerberos and Lightweight Directory
Access Protocol (LDAP), and provides
web single sign-on based on Yale Central
Authentication Service (CAS).
The identity management subsystem
also has full Security Assertion Markup
Language (SAML) 2.0 federation support
based on OpenSAML, which provides full
interoperability with standard SAML based
federations (namely Shibboleth based
federations).
This identity management subsystem also
supports strong authentication based
on the Portuguese National e-ID Card
(named Carto de Cidado or Citizen
Card) and, moreover, is fully integrated
with the European e-ID interoperability
subsystem, developed in the scope of the
European project STORK. Digital signature
of documents and actions is also possible
using the Portuguese National Identity
Card.
The overall system was developed
from scratch as an open source project
based on the LGPL, to offer a basis for
open contributions, free distribution,
free availability, and customization to
special requirements and needs at
different institutions. This distribution
model enabled several HEI to implement
the Fenix system with the support of
independent private companies and, at
the same time, to enlarge the technical
support of the platform, which does not
rely today only on internal IST resources,
given the wider implementation basis
and technical support. This strategy
also contributed to the long-term project
sustainability.
The Fenix logo is the iconic Portuguese
Galo de Barcelos (Barcelos rooster), an
old Portuguese symbol, representing
that truth always prevails. The Galo de
Barcelos legend describes how the
rooster interceded for a man to be hanged
for a crime he had not committed. The
Galo de Barcelos was chosen because
Fenix is a Portuguese project driven by the
belief that by doing good we will prevail.
The Fenix project code and
documentation is available at
https://fenix-ashes.ist.utl.pt/.
10
IST overview 1.2
As stated before, the Fenix project was
developed from scratch at IST. While
today the Fenix system is also deployed
at other institutions, IST remains both the
largest user base and the primary source
code contributor. As would be expected,
ISTs implementation is the only one that
makes full use of all platform features, as
most of them stem directly from internal
requirements.
IST is the largest school of engineering in
Portugal. It was founded in 1911 in the
city of Lisbon, with the aim of developing
top quality education and research in
the areas of engineering, science and
technology.
The mission of IST is to create and
disseminate knowledge and provide our
students the education and the knowledge
tools to improve, to change, and to shape
society through science, technology,
and entrepreneurship. We achieve
this by combining a top quality higher
education with Research, Development
and Innovation activities, according to the
highest international standards, immersing
our students, alumni, faculty and staff in
an exciting and global environment geared
towards solving the challenges of the XXIst
Century.
IST is a research-oriented school, home to
more than 6,000 undergraduate students
(BSc), 4,000 graduate students (MSc and
PhD) and around 1,100 faculty members
and researchers. IST is settled in two
campuses, one in central Lisbon and
another in Taguspark (a modern science
and technology complex, home to more
than 130 high-tech based companies,
located in the southwest coast of Lisbon).
Students can choose from a rich variety
of MSc and PhD programs offered at IST,
covering the classical engineering and
basic science felds as well as a number of
the emerging scientifc areas. A signifcant
number of international students
participate in ISTs Master and Doctoral
programs.
IST cooperates worldwide with some of
the best universities and Research and
Development (R&D) institutions, and is a
member of various European networks
of prestigious schools in Engineering,
Science and Technology, such as
CLUSTER, TIME, and CESAER, all
committed to provide technical education
at the highest international standards.
Currently, IST offers several master and
doctoral programs in collaboration with
international partners (including Erasmus
Mundus).
Being research a central activity at
IST, it spans several R&D units and
disciplines. Teaching and research are
closely connected. Research and external
consulting contribute to more than half of
the IST fnantial turnover.
Master and Doctoral students are regularly
involved in these research activities,
working together with IST faculty and
research staff, to face the challenges
posed by ambitious national and
international research projects. Figures 2A
and 2B summarizes main IST facts and
fgures.
Figure 1
Alameda Campus
Figure 2A
(next page)
IST facts and fgures
(July 2010)
FACTS & FIGURES A SNAPSHOT OF IST
Education
Graduate students per cycle
30%
10%
60%
10%
International
Students
14%
International
Students
10231
Students
PhD
1058
Students
28
PhD Programmes
110
PhD Thesis
Master
3319
Students
25
Master Programme
823
Master Dissertations
1rst
Cycle
1121
2nd
Cycle
824
3rd
Cycle
110
Employability
96%
Get a job within
6 months of
graduating
63%
Get a job
before
graduation
Bachelor
5854
Students
19
Courses
Research
Internationalization
M.Sc
Double
Degrees
2
5
Joint PhD
programs
MIT
CMU
UT Austin
EPFL
International
networks
CLUSTER
EIT-LIC InnoEnergy
TIME
CEASER
MAGALHES
ATHENS
Mobility
programmes
E
R
A
S
M
U
S
S
M
IL
E
B
R
A
S
IL
Traineeships
IAESTE
VULCAN
US
ERASMUS MUNDUS
(Msc, Phd) programmes
euSYSBIO
EMDC
IDS-FunMat
EU-Brazil StartUP
38
7
29
1186
1852
4538
PhD awards
Research centres and institutes
New patents applications
Associated laboratories
59%
Own resources
Funding
135M
Total funding
13
Organization 1.3
This document is structured as follows.
Chapter 2 presents the overall project
strategy and discusses the adopted
model and the in-house development
approach.
Chapter 3 describes the Fenix platform,
listing the overall system features and
model at a functional level.
Chapter 4 delves into the systems
software architecture, and provides a brief
overview of the innovative approach that
enabled us to simplify the development of
applications with a rich domain model.
Chapter 5 describes The identity
management subsystem, including
federation support, strong authentication
support and European e-ID compatibility.
Chapter 6 presents several project facts
and fgures.
Finally, chapter 7 concludes, discussing
the current state of the project, overall
features and on-going and foreseen
developments.
Figure 3
Taguspark Campus
Figure 2B
(previous page)
IST facts and fgures
(July 2010)
14
The design of the Fenix business strategy
took into account our previous experience
with the development of information
systems (IS) in the context of HEI.
IS Development Models 2.1
In terms of funding, we realised that HEI
funding is constantly changing and it is
heavily based on political decisions. In
terms of management, HEI management
boards change periodically.
In terms of technology, HEI information
systems are long living platforms which
very often become technologically
obsolete. In terms of human resources,
HEI have problems competing for the
best-qualifed human resources in the
market of software. Moreover, there is
usually a communication gap between
the HEI and external entities that it tries to
work with.
The approaches already taken for the
development of HEI IS do not provide a
complete solution to these problems:
Commercial off-the-shelf products are
usually not fexible enough to support the
differences each HEI has in regards to
its core processes. So they are usually
limited to standard resource management
(salaries, accounting, etc), which usually
depend on the accounting laws of the
country, and so thus less variation from
institution to institution. When they are
used in other contexts (for example a
LMS), usually the HEI has to change or
adapt its processes to conform to the
software.
Analysing the outsource approach reveals
two major problems. The frst is cost.
A dedicated application that covers all
needs of an institute with the size and
complexity of a medium sized HEI can
cost well above 2 Million Euros. But
the main problem with this approach is
that the rules and processes at the HEI
change very often, and are a priori very
diffcult to put on paper. In this case the
communication gap is evident and the
derived costs from constantly changing
the systems with new functionalities
increases the overall cost.
In-house Development is usually done by
technical HEI staff, in close connection
with management and academic offcers.
This technical staff usually has no research
or teaching functions besides some
introductory courses. When an inhouse
IS project starts, normally it begins as a
small project and it progressively grows
The Fenix Strategy 2
IS Development Models
Integration of Business Goals
2
15 The FenixEdu Project: an Open-Source Academic Information Platform
Figure 9
Typical course page.
Figure 10
Creating an
on-line quiz.
23 The FenixEdu Project: an Open-Source Academic Information Platform
Academic management support 3.4
Designing the course structure for each
degree is a complex process requiring the
participation of different members. While
such a structure is designed from scratch
only once in time, it is successively
redesigned every year for reasons that
include changes in scientifc knowledge,
technological development or regulatory
changes. All areas of degree design are
evaluated and monitored by the Fenix
application, providing an automatic check
that most regulatory conditions are verifed
(namely ECTS number, course pre-
conditions, distribution by scientifc groups
and areas, etc).
Once approved by the scientifc board,
the plan and structure of each degree is
automatically mapped into the academic
administrative back-offce. During
student enrolment, which happens at the
beginning of each term, each student
chooses on-line the courses that he/her
wants to attend. During this process, the
students choice is automatically validated
against his/hers degree curricular plan and
historical academic record.
Another driving force for changes in
the curricular structure of a course is
academic quality control provided by
feedback from students and faculty.
At the end of the term, students,
teachers, student representatives and
degree supervisors fll out on-line surveys
regarding several areas of the learning
process. The result of these surveys
is subject to a deep statistical analysis
and is correlated with other academic
information, such as student workload,
assessment results and attendance
levels. This analysis provides the schools
management and department executive
boards with relevant information that is
taken into account when reviewing or
adjusting academic courses, degrees,
class schedules and it is the main tool for
quality control of academic performance.
Figure 11
Degree plan interface
(partial view).
IST
Life Cycle
Class
period
Exam
period
Enrolment
period
Figure 13
Typical HEI life-cycle.
Schedule preparation and classroom
allocation is a crucial activity that is
developed well before each enrolment
period begins.
Collection
and processing
Contents
Metadata
Harvesting
External Sources
Validation
IST
Repository
26
Admissions and on-line
application support 3.8
To capture a greater number of students
and to boost student mobility, on-line
applications are another relevant feature
provided by the Fenix application. The
platform currently supports on-line
applications for most courses. In each
case, any potential student may apply
from anywhere in the world, by flling
out forms and uploading any required
documentation.
Building and infrastructure
management 3.7
Another feature provided by the Fenix
application is the space management
module. This module allows registration
of every space managed by the school,
including campuses, buildings and rooms.
Several attributes can be associated
with each space, such as area, capacity,
available multimedia equipment and
furniture and associated quality attributes.
Blueprints can be uploaded for each
campus and for each building level (see
Figure 15). Searching for spaces can be
achieved either by navigating through the
blueprints, or by submitting a search form.
When spaces are classrooms or meeting
rooms, scheduling and reservation is
provided by the system. Any user can
check room availability at anytime.
Figure 15
Example of the space
management interface.
One of the challenges in on-line
applications is how to validate a users
identity. Since the Fenix application is fully
integrated with national authentication
services, Portuguese citizens can identify
themselves providing strong authentication
using their National e-ID Card. Recent
developments include the extension of
this strong authentication method to an
international level, through the European
e-ID interoperability platform developed
in the scope of the pan-European project
STORK. This topic is discussed in more
detail in Chapter 5.
27 The FenixEdu Project: an Open-Source Academic Information Platform
Website management 3.9
Since the Fenix application integrates a
powerful CMS system, the application
includes the required tools to easily create
websites that are fully integrated with
the core faculty database and provides a
high level of customization. This includes
support for creating menus, sections,
sub-sections, announcement pages,
and so forth. These websites are usually
Other functionalities 3.10
As a system that encodes all
organizational structure and user
information, Fenix includes several
auxiliary modules and add-ons that assist
administrative support and workfow
management for several processes
that are not provided by the existing
ERP platforms. This includes several
auxiliary tasks, as student residence
management, parking management, on-
line access to fnancial data of scientifc
and development projects, management
of institutional websites, research staff
evaluation, several supervision and
authorization activities related with the
management, scientifc and pedagogical
boards.
Another add-on module to the Fenix
system is the Bennu framework and
associated applications, also developed
at IST, briefy described in section 4.4.
While not strictly part of the academic
platform, it integrates the organizational
and user information of the Fenix platform,
and is currently the basis for several IST
workfow processes. This include the
management of several administrative
tasks, namely acquisition processes,
travel authorizations, administrative
staff evaluation, internal staff transfers,
document management, etc.
Figure 16
Typical CMS
management interface
associated to a generic faculty unit,
which can range from a full academic
department to a small research group.
Since users can be easily associated to
any of these units, such websites may
provide an automatic user directory
with contacts and personal information,
associated scientifc production and
related information, at unit level.
28
Main functions available:
student admission, enrolment and
management;
degree transfer;
management of tuition, insurance and
fees;
issue of documents and certifcates;
registration and validation of grades and
mark sheets;
production of academic reports on a year
and degree basis;
processing and validation of applications;
Confguration of access permission to
each offce personel by the academic
offce supervisor.
Main functions available:
confguration and monitoring options of
the overall application.
Main functions available:
curriculum access;
self update of employment, professional
and academic information for
dissemination purposes;
request of documents and certifcates;
search for alumni;
access to institutional news, events and
publications;
subscription of institutionale-mailing lists;
access to a personel homepage;
access to an e-mail account.
Main functions avilable:
monitoring of the application status;
personal information update;
upload of requested or optional
documentation.
Roles and associated functions 3.11
A non-exhaustive list of roles and
associated functions is depicted int the
following list.
Academic Administrative Offce
School staff who are in charge of student
registration, enrolment and academic
administrative processes.
Administrator
Technical staff that are in charge of the
Fenix application.
Alumni
Former students.
Candidate
Any potential student who applies to a
program or degree offered by the school.
On the left we have the role being
described and who it is attributted to.
On the right we have the functions
associated with each role.
29 The FenixEdu Project: an Open-Source Academic Information Platform
Main functions available:
access to news;
access to forums;
e-mail delivery;
fle sharing;
search for system users;
access to school directory and
organizational structure;
Main functions available:
assignment of additional team members;
assignment of scientifc commission
members;
management of the degree website;
access to the degree plan and curriculum;
access to degree students curriculum;
management of degree applications;
access to quality control reports;
mail distribution to degree students and
teachers;
management of thesis themes, distribution
and control (if the degree includes a
thesis);
management of PhD processes (if the
degree pertains to a doctoral program).
Creation and management of a course
requires the following information:
name, level (1st cycle, 2nd cycle, etc) and
type;
scientifc area;
term and associated time span (dates, etc);
student workload;
ECTS credits;
objectives, program and evaluation
method;
bibliographic references.
The creation and management of a
full degree curriculum is based on the
defniton of curricular groups. Each
curricular group includes a set of
mandatory or optional courses.
For each course, the following information
must also be provided:
prerequisites for the course;
curricular year and term;
rules that students must verify to enroll in
the course.
Communication
Any user of the system.
Coordinator
Teaching and administrative staff who
are in charge of the supervision and
management of a degree.
Curriculum Manager
Staff members that manage and confgure
the curricular plan of each academic
degree.
30
Main functions available:
e-mail communication to students;
assessment of student schedules;
access to quality control reports.
Main functions available
access to curricular course data;
manage teaching staff allocation and
workload;
access to class abstracts;
generation of reports related with degrees
and courses;
confguration of privileges regarding
degree coordination and scheduling;
management of department thesis;
management of the department website;
sending e-mails to department members,
coordinators, students and delegates;
sharing of fles and documents with
department members.
Main functions available:
view the scientifc curriculum of
department members (teaching and
research staff);
access statistics of department courses;
manage teaching staff service and
schedule distribution;
coordination, evaluation and scheduling of
department courses and degrees;
view and manage the department forums;
send e-mail to department members;
share fles and documents with
department members.
Main functions available:
access to own time cards (self);
access to time cards of supervised staff;
Main functions available:
access to reports regarding payment of
tuition and fees;
student statistics for each academic year
and degree;
tools for supervision of class abstracts
and evaluation methods;
assignment of external supervisors;
management of applications to career
workshops.
Delegate
Students nominated by their peers and
have a liaison role between students and
the instituion. Delegates are distributed by
degree and academic year.
Department Administrative Offce
Administrative staff at academic
department level.
Department Member
Teaching staff who are in charge of the
academic department executive board.
Employee
This role is attributed to the instituion staff
who are neither teachers nor researchers.
Executive Board
The executive board is the institutions top
management unit. It is usually composed
by teaching staff and administrative
executive offcers.
32
Main functions available:
Access to project fnantial data.
Main functions available:
managing news and information in the
instituional site;
e-mail distribution to students, alumni,
teachers and researchers;
management of simple user surveys
related with public events;
access to a restricted set of student and
alumni information.
Main function:
acess to documents pending rectorate
processing.
Main functions available:
registration of sicentifc and other
activities that make part of the offcial
user professional curriculum (including
publications, conferences, patents and
prizes;
e-mail distribution to reserachers of the
same research unit.
Main functions available:
management and control of residence
registration and fees.
Main functions available:
management of academic periods;
management of class schedules;
management of tests and exam dates;
room allocation for classes, evaluations
and other events.
Project Manager
Teaching and research staff who are
in charge of a scientifc or institutional
projects.
Public Relations Offce
Public relations staff.
Rectorate Administrative Support
Administrative staff of the rectorate.
Researcher
Teachers and researchers.
Residence Manager
Staff who manage student residences.
Resource Manager
This role is attributed to administrative staff
who support institutional schedules and
resources, including degree and course
schedules and room allocation.
34
Main functions available:
view his/her curriculum and status;
view his/her class schedule and
evaluation calendar;
view his/her tutor (should one have been
appointed);
view his/her delegate;
access administrative services, including
document and certifcate requests;
access course forums;
flling out inquires regarding academic
quality control;
vote for student representatives
(delegates);
subscribe to ad-hoc events and
workshops;
perform on-line tests;
access course excercises and projects;
manage his/her thesis (if it applies);
course enrollment;
select his/her class schedule;
exame enrollent.
Main functions available:
manage his/her course;
manage his/her course webpage;
Student supervision;
access student grades;
request room reservation for non regular
classes;
manage thesis processes;
Student
All students.
Teacher
All teaching staff.
36
The development of Fenix started in 2002
with a well-defned software architecture
that was based on the best practices
for web application development at that
time (Fowler, 2002; Singh, Stearns, &
Johnson, 2002; Alur, Malks, & Crupi,
2001). That software architecture was
the basis of the project infrastructure
during its frst years of rapid growth,
but proved to be inadequate as the
complexity of the application increased.
Thus, as the problems of the original
software architecture started to surface,
the Fenix team began the development
of a new software architecture that went
into production for the frst time in the
late summer of 2005. Since then, the
architecture was further developed and
evolved into a set of additional frameworks
that are independent of the Fenix web
application and that are, in fact, being
used in the development of several other
applications, proving the success of this
new approach.
This section presents a high-level
description of the newly developed
software architecture for Fenix,
emphasizing some of its innovative
aspects, which are still pioneering in the
area of web application development.
This presentation starts with a brief
overview of the original software
architecture of Fenix, which is still one
of the most common architectures for
web applications, and identify some of its
problems. Then, the key ideas underlying
the new software architecture of Fenix
are introduced. In sections 4.3 and 4.4,
we briefy describe two of the major
frameworks that emerged from the Fenix
project.
An Innovative
Technological Approach 4
The original software architecture of Fenix
A software architecture for applications
with a rich domain model
The Fenix Framework
The Bennu Framework
A visual representation of the Fenix
domain model
4
37 The FenixEdu Project: an Open-Source Academic Information Platform
The original software
architecture of Fenix 4.1
Originally, Fenix was developed using the
typical 3-tiered software architecture for
web applications, where the three tiers
are a web browser, an application server,
and a relational database server. In this
architecture, a user interacts with the web
browser, which makes HTTP requests to
the application server (as a result of the
user actions) and renders the HTML page
that is returned by the application server.
The application server, on the other hand,
receives HTTP requests from the web
browser and is responsible for processing
those requests, typically by requesting
data from the database server, processing
that data according to the applications
business logic, and eventually writing
some data back into the database (if the
request involved changing some of the
applications data). In Fenix, the database
tier is supported by the MySQL relational
database management system, and the
application server is implemented using
the Java platform.
The architecture of web applications
evolved into this standard structure, where
the application server is separate from the
database server (effectively moving from a
2-tier architecture to a 3-tier architecture),
because it allows programmers to use
different technologies for two crucial
aspects of a web application: (1) the
implementation of the applications
business logic, and (2) the persistent
storage of the applications data.
Whereas managing persistent data that
may be accessed concurrently has
been the realm of relational database
management systems (RDBMS) for
decades, these systems often lack the
expressiveness of modern object-oriented
programming languages to implement the
complexities of an applications business
logic. Thus, the separation of these two
tiers seeks to combine the best of both
worlds: the database tier continues to do
what it does best to manage persistent
data , and the application tier is free to
implement all of the business logic using
whatever programming language fts best
its needs. This is of special relevance
when we are dealing with applications with
a rich domain model.
We say that an application has a rich
domain model when its domain is
composed of many different entity
types, often with subtle variations and
intricate relationships among them.
Moreover, besides having a complex
structure, such domains typically exhibit
complex behaviours that involve many
different entity types at the same time.
Given the scope and range of the Fenix
functionalities already summarized in
chapter 3, it should be clear by now that
Fenix fts well within this category: the
Fenix domain model currently consists of
more than 1200 different entity types with
more than 1700 bidirectional relationships
among them.
Developing such a complex domain model
poses serious development challenges,
and requires highly disciplined use of
the best software engineering practices
and design principles. This is where the
object-oriented design and programming
may make a difference, if properly used,
suggesting that the 3-tier architecture
described above is a good solution, so
that the applications domain may be
implemented in the application server
using a language such as Java.
Yet, implementing the applications domain
logic using an object-oriented model is
at odds with the relational nature of the
data stored in the database tier, because
it is not easy to map one model into the
other. To tackle this diffcult problem, it is
common practice to rely on an Object/
Relational Mapping (ORM) framework
that implements most of the heavy-lifting
needed to bridge the gap between the
two worlds. So did Fenix, which used the
Apache ObJectRelationalBridge
(OJB)
2
as an ORM, hidden behind a
layer implementing the Data Access
Object (DAO) design pattern (Alur,
Malks, & Crupi, 2001). With todays
technologies, the equivalent solution is
to use an implementation of the Java
Persistence API (JPA) specifcation to play
the role of ORM.
Still, regardless of which ORM
implementation is used, a key aspect
of this architecture, and one where the
new architecture of Fenix departs from
standard practice as we shall see, is that
all of the ACID (atomicity, consistency,
isolation, and durability) properties of the
applications transactions are ensured
by the database tier, rather than by the
application server. And in here lies one of
the problems of this architecture for an
application such as Fenix - an application
with a rich domain model.
To ensure that the database tier detects
conficting accesses to the applications
data, all of the data accessed by a
business operation must be directed to
the database by the application server.
The problem, however, is that being the
database a separate component from
the application server, such accesses
are expensive, because they incur into
remote calls and data marshalling.
When the data needed to process a
users request may be fetched from the
database in few requests, that is not
a big problem, because the latency of
the connection between the users web
browser and the application server is
typically much larger than the latency of
the connection between the application
server and the database server, thereby
hiding the cost of the round-trips to the
database. Unfortunately, for applications
with a rich domain model, such as Fenix,
it is not uncommon to have business
operations that involve fetching hundreds
to thousands, or even millions, of different
pieces of data from the database in a
sequential fashion.
2 See http://db.apache.org/ojb/.
38
A software architecture for applications
with a rich domain model 4.2
In late 2003 Fenix was starting to face
some of the problems described in
the previous section. Having a domain
model with close to 200 different entity
types and implementing more than 1000
different services of varying complexity,
some of the services were taking too long
because of the excessive round-trips to
the database. The need to solve those
performance problems led developers
to add more responsibilities to the data
access layer, by creating Data Access
Objects that implemented complex
SQL-like queries to the database tier.
This, however, resulted in poor use of the
object-oriented programming paradigm,
with little opportunity for reuse and with
the proliferation of duplicate code.
Moreover, the transactional semantics
provided by the persistence mechanisms
(including the database tier) were
not strong enough, resulting often in
the violation of the applications data
consistency. In fact, most RDBMS do not
provide strict serializability semantics to
their transactions, falling back to weaker
consistency guarantees such as snapshot
isolation or repeatable read isolation levels.
The new software architecture for Fenix
was designed to address both the
performance problems and the software
development problems that resulted
from its original, and still common today,
software architecture. The goals for
the new architecture were to facilitate
the development of a persistent, fully-
transactional, object-oriented rich domain
model, while at the same time improving
the applications performance.
The key, and pioneering, element of
the new architecture is the use of a
Software Transactional Memory (STM)
in the application server tier to ensure
the atomicity, consistency, and isolation
properties of transactions, without relying
on the database tier. Thus, in this new
architecture the database tier is used
to ensure only the durability property of
transactions.
STMs have been the subject of intense
research since 2003 (even though
they were proposed earlier), as an
alternative to lock-based mechanisms to
synchronize access to shared memory
in parallel programming. Using an STM,
programmers developing a concurrent
program for a shared-memory system
do not need to obtain locks to access a
shared object. Instead, they just have to
identify which operations are supposed
to run atomically, and the STM runtime
system ensures that the operations run
with the intended semantics, eventually by
aborting and restarting conficting atomic
operations that run concurrently.
Unlike relational databases, STMs typically
provide strict serializability semantics for
their transactions, but have no support
for durability. Moreover, STMs are usually
embedded in a programming language,
providing atomic actions at the language
level over the languages objects.
For the new architecture of Fenix,
we developed an STM for the Java
programming language the Java
Versioned Software Transactional Memory
(JVSTM) library
3
. This STM was the
frst multi-version STM, and was the frst
STM to be used in a real-world production
environment.
The design of JVSTM and of the new
architecture for Fenix was based on the
assumption that many web applications,
including Fenix, have a very high read/
write ratio, meaning that they do many
more operations that only read data than
operations that read and write data.
In such cases, the combined latency of
all the round-trips to the database may
add up to a long response time to a users
request, from many seconds to several
minutes.
In such cases, programmers have
to resort to one or more of several
approaches to get acceptable
performance for their applications, from
caching data on the application server
to carefully crafting complex queries
that fetch more data with each round-
trip to the database. These solutions,
however, either interfere with the semantic
properties of transactions, in the former
case, or make the development much
more complex, error-prone, and brittle,
in the latter case. Often, this leads to a
programming approach that precludes
the use of a natural object-oriented
programming model, thereby defeating
one of the purposes of the architecture in
the frst place.
3 Available at
http://web.ist.utl.pt/~joao.cachopo/jvstm/.
39 The FenixEdu Project: an Open-Source Academic Information Platform
Since the development of the new
architecture, this has been confrmed
for Fenix, where only 2% to 4% of its
transactions write (Carvalho, Cachopo,
Rodrigues, & Rito-Silva, 2008).
Thus, using the JVSTM to ensure the
proper transactional properties of the
operations removes the need to access
the data from the database in the vast
majority of cases, provided that the data
is already in memory. Given the generous
amount of memory that is possible to
fnd in modern hardware, this assumption
proves to be easily satisfed for an
application with moderate memory needs,
such as Fenix, which has a database of
approximately 20 Gb. Note, however, that
this architecture does not need to have
all of the applications data in memory, as
in the more recent approaches based on
in-memory databases. It just performs
better if the data that it needs is already in
memory.
Whereas the use of an STM was a
key enabling technology in the new
architecture of Fenix, there are several
other aspects of the new architecture
that contribute to its success, such as
the use of a domain specifc language
to implement the structural aspects of a
rich domain model, or the mechanisms
supporting the development of modules of
a system. In the next sections, we briefy
introduce the Fenix Framework and the
Bennu Framework that embody some of
these new aspects.
Both of these frameworks were originally,
and more recently, extracted from the
Fenix code base to make them reusable
for other applications. Both have already
been used in several other projects, both
at IST and by other software development
teams implementing products for their
own companies.
The Fenix Framework 4.3
One of the major design goals
underlying the development of the
Fenix Framework
4
is that it should
provide a natural programming model for
programmers used to develop plain Java
programs without persistence.
Typically, a domain model is programmed
in Java by using Java classes to
implement the domain models entity
types. Relationships between entity types,
however, do not map that easily into Java
constructs. Instead, they are typically
implemented in each of the participating
entities classes, either as references to
other objects, or as collections of objects,
or both.
Moreover, classes corresponding to
a domain models entities have other
requirements that are not common to
classes implementing other types of
objects in the application. For instance,
their objects need to be persistent and are
typically shared among many concurrent
threads. So, these classes need to be
implemented specially, taking these
requirements in consideration.
Given the special nature and needs of the
domain model, in the Fenix Framework
the domain model is defned using a new
language that was specifcally created
to allow the defnition of the structural
aspects of a domain model. This language
is the Domain Modeling Language (DML),
which is a micro-language designed
specifcally to implement the structure
of a domain model; it has constructs
for specifying both entity types and
associations between entity types. A
domain model defned in the DML is then
compiled into the corresponding Java
classes that correctly implement that
domain model structure in such a way
that allows the programmer to further
defne the entities behaviours in plain Java
(Cachopo e Rito-Silva, 2006b).
The current version of the Fenix
Framework stores the applications
entities in a MySQL database, but does
so automatically and transparently to
the programmer, relying on the JVSTM
to ensure the correct strict serializability
semantics. Therefore, the database is
completely hidden from the programmer.
This has two outcomes: (1) the
programmer cannot control the mapping
of objects to the database, and (2) there
is no way to take advantage of database
facilities such as joins or aggregate
functions. In return, programmers may
use all of the normal object-oriented
programming coding patterns, and are
encouraged to do so.
The Fenix Framework is also an excellent
example of the Fenix strategy described
in chapter 2. First, because it is a result
of research work that was done in the
context of the Fenix project. Second,
because it is used in the ISTs degree
on Information Systems and Computer
Engineering as a tool that students use to
develop new applications. Third, because
it serves as a basis for further research
done by MSc and PhD students, as
well as by senior researchers on several
research projects.
4 The Fenix Framework is available at
https://fenix-ashes.ist.utl.pt/trac/fenix-framework.
40
The Bennu Framework 4.4
The FenixEdu application is ISTs
solution to model its academic business
processes. The success of this
implementation made the applications
source code to grow on average 138000
lines of code per year, since 2003. The
application has been developed as a
single module, having only a few borders
delimiting how objects interact in the
application. Albeit the applications domain
model is well defned, and domain entities
encapsulate well their responsibilities,
there are no barriers between domain
objects. Consequently, developers are
unencumbered when programming
domain object interactions. While this
strategy allows for rapid development,
it greatly increases the applications
overall complexity and is more prone to
programming errors.
With a well-established presence in faculty
academic processes, in mid 2008 the
Fenix development team began to focus
more attention on the support provided
to other administrative processes. This
requirement to develop functionalities in
new business processes, coupled with
the teams desire to contain complexity led
to the creation of the Bennu Framework,
which is worth referencing in this scope
since it can be seen as a byproduct and
outcome of the Fenix project.
Figure 17
(next page)
Bennu architecture
model and example of
modules.
When developers model a business
problem using modules, they are
establishing well defned boundaries
for how objects may interact with that
module. Besides reducing complexity, this
strategy also promotes reuse. With the
compartmentalization modules introduce,
code is much easier to manage and
refactor.
Using the Bennu Framework, a web-
application is simply a set of modules
joined together. Developers can limit their
view to the modules they are working
on. Multiple applications can be created
deploying different sets of modules. At IST
we currently have fve distinct Bennu-
based applications deployed, all of which
share some modules.
Out of the box, the Bennu framework is
a fully functioning web-application and it
provides modules with:
the concept of a user;
the concept of a group;
security features and access control flters;
a task scheduler and automation of task
execution;
transparent and consistent persistence
of data.
Not all modules have to provide business
logic. They can simply be used to provide
other modules with more abstractions,
to hide infrastructure not provided by the
Bennu framework. Such modules already
developed include:
e-mail communication support;
fle repository support module;
web-service communication module;
organizational structure module;
personal and contact information module;
geographic information module;
IST is currently working on the transfer
and decomposition of the Fenix
application into modules. However with
over 1200 domain classes and more than
1250000 lines of code, this is not an easy
task. Finding the appropriate boundaries
will take some time. But this effort will
be worth it as it will reduce maintenance
costs in the long run.
Simply put, the Bennu Framework
is an empty web-application, void of
business logic, containing all the technical
abstractions extracted from Fenix on
which business processes are developed.
Note that having this infrastructure
separate from the application also allows it
to be reused in other applications.
Another signifcant improvement
introduced by the Bennu Framework is
the concept of a module. Functionalities
are added to the Bennu Framework
with modules. A module is a coherent
set of domain entities, domain logic and
interfaces for manipulating that domain.
Mission Module
UI Component
Domain Module
Expenditure
Tracking Module
UI Component
Domain Module
Document
Manag. Module
UI Component
Domain Module
Web- Service
Module
REST Servlet
UI Component
Domain Module
Geographic
Module
Domain Module
Personal & Contact
Inform. Module
UI Component
Domain Module
Email Module
Domain Module
SMTP Adapter
Organizational
Module
UI Component
Domain Module
File Module
UI Component
Domain Model
File System Adapter
Bennu Framework
User
Interface
Data
Persistence
Security &
Acess Control
Task
Scheduler
42
A visual representation
of the Fenix domain model 4.5
The Fenix domain is a large complex
domain that includes several thousand
object classes. In order to develop a visual
representation of Fenix entities and their
relations, we used a design tool to data
mine gigantic graphs (see fgure 18).
In this representation, each dot (graph
node) is a class and each line (graph edge)
is a relation. Colors encode the relation
type. Pink lines represent inheritance, in
which one entity is the specialization of
another, while the remaining are a relation
between two entities (e.g. Person has
a Card, Student has a grade). The fnal
representation results from an optimization
algorithm which attempts to distribute nodes
and edges in such a way that graph nodes
fll the overall graphic area and graph edges
are minimized. Note that optimization usually
stops at a local minimum and, therefore, the
fnal representation is not unique.
This graph visually encodes some
interesting components of the faculty
structure. The colours are separation
of important parts of the system. For
example:
cyan: Person;
red: Teacher;
ligher green: Student;
orange: Accounting;
blue: Personnel Section;
darker green: PhD;
yellow: organizational structure.
The most important entity is Person. This
entity represents the concept of a person
with which the college has a relation
with, either being a student, teacher or
employee. This is at the heart of the graph
because it is the most connected entity
(see zoomed area in fgure 18).
Figure 18(next page)
The Fenix domain
model. The zoomed
area corresponds to the
area around the person
object class.
Windows
Desktops
Web Applications
Email
CIFS
RT
Proxy
WiFi
VoIP
VPN
AFS,
Cluster
Radius
Active
Directory
Kerberos
CAS
SAML 2.0
Federation
National
ID card/
European
eID
LDAP
45 The FenixEdu Project: an Open-Source Academic Information Platform
Global Perspective 5.2
Whenever a user wants to access an
electronic service he must provide his
IST identifer, and authenticate using one
of the authentication protocols available
at that service. Although most services
support some Single Sign On (SSO)
system, the supported systems differ from
service to service. The solution was to
develop a forest of SSO systems with trust
relationships among them, so to the end
user it looks like a Single Source Sign On
(SSSO) system.
Each trust relationship (fgure 19) maps
users credentials from one e-ID system to
another. However, not every e-ID system
has a trust relationship with every other
e-ID system. The LDAP and Kerberos
e-ID systems are at the core of most trust
relationships. Every other system either
has a direct trust relationship with one of
them or an indirect one (transitive trust).
Figure 19
Global perspective
of the identity
management system
46
LDAP 5.3
The OpenLDAP service (OpenLdap
Foundation, 2011) implements the
Lightweight Directory Access Protocol
(LDAP) (Zeilenga, 2006) and it is the
primary storage of user personal
information. Each user has a LDAP record
containing a set of attributes according to
9 different attribute schemas:
Core Schema
Cosine Schema
Nis Schema
InetPerson Schema
utlPerson Schema
istPerson Schema
Samba Schema
EduPerson Schema
Kerberos Schema
Each schema defnes a number of
attributes. Not all attributes are flled for
every user, but several attributes are
flled for most users. One of the core
attributes is the uid attribute. Each user
may have multiple uid attributes, in other
words, a user may be known by several
different identifers. However, one of them
must be the IST identifer (for example
ist10010). Other uids may represent
legacy identifers or identifers for special
applications. Besides uids, every other
personal information like full name, photo,
e-mail address, phone number, password
and home directory in the Distributed
Files System, etc. is stored and accessed
through LDAP.
Upon registration every user gets an
entry in the LDAP storage with all the
mandatory attributes. There are several
methods to register a new user. All but
two (see sections 5.6 and 5.7) require the
execution of a privileged operation by a
system administrator on the Fenix system,
which flls in the user attributes, generates
a temporary password and creates a
LDAP user register. Some of the attributes
may only be changed by the system
administrator, others may be updated by
the user himself through a web interface
provided by the Fenix system.
In order to prevent that one single
system, generating too many LDAP
queries, hinders the performance of every
other system dependent on LDAP, the
LDAP service is replicated by 6 different
mirrors, each one handling on average
50 queries per second. This way, if one of
the services is overloaded with requests
almost only the service generating the
excess of queries gets affected.
The LDAP protocol is used both to
query for attributes and to perform user
authentication. Some applications use
LDAP directly for authentication through
a SASL module (Simple Authentication
and Security Layer), but most use it
as backend storage for other identity
systems, e.g. Kerberos and RADIUS,
thus creating a sort of trust relationship
between them.
Kerberos 5.4
Kerberos (Neuman, 2002) is one of
the most well known Single Sign On
distributed authentication protocols. At
IST, Kerberos is used directly by many
different applications, like the AFS and the
computer cluster, and indirectly through
the Active Directory (AD) identity system,
the CAS and LDAP.
Kerberos uses the LDAP service
as storage for user authentication
information, and LDAP uses Kerberos
for authentication, thus creating a trust
relationship between them.