Questa è una vecchia versione del documento!
Per funzionare il sistema avrà bisogno dei seguenti microservizi “di bootstrap”, gli stessi non sono necessari a un funzionamento di base, ma serviranno per un utilizzo completo:
Esporrà i modelli Capabilities (importate dai manifest dei microservizi), Applications, Groups, Users, Sessions (in un ottica di multi-tenancy potrebbe esporre anche la stessa). E' il centro stella del sistema, motivo per il quale i microservizi devono cachare le sue risposte per la durata di vita dei token. Offre un servizio oauth di autenticazione applicativa. Offre un servizio oauth di autenticazione utente. Offre un api per ottenere l'identità e le capabilities relative a un token. Non sono previste dalla presente gestione dello scoping delle informazioni.
Esporrà un modello Log, sarà utilizzabile con l'api già presentata. Categorizzerà i log nelle seguenti categorie:
Deve garantire un funzionamento diffserv all'interno del quale:
I log di tipo perf_start e perf_end sono log transitori utili alla generazione dei log perf
Esporrà un modello Resource, che rappresenterà un file caricato da un utente.
In tal senso nell'architettura è l'unico microservizio che necessita di accedere a un disco, centralizza e semplifica la gestione sistemistica e delle risorse. Oltre all'api succitata offrirà un api di upload a chunk di dati binari, referenzierà tramite url la risorsa che deve essere depositata di default su uno spazio sufficientemente randomico, ma alla quale dovrà poter esser associato un pretty url (non richiesto, un tiny url), la risorsa dovrà poter essere prelevata anche tramite cdn, può restare non disponibile fino a quando il modello non è in stato ACTIVE.
Consentirà di gestire delle Job Queue FIFO a priorità differenziata, ancora da definire.