04-architecture.tex
9.02 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
\section{Architecture}
\label{sec:architecture}
Based on the extensive list of functional requirements defined by the
Brazilian Federal Government, we selected some FOSS systems to form our
solution. We looked for system that together could provide the largest
subset possible of the requirements, and were fully aware that we would
need to improve those systems in order to provide the rest. We were also
convinced that it would be impossible to provide all of those
requirements with a single tool.
From the point of view of the architecture, two main requirements was
brought by the Brazilian Federal Government for the new platform:
\begin{enumerate}
\item \textit{Integrate existing FOSS systems}, with minimal differences from
their original versions;
\item \textit{Provide a consistent user interface} across the different
systems, as well as centralized authentication.
\end{enumerate}
Adopting existing FOSS systems and minimizing locally-made changes had
the objective of being able to upgrade to newer versions of the original
software, benefiting from improvements and maintenance done by the
existing project communities. Providing a consistent user interface on
top of those different tools was needed to make the transition between
the different systems seamless from the point of view of users, which
would be confused by jumping through completely different interfaces
while interacting with the portal.
For the first requirement, we identified four main systems that required
specialized teams for work in the integration process. The teams learned
how to develop for their assigned systems and contributed to the
original communities, so that the version we used were not significantly
different from the original.
At the end of the project, the SPB portal was composed of more than ten
systems, such as Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix, and
Munin. The remainder of this section describes the most relevant of
them, as well as how they were integrated into the platform.
\subsection{Colab}
Colab\footnote{\url{https://github.com/colab}} is a systems integration
platform for web applications. One of its goals is allowing different
applications to be combined in such a way that an user does not notice
the change between applications. For that, Colab provides facilities
for:
\begin{itemize}
\item Centralized authentication
\item Visual consistency
\item Relaying of events between applications
\item Integrated search engine
\end{itemize}
Colab implements this integration by working as a reverse proxy for the
integration applications, that is, all external requests pass through
Colab before reaching them.
Centralized authentication is handled by letting users authenticate to
Colab, which then sends a REMOTE\_USER HTTP header to applications,
which are expected to be pre-configured to accept that as an indication
of the current user (REMOTE\_USER is a standard authentication mechanism
for web applications). This allows users to be automatically identified
to each of the applications without having to enter credentials for each
of them.
%
Of course, this requires that the integrated applications are not
accessible on the public internet, otherwise malicious users could send
their own crafted REMOTE\_USER headers and impersonate any user.
For the visual consistency, Colab is able to make transformations to the
HTML produced by the integrated applications, ir order to provide a
unified interface. It allows one to define default templates to be used
by all applications, as well as providing extra ones in a plugin. This
approach allowed us to reuse common HTML pages, what facilitates
maintenance.
Colab also provides a publish-subscribe event system. This allows one of
the applications, or Colab itself, to trigger an action in another
application. For example, when a user registers with Colab, all
applications need to be notified in order to create their own internal
representation of that user account.
Colab also provides an integrated search engine, which can be configured
to specify exactly what data needs to be indexed for each of the
applications, and how to direct the user to that piece of information on
the specific application.
Initially, Colab had support for a small set of applications (Trac, GNU
Mailman, and Apache Lucene) and support for them was hard-coded. Our
team evolved Colab so that it can now receive plugins that add support
new applications without the need of changes to the Colab core. We also
developed plugins to be used in the SPB platform: Noosfero, GitLab, and
Mezuro.
\subsection{Noosfero}
Noosfero\footnote{\url{http://noosfero.org}} is a software for building
social and collaboration networks. Besides the classical social
networking features, it also provides publication features such as blogs
and a general-purpose CMS (Content Management System). Most of the user
interactions with SPB is through Noosfero: user registration, project
home pages and documentation, and contact forms.
\subsection{Gitlab}
GitLab\footnote{\url{http://gitlab.com}} is a web-based Git repository
manager with wiki pages and issue tracking features. Gitlab is a FOSS
platform and focuses on delivering a holistic solution that will see
developers from idea to production seamlessly and on a single platform.
Gitlab has several unique features, such as built-in continuous
integration and continuous deployment, flexible permissions, tracking of
Work-in-Progress work, moving issues between projects, group-level
milestones, creating new branches from issues, issues board, and time
tracking.
\subsection{Mezuro}
Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
metrics to monitor the internal quality of software written in C, C++,
Java, Python, Ruby, and PHP.
In general, source code metrics tools also do not present a friendly way
to interpret its results and, even more, do not follow a standardization
between them. Mezuro collects and presents these results to the end
user, specially, by analyzing source code metric history during its life
cycle.
The Mezuro platform provides a single interface grouping available
tools, allows selection and composition of metrics in a flexible manner,
stores the metrics evolution history, presents results in a friendly
way, as well as, allows users to customize the given interpretation
accordingly to their own context.
\subsection{System unification}
\begin{figure}[hbt]
\centering
\includegraphics[width=\linewidth]{figures/arch.png}
\caption{SPB architecture overview.}
\label{fig:architecture}
\end{figure}
The conceptual architecture of the platform is presented in Figure
\ref{fig:architecture}. Colab initially handles all user interaction,
directing requests to one of the integrated applications. It
post-processes responses from the applications to apply a consistent
visual appearance, manages authentication, and provides a unified search
functionality: instead of using the redundant restricted search
functionality of each application, a search in the SPB portal might
return content from any of the applications, be it web pages, mailing
list posts, or source code.
% Falar do devops
\subsection{Deploy}
The SPB platform was deployed in 7 virtual machines with different functions,
as we can see in Figure \ref{fig:architecture2}.
\begin{figure*}[hbt]
\centering
\includegraphics[width=.8\linewidth]{figures/arch3.png}
\caption{Instanciation view of the SPB architecture.}
\label{fig:architecture2}
\end{figure*}
The \textit{reverseproxy} handles the HTTP requests and redirects them to the
\textit{integration}, the \textit{email} sends and receives e-mails on behalf
of the platform and the \textit{monitor} keeps the entire environment tracked.
These three \textit{VMs} mentioned - \textit{reverseproxy}, \textit{email} and
\textit{monitor} - are accessible via Internet and the other ones are only
available in the local network created between them.
\textit{Integration} works as a second layer of proxy beneath
\textit{reverseproxy}, any request to the platform will be handled by it. The
Colab service provides interface, authentication and search engine integration
among all the services. When a request is received to a specific service,
Colab authenticates the user in the target tool, sends the request and makes a
visual transformation in the HTML page which is the content of the response.
Another user-oriented feature is the integrated search engine, when the user
want to find something in the platform Colab will perform the search in the
whole databases. Colab itself provides a web interface for GNU Mailman and we
have two others integrated tools in \textit{integration}: Gitlab and Prezento.
Gitlab provides web interface for Git repositories and issues tracker, and
Prezento is a front-end for source code static analysis.
The source code static analysis is performed by \textit{mezuro}. It runs some
static analysis tools on source code stored in repository and provide this data
to Prezento. A social network and CMS (Content Manager System) is provided by
Noosfero in \textit{social}, and the databases of all tools with a cache
service are in \textit{database}.