Services Composition
È tanto che non parliamo di Services Composition e mi sono appena reso conto che abbiamo lasciato il discorso in sospeso. L’ultima volta che abbiamo toccato l’argomento abbiamo delineato cosa succede quando componiamo informazioni che provengono da più servizi e lo scopo è visualizzare un singolo elemento, come ad esempio 1 prodotto. Cosa succede se dobbiamo visualizzare una lista? Sia nello screenshot di cui sopra, che nel seguente, stiamo visualizzando un insieme di elementi, tutti a loro volta frutto di un processo di composizione. Salta probabilmente subito all’occhio il potenziale problema in cui possiamo...
Ci siamo lasciati a questo punto, con una overview ancora architetturale di come funzionano le cose: Il commento di Raffaele mi da lo spunto per entrare un minimo nel tecnico: Back-end Facciamo un esempio con il mero scopo di capire come potrebbero funzionare nella realtà le cose. Marketing è un nostro sistema interno scritto in .NET che espone un’API tramite WebAPI. Sales è un’istanza di SalesForce che paghiamo profumatamente. Shipping sono i servizi del/i corriere/i espresso/i che ci forniscono servizi e li possiamo interrogare sempre tramite un’API basata su HTTP. Warehouse è...
Dopo aver introdotto ViewModel Composition e prima di parlare di UI Composition, lasciatemi approfondire un attimo la parte di composizione perché è propedeutica a quando inizieremo a parlare di scritture. La volta precedente ci siamo lasciati qui: Dicendo che ViewModel Composition è il risultato del lavoro prodotto da IT/Ops nell’orchestrare il dialogo tra client e servizi. OK, ma come? Quello che succede può schematizzato nel seguente modo Tutto inizia con il client interessato ad una risorsa che possiamo identificare con un URL, come ad esempio “/orders/1” dove 1 nel diagramma di cui...
Fino a questo momento non abbiamo fatto distinzioni tra ViewModel Composition e UI Composition, diciamo che in maniera generica abbiamo trattato di Services Composition. Abbiamo sempre usato un diagramma tipo il seguente senza mai addentrarci nei meandri di cosa succede nel client, a livello di UI. Diventa abbastanza ovvio che ci addentriamo nei meandri dello stack tecnologico, cosa che sappiamo non mi interessa, e che quindi per ora non farò. I concetti però sono la prima cosa che dobbiamo digerire. IT/Ops Nel mondo servizi/SOA si tende a etichettare con IT/Ops tutto ciò che è...
Abbiamo parlato a lungo su questo blog di Services UI Composition, in calce a questo post il dettaglio delle “puntate”. Ad inizio maggio a Bristol ho avuto il piacere di parlare proprio di questo argomento presentando il lavoro (lungo) fatto per passare da una primissima ed embrionale versione ad una finalmente solida ed utilizzabile. La prima versione era nata a supporto di un post scritto sul blog aziendale: The secret of better UI composition. La seconda versione Un secondo passaggio nasce invece come primo passo verso qualcosa di più solido, e avrà come primo scopo quello di...
Una delle cose su cui ho stressato molto a Codemotion durante il workshop “Microservices development deep dive” e forse ancora di più nella maratona di 50 minuti all’evento KLab è quanto sia rischioso, in un sistema distribuito, condividere dati: All’aumentare della condivisione perdiamo facilità di evoluzione. La ricerca sembra essere uno di quegli argomenti/requisiti che può essere risolto solo ed esclusivamente con un calderone unico in buttare dentro tutto ciò che è cercabile. Ma è veramente così? Quando Google arrivò ed educò gli utenti che una ricerca poteva essere semplice e non...
Ieri a WPC 2016 ho avuto il piacere di parlare di Services UI Composition, tante domande e una bella discussione a seguire. Ovviamente la domanda più gettonata era: OK, tutto bello…ma quando devo scrivere? L’utente in moltissimi casi non deve solo leggere dati, ma ci deve anche interagire, manipolando le informazioni che sono “sparse”sui vari servizi. Il vero segreto non è la tecnologia ma la conoscenza profonda dei processi di business È necessario spendere tempo, tanto tempo, per comprendere a fondo come sono modellate le interazioni nella realtà, quali informazioni sono...
La domanda di Fabio mi spinge a trattare subito IT/Ops: immagina una ui che vede dal canale di lettura una projection di nome SuperOrder che è un mix di quello che server side avviene a fronte dell'evento dal canale di scrittura di OrderUpdated\Created and CustomerUpdated\Created e dalle quali viene creata una denormalizzazione che confluisce in SuperOrder tutto chiaro, il “problema” è che se scegliamo Services UI Composition come strada una projection risultato un mix tra quello che succede in servizi diversi non esiste, a meno che non ci sia uno specifico caso d’uso...
Abbiamo toccato per la prima volta il problema quando abbiamo parlato della differenza tra eventi ed eventi di dominio per tornarci, grazie a Roberto, con un approfondimento e infine per lanciare la stoccata finale: I fat event non esistono. Non abbiamo però mai detto che cosa sia un fat event. Cosa sono Un esempio vale mille parole, nel mondo Pub/Sub delineato da SOA un evento è (in pseudo codice json) una cosa del tipo: { Id: ‘invoicePaidEvent/some-weird-unique-id’, InvoiceId: ‘the paid...
Quando abbiamo parlato di tecniche di recupero delle informazioni abbiamo introdotto il concetto di proxy. GraphQL sembra essere la soluzione di tutti i mali :-) permettendovi di fare due cose, che voglio approfondire: Implementare il concetto di “proxy” come lo abbiamo descritto liberarvi del male assoluto che rappresentato dal versioning delle API REST pubbliche Mentre il primo punto continua a farmi storce il naso, il secondo è in linea con la mia convinzione che i fat events non esistono. Appena iniziamo a parlare di scritture in un modello distribuitoci ritorneremo....
Full Services Composition Archive