Pool² Dokumentation

Pool²

Jeder Supporter findet heute seinen Weg zu VcA über den Pool. Daher ist das Tool zu einem zentralen Bestandteil unseres Netzwerks geworden. Ob nun das nächste Festival mit sinnstiftender Aktivität füllen, die gesammelten Spenden dokumentieren oder einfach informiert bleiben - all dies läuft mittlerweile über den Pool und so erlaubt das System das dezentrale Wachstum von VcA. Während die neuen Funktionen, wie etwa Email-Newsletter der Crews, unser Zusammenwirken vereinfacht und teilweise sogar erst ermöglicht hat, haben wir versucht den Pool so zu gestalten, dass dieser unseren Bedürfnissen entspricht. Soziales und technisches System haben sich also gegenseitig beeinflusst und sind mittlerweile stark miteinander verwoben.

Viva con Agua ist erfolgreich, weil sehr viele Menschen mit Spaß und Kreativität aktiv werden können. Wir erhalten unsere Motivation, indem wir immer wieder Neues zu probieren, aber uns dabei nicht selbst übernehmen. Denn das Wachstum von VcA basiert nicht auf der Vergrößerung einzelner Aktionen, sondern auf der Vermehrung unterschiedlicher Aktionen. Die dezentrale Organisation, welche der Pool erlaubt, ist somit auch Garant für den Erfolg von VcA.

Gleichzeitig ist die dezentrale Struktur auch die größte Hürde für die Weiterentwicklung des Pools (also die Anpassung des Pools an unser soziales System). Denn wie sollen die vielen verschiedenen Entwicklungen in den Crews, die teilweise auch im Konflikt miteinander stehen, in einem technischen Tool zusammenfließen? Eine Crew braucht dringend einen Chat, um schnell Informationen weiterzugeben, die nächste Crew hätte gerne Abstimmungshilfen, um wirklich faire Entscheidungen zu treffen, verzichtet aber explizit auf Chats, damit das persönliche zwischen den Supportern nicht zu kurz kommt. Die Umsetzung solcher verschiedenen Anforderungen ist nicht alleine komplex, sondern erfordert auch ein gut koordiniertes, größeres Team an Entwicklern. Für eine gemeinnützige Organisation ist der damit verbundene finanzielle Aufwand nicht zu bewältigen.

IT Projektkultur

Daher haben wir uns vorgenommen die Element der VcA Projekte im IT-Umfeld umzusetzen, welche für den Erfolg maßgeblich sind. Das bedeutet, Beteiligte sollten intrinsisch motiviert sein sowie Spaß und Freude an der Realisierung des Projekts haben. Außerdem ist das Projekt eine Komposition kleiner, dezentral organisierter und möglichst unabhängiger Projekte.

Zur Realisierung der angestrebten Kultur sehen wir uns mit diversen Herausforderungen konfrontiert: Zunächst müssen Menschen gefunden werden, die an einer kontinuierlichen technischen Weiterentwicklung in Symbiose mit dem sozialen System interessiert sind. Dabei können ähnlichen Strukturen wie in Open Source Communities entstehen, studentische Arbeiten integriert werden oder Organisationen im Sinne des All-Profit Gedanken einen Beitrag leisten. Zudem muss die Unabhängigkeit der Beteiligten ermöglicht werden. Es also die notwendige Einarbeitung gering zu halten und die Unabhängigkeit von Technologien weitestgehend zu gewährleisten. Auch die Schnittstellen zur Koordination zwischen den Teams sollten frei gestaltet werden können, so dass verschiedene Projektmanagement-Stile unterstützt werden.

Todo:

• Einführung ins Projekt
• Entscheidungen die die Projektkultur definieren
• Grundlagen zur Architektur

Konzepte

Nachfolgend werden grundlegende Konzepte aufgeführt, die eine Implementierung der zuvor beschriebenen, angestrebten Lösung auf technischer Ebene erlauben. Die Liste von Konzepten wird dabei kontinuierlich erweitert und dient einer ersten Orientierung, wenn ein neuer Microservice entwickelt werden soll.

