Show Advanced KnowledgeHide Advanced Knowledge

Rewrite of ECS Server Middleware

1 Initial Problem

ECSA - Elearning Community Service Architecture relies on a middleware called ECS (elearning community server) written by Heiko Bernlöhr and implemented in Ruby mainly serving as a messaging server between connected LMS-Systems (not only ILIAS) and today also campusmangement software (LSF)
See: ECSA — Elearning Community Service Architecture

It is dependent on a specific Ruby Version (1.8.7). This (older) ruby version is not by default available for current long-term-supported Distributions like Ubuntu 14.04/16.04 nor Debian Jessie stable. Generally speaking Ruby applications ar more version dependent than i.e. PHP or nodejs applications. Ruby is not used anywhere else in ILIAS and needs different knowledge and on the webserver-side different setup.

While attending the workshop "CampusConnect" held by Dr. David Boehringer on the ILIAS conference a few participants expressed their difficulties getting the middleware up and running and also maintaining such an important software in the future. That matches my own experiences in setting up the middleware.

As far as I know the author of the ECS Server is not an active ILIAS community member nor maintainer of any ILIAS module but working as a Freelancer.

ECS itself lacks features like authentication and relies on SSL CA-based authentication done via a Webserver or Reverse-Proxy in front of the ECS Server itself. The setup is none-trivial and the need for driving a SSL CA poses organizational problems to the institutions/ILIAS instances that want to take part in an ECS community.

2 Conceptual Summary

I mainly suggest a rewrite of the ECS community server based on a platform which can be better supported by active ILIAS maintainers and/or service providers to open the ECS achitecture to more possible users/institutions. I also think that a maintainer is needed who is actively involved in the ILIAS community.

In detail I suggest to build a new server compatible on the REST API to the existing one. For now I only suggest to reimplement the features described in chapter 1-3 in above mentioned document !

That will be sufficient to interface different LMS to ECS and to build communities sharing content.

3 Technical Information

I would like suggest a discussion about how to implement the new middleware. Our preferences:

• Implementation on nodejs. Perfectly suited for fast REST api and messaging, also stateful and use of websockets possible.
• Implementation in php. Best knowledge in community and easiest to maintain and setup.

Possible Enhancements which don't break compability or need only minor changes of ILIAS plugin:

• Authentication based on Exchange of API Keys + Identification for Institution + Password via https sufficent - No need for CA
• Persistent storage in MySQL Database instead of SQLite

4 Contact

• Author of the Request: Schenk, Ralf [rschenk]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

5 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• ...

6 Discussion

Boehringer, David [DavidBoehringer], 2016-11-29:

Hi Ralf,
I’d prefer not to fork the ECS development with a re-designed ECS. At the University of Stuttgart we are using the ECS also in a completely different context, the “Virtual Programing Lab” (VIPLab: www.tik.uni-stuttgart.de/forschung/projekte/vip) and do not intend to (let) implement all functionalities twice.
An ECS-Community can be run (and is done so) without CA.
Heiko Bernlöhr is currently developing Debian packages for the ECS (and RPMs for our SUSE SLES in Stuttgart). He wants to distribute these packages connected with an ECS-support contract so there will be continuous funding for a continuous development of the ECS. He is eager to offer this in collaboration with a service provider, so that institutions who do not want to rely on a one-man-company can be satisfied. Heiko will get in touch with service providers to talk about the conditions of such a co-operation.
We all agree that the situation with an ECS using a very old version of Ruby is not acceptable. And the ECS must be easier to install. But I do not think that a fork of the development is the best answer to this problem.
David

Killing, Alexander [alex], 29 Nov 2016: Should the ECS middleware be part of our ILIAS product and thus the society and the JF be responsible to take any actions / decisions? Currently this is not the case.

Bogen, Christian [bogen], 2016-11-29: No. I at least do not think that would make sense. The ECS itself was designed as an independent component for good reasons.

7 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.