architecture: improve Colab description

Lucas Kanashiro
1 parent 38934816
Showing 1 changed file with 37 additions and 5 deletions Show diff stats
opensym2017/content/05-architecture.tex
@@ -39,11 +39,43 @@ described how we integrated those tools and conclude with the deployment.
 \subsection{Colab}
-For the second requirement, we decided to use a web integration platform named
-Colab\footnote{\url{https://github.com/colab/colab}}. It works as a frontend
-for other web applications as a reverse proxy, manages authentication, and can
-apply changes to the HTML provided by the integrated applications in order to
-bring visual consistency.
+Colab\footnote{\url{https://github.com/colab/colab}} has integration of web
+applications as its main goal, the user of this integrated system should not
+notice the change between the integrated applications. To do that Colab was
+designed to use plugins of each application and has four levels of integration:
+
+\begin{itemize}
+  \item Authentication
+  \item Visual
+  \item Events
+  \item Data and search engine
+\end{itemize}
+
+Colab works as a reverse proxy, therefore all external requests pass through
+it, this is an advantage to manage these four levels of integration.
+
+Single Sign-On (SSO) is used to login users throughout all integrated
+applications. REMOTE\_USER HTTP header is sent to the applications and we
+expect that they know how to handle it, since this is a common authentication
+mechanism. The integrated applications should be in a local network to avoid
+security issues. With this the user will be able to navigate through the
+platform applications and will not be asked for authentication credentials.
+
+As Colab is a reverse proxy, it makes some HTML transformations in the HTTP
+response of integrated applications to provide a unified interface. Allows one
+to define some default templates to be used by all applications and overwrite
+when needed in its plugin. This approach allowed us to reuse some HTML pages
+which facilitates maintenance.
+
+A publish-subscribe implementation was used to handle events in the platform.
+Thus, if some application want to trigger some action in case that other
+application do something is possible. A registration of the desired events and
+implementation of the handlers must be done in the plugin of each application.
+This bring us many options to innovate in these integrations.
+
+A integrated search engine is provided by Colab. Each plugin specify which data
+will be indexed and will became available for the users, just need an simple
+implementation of how should perform the collection of data.
 Initially, Colab had support for a small set of applications (Trac, GNU
 Mailman, Apache Lucene) and all of them was hard-coded; our team evolved Colab
	@@ -39,11 +39,43 @@ described how we integrated those tools and conclude with the deployment.		@@ -39,11 +39,43 @@ described how we integrated those tools and conclude with the deployment.
39		39
40	\subsection{Colab}	40	\subsection{Colab}
41		41
42	-For the second requirement, we decided to use a web integration platform named
43	-Colab\footnote{\url{https://github.com/colab/colab}}. It works as a frontend
44	-for other web applications as a reverse proxy, manages authentication, and can
45	-apply changes to the HTML provided by the integrated applications in order to
46	-bring visual consistency.	42	+Colab\footnote{\url{https://github.com/colab/colab}} has integration of web
		43	+applications as its main goal, the user of this integrated system should not
		44	+notice the change between the integrated applications. To do that Colab was
		45	+designed to use plugins of each application and has four levels of integration:
		46	+
		47	+\begin{itemize}
		48	+ \item Authentication
		49	+ \item Visual
		50	+ \item Events
		51	+ \item Data and search engine
		52	+\end{itemize}
		53	+
		54	+Colab works as a reverse proxy, therefore all external requests pass through
		55	+it, this is an advantage to manage these four levels of integration.
		56	+
		57	+Single Sign-On (SSO) is used to login users throughout all integrated
		58	+applications. REMOTE\_USER HTTP header is sent to the applications and we
		59	+expect that they know how to handle it, since this is a common authentication
		60	+mechanism. The integrated applications should be in a local network to avoid
		61	+security issues. With this the user will be able to navigate through the
		62	+platform applications and will not be asked for authentication credentials.
		63	+
		64	+As Colab is a reverse proxy, it makes some HTML transformations in the HTTP
		65	+response of integrated applications to provide a unified interface. Allows one
		66	+to define some default templates to be used by all applications and overwrite
		67	+when needed in its plugin. This approach allowed us to reuse some HTML pages
		68	+which facilitates maintenance.
		69	+
		70	+A publish-subscribe implementation was used to handle events in the platform.
		71	+Thus, if some application want to trigger some action in case that other
		72	+application do something is possible. A registration of the desired events and
		73	+implementation of the handlers must be done in the plugin of each application.
		74	+This bring us many options to innovate in these integrations.
		75	+
		76	+A integrated search engine is provided by Colab. Each plugin specify which data
		77	+will be indexed and will became available for the users, just need an simple
		78	+implementation of how should perform the collection of data.
47		79
48	Initially, Colab had support for a small set of applications (Trac, GNU	80	Initially, Colab had support for a small set of applications (Trac, GNU
49	Mailman, Apache Lucene) and all of them was hard-coded; our team evolved Colab	81	Mailman, Apache Lucene) and all of them was hard-coded; our team evolved Colab