Bezeichnung	Beschreibung	Status
Dynamic UI Fragment Composition	In einer dezentralen Microservice Architektur ist die Implementierung der Nutzeroberfläche eine Herausforderung. Da ein zentraler Service starke Abhängigkeiten aller anderen Services zu diesem einen Service erzeugt, ist dies für die angestrebte Projektkultur keine Lösung. Somit muss jeder Service seine eigene Nutzeroberfläche implementieren können, dabei ist aber ein Corporate Design (CD) zu beachten und Code Duplizierung zu vermeiden. Das vorliegende Konzept beschreibt, wie diese Ziele erreicht werden können.	Draft
Business Object Exchange	Ein Microservice übernimmt die Verantwortung für (mehrere) Business Objects (BO). Diese müssen gegebenenfalls an andere Microservices weitergegeben werden, da diese zusätzliche Informationen zur Durchführung der bereitgestellten Operationen benötigen. Das vorliegende Konzept beschreibt den Austausch der BOs basierend auf RESTful webservices.	Draft
Shared Session	Innerhalb vieler Microservices werden Nutzer identifiziert werden müssen. Damit nicht jeder Microservice eine eigenen Authentifizierung implementieren muss und damit die Wartbarkeit des Gesamtsystem erschwert und außerdem den Nutzern kein eigener Login für jeden Microservice zugemutet wird, soll eine Shared Session implementiert werden. Das vorliegende Konzept beschreibt die Shared Session basierend auf einem OAuth2 Handshake zwischen den Microservices, so dass nur ein Service eine tatsächliche Session mit dem Nutzer halten muss.	Draft
Task-based role system and access control	Klassische Modelle der Zugriffsverwaltung, basierend auf statischen Rollen die einem Nutzer zugewiesen werden können, sind auf das dynamische soziale System von Viva con Agua nicht anwendbar. Allein das Prinzip der Open Participation, welches bei Viva con Agua gelebt wird, verbietet eine starre Implementierung von Rollen mit implizit definierten Zugriffsrechten und daraus resultierenden Aufgaben. Das vorliegende Konzept beschreibt eine Zugriffskontrolle, basierend auf der Assoziation von Nutzern zu Aufgaben. Dabei wird eine Menge von Aufgaben eine dynamische Rolle beschreiben und so das soziale System von VcA angemessen gespiegelt.	Draft
Action-based extension of user representation	Dem Prinzip der Open Participation bei VcA gerecht werdend, sollen Nutzer im Rahmen der Registrierung so wenig Informationen wie nötig angeben müssen. Einige Aktivitäten im Pool² erfordert jedoch mehr Wissen über den Nutzer. So wird etwa bei der Anmeldung für ein Festival die Handynummer und das Geburtsdatum benötigt. Die angestrebte Microservice Architektur soll es ermöglichen dynamisch neue Funktionen dem Pool² hinzuzufügen. Somit kann der Pool² zur Laufzeit um Funktionen erweitert werden die mehr Informationen über den authentifizierten Nutzer erfordern, als dieser bisher angegeben hat. Diesem Problem begegnet das vorliegende Konzept mit einer dynamischen Erweiterung der Stammdaten des Nutzers immer zu genau dem Zeitpunkt, zu dem der Nutzer eine Funktion nutzen möchte. Dabei wird der Datensatz stets nur um die fehlenden Informationen erweitert.	Draft
Intra-Microserves authentication	Bei der Kommunikation zwischen den verschieden Microservices im VcA Pool², müssen diese die Möglichkeit haben sich untereinander zu authentifizieren. Beispielsweise ist es für Drops wichtig zu wissen, ob ein Microservice der eine Shared Session anfordert, auch wirklich Bestandteil des Netzwerkes ist. Andernfalls könnte ein „man in the middle“ die Shared Session abfangen und somit auch im Namen des Nutzers agieren. Realisiert wird die Authentifizierung über einen eigenen Microservice „Sluice“. Das Konzept beschreibt dabei das vorgehen von Sluice und die Auswirkungen auf verschiedene Kommunikationsebenen im Pool².	Draft