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....
In effetti mi sono dimenticato anche questo :-) Di materiale ce ne è già un po’, sparso: Microservices Workshop, esercizi: https://github.com/Particular/Workshop.Microservices, il repo ufficiale del workshop, gli esempi in quanti tali sono ridotti all’osso e per certi aspetti un po’ lontani da un progetto reale; Composite-UI-Sample: https://github.com/mauroservienti/Composite-UI-Sample, la prima bozza che ha dato inizio a tutto; Services-UI-Composition: https://github.com/mauroservienti/Services-UI-Composition, un lungo e corposo lavoro di evoluzione della prima bozza finalizzato a costruire un esempio molto real world; Post in questa serie: SOA service...
Abbiamo parlato di IT/Ops e Batching, un ultimo approccio ricade sotto il nome di Proxy. Quello che abbiamo detto è che a fronte di una domanda è sempre possibile identificare un responsabile per la risposta, parlando di tecnologia potremmo quindi dire che a fronte di una richiesta HTTP identificata da un URI c’è sempre un endpoint che si prenderà carico di gestire/orchestrare la risposta. Per uno sviluppatore .NET viene quasi istintivo tradurre la frase precedente in “…a fronte di una richiesta HTTP identificata da un URI c’è sempre una Action MVC che si prenderà carico…”. Ma HTTP...
Abbiamo introdotto una prima modalità di recupero dei dati, modalità che abbiamo definito IT/Ops. Vi ricordo che IT/Ops è un termine abbastanza generico nel mondo SOA che tipicamente viene usato per identificare quei componenti prettamente tecnologici il cui scopo è gestire l’aggregazione di dati. Il problema che vogliamo risolvere credo sia abbastanza chiaro, nel caso nel post precedente ne parliamo in dettaglio. Batching Come dicevamo il sogno sarebbe poter dire al client, ma soprattutto al team di sviluppatori che gestiscono il client: fai quello che vuoi come l’hai sempre fatto. Per capirci meglio immaginate uno scenario basato...
Torniamo a noi e prima di chiudere il discorso tecniche di recupero dei dati cerchiamo di dare una risposta al commento di Raffaele. Commento che sottolinea che mi sono dimenticato di una cosa di cui ho parlato al compleanno di UGI e evidenzia come sia fondamentale la storia che vogliamo raccontare, storia che nel caso di questi post su UI Composition non è abbastanza ben definita, piuttosto, si sta trasformando mano a mano che li scrivo. Ciao Mauro, leggo con piacere questa serie ma la domanda mi sorge spontanea. ...
Nel mio peregrinare nei meandri del mondo SOA e in particolare di Services UI Composition mi sto sempre più convincendo che i così detti “fat events” non hanno ragione di esistere. È un’affermazione forte lo so, e non è ancora una convinzione, ne parleremo ancora magari cercando di sviscerare la questione fino in fondo. Tipologie di eventi Se penso alla parola “event” la penso declinata nei seguenti modi: Domain Event Thin Event Fat Event Abbiamo già detto, e approfondito, che Domain Event è...
Prima di dare un’occhiata al commento di Raffaele devo fare un altro passaggio. Nella nostra analisi ad un certo punto abbiamo introdotto e definito i servizi che servono per soddisfare il requisito. Tempo fa abbiamo anche parlato di cosa sia un servizio nel mondo SOA. Abbiamo definito i nostri servizi: Che sono: per forza logicamente separati possono essere fisicamente separati possono essere, tutti o in parte, servizi di terze parti Un esempio Quando un ordine su Amazon è in...
Nei nostri esperimenti con UI Compostiion fino a questo momento abbiamo dato per scontato che ci sia un solo modo per “parlare” con i servizi di backend, come potete immaginare non è proprio così. Di seguito l’elenco dei post che trattano l’argomento: SOA service model decomposition: il requisito SOA service model decomposition: un tentativo SOA service model decomposition: i modelli SOA service model decomposition: i servizi Services UI Composition: Recap Questo post sarebbe dovuto arrivare prima del...
Al compleanno di UGI parlando di “Services UI Composition” ho sottolineato un dettaglio che a pensarci bene è di una banalità disarmante, banalità che a volte è meglio ripetersi un paio di volte di troppo al fine di evitare fantasmagorici castelli di carta, o come dicono i francesi “seghe mentali” :-) In DDD esiste il concetto di Ownership, in SOA esiste il concetto di Ownership, quando si parla di sistemi di messaggistica, Command e Pub/Sub, esiste il concetto di Ownership. Quando si parla di UI? silenzio… In realtà se ci pensiamo bene ogni volta...
Direi che ci siamo, dato il contesto che abbiamo ipotizzato i nostri attori sono i seguenti: Marketing Warehouse Sales Shipping Publishing La cosa importantissima che abbiamo identificato a questo punto, e che è la base fondante di un buon design, sono i rispettivi Owner dei vari modelli. Ognuno degli attori in gioco è responsabile di un pezzetto dell’informazione che vediamo stilizzata nella figura di cui sopra, e “Publishing” è responsabile non del tutto, come purtroppo...
Ci siamo lasciati con un primo tentativo che sebbene praticabile espone comunque il fianco ad sacco di potenziali magagne. Prendiamo la solita immagine che abbiamo usato usato fino ad ora e proviamo ad applicare sull’immagine delle etichette che rappresentano gli attori di cui abbiamo parlato nel post precedente, l’obiettivo di questo esercizio è trovare gli owner, trovare quindi quali porzioni dell’informazione che stiamo visualizzando sono gestite da chi. I nostri attori potrebbero essere i seguenti, potrebbero essercene di più o di meno ovviamente in base al contesto: Marketing Warehouse ...
Siamo partiti da questa immagine: Partendo dall’assioma che rappresenti un requisito espresso da uno stakeholder non tecnico, ad esempio un product owner o una porzione dell’information flow frutto di una analisi di user experience. Kudos a Luca che accoglie la sfida e ci prova: Io direi un ViewModel principale (che so ProductsViewModel) ed una serie di template in base a diversi fattori : origine dei dati, prospettive di evoluzione della UX, necessità di rendering, etc... È sbagliato? non necessariamente, è giusto? non necessariamente :-) dipende? non direi, diciamo...
A Napoli abbiamo parlato di “Services UI Composition” e per arrivare li siamo partiti dal problema che vogliamo risolvere problema inevitabilmente generato da una corretta implementazione dei dettami di SOA e DDD. Prima di tornare a parlare di “Services UI Composition”, argomento vastissimo e complesso, vorrei fare un escursus sul processo di modellazione che, se basato su DDD e SOA, porta a risultati che per alcuni possono essere inaspettati. Fate un favore a voi stessi dimenticatevi la tecnologia, evitate cioè di cercare immediatamente una soluzione tecnologica a tutto quello che diremo, è controproducente. Inoltre ricordatevi che cosa è un...