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	39
40	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	80	Initially, Colab had support for a small set of applications (Trac, GNU
49	81	Mailman, Apache Lucene) and all of them was hard-coded; our team evolved Colab
...	...