Pool² Dokumentation: Unterschied zwischen den Versionen
Aus VcA | Wiki
(Die Seite wurde neu angelegt: „== Pool² == Todo: * Einführung ins Projekt * Entscheidungen die die Projektkultur definieren * Grundlagen zur Architektur === Konzepte === {| class="wikitab…“) |
Keine Bearbeitungszusammenfassung |
||
Zeile 6: | Zeile 6: | ||
=== Konzepte === | === 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. | |||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
|- | |- | ||
Zeile 18: | Zeile 20: | ||
| [[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 | | [[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]] || | | [[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]] || -- || Draft | | [[Intra-Microserves authentication]] || -- || Draft | ||
|} | |} |
Version vom 6. April 2017, 08:45 Uhr
Pool²
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 | -- | Draft |