One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
Attracted by AngularJS power and simplicity, you have chosen it for your next project. Getting started with DataBinding, Scopes and Controllers was relatively quick and easy...
But what do you need to effectively bring a complex application to Production?
We discuss
the new Component API,
lifecycle callbacks - $onChanges
selecting different ways for components to collaborate
choosing between Two-Way Binding and One-Way Data Flow,
"smart" vs "dumb" components,
We ‘ll share recipes from our real world experience so that you can productively & reliably build a complex application out of reusable Components.
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
Andrea Cirioni e Nicola Zangrandi ci hanno presentato un esempio di deploy automatizzato e ripetibile, realizzato con Octopus e la sua integrazione con PowerShell. Ci hanno dimostrato come sia possibile rilasciare nei vari ambienti del cliente gli applicativi con un solo click.
Un'architettura basata sui comandamenti di SOA genera e guida verso sistemi basati sulla decomposizione dei servizi e sul disaccoppiamento del dominio al fine di creare componenti autonomi. Purtroppo, dato che la UI è il luogo dove aggreghiamo tutte le informazioni per l'utente, ci ritroviamo ad accoppiare nuovamente e spesso velocemente di nuovo tutto. Obiettivo della sessione è di sviscerare il problema fino alle sue radici e proporre alcuni possibili approcci per risolverlo.
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
Attracted by AngularJS power and simplicity, you have chosen it for your next project. Getting started with DataBinding, Scopes and Controllers was relatively quick and easy...
But what do you need to effectively bring a complex application to Production?
We discuss
the new Component API,
lifecycle callbacks - $onChanges
selecting different ways for components to collaborate
choosing between Two-Way Binding and One-Way Data Flow,
"smart" vs "dumb" components,
We ‘ll share recipes from our real world experience so that you can productively & reliably build a complex application out of reusable Components.
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
Andrea Cirioni e Nicola Zangrandi ci hanno presentato un esempio di deploy automatizzato e ripetibile, realizzato con Octopus e la sua integrazione con PowerShell. Ci hanno dimostrato come sia possibile rilasciare nei vari ambienti del cliente gli applicativi con un solo click.
Un'architettura basata sui comandamenti di SOA genera e guida verso sistemi basati sulla decomposizione dei servizi e sul disaccoppiamento del dominio al fine di creare componenti autonomi. Purtroppo, dato che la UI è il luogo dove aggreghiamo tutte le informazioni per l'utente, ci ritroviamo ad accoppiare nuovamente e spesso velocemente di nuovo tutto. Obiettivo della sessione è di sviscerare il problema fino alle sue radici e proporre alcuni possibili approcci per risolverlo.
Lavoro da remoto, come Solution Architect, per Particular Software. Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team "dispersed" cresce, più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono “dispersi” su 17 time zone.
Esploriamo assieme come il linguaggio C# e il concetto di “universal”, declinato sulle varie piattaforme hardware, si possono fondere assieme, con poca teoria e molta pratica.
THE ROAD TO A SERVICE ORIENTED ARCHITECTURE (SOA)Mauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
L'utilizzo dei software open source può diventare una vera e propria opportunità per sviluppare la propria azienda, oppure per abbattere i costi di un'azienda esistente.
Tutto questo senza rinunciare alla qualità ed alla sicurezza del software, ma utilizzando prodotti sviluppati e testati da migliaia di persone.
Daniele Barcella "Kowalski", al Linux Day 2016, ha spiegato come si gestisce un progetto open-source. I motivi per i quali condividere un progetto e quali strumenti utilizzare per sviluppo, versionamento, testing. Non manca una panoramica sulle principali licenze open-source.
Costruire un Recommendation Engine con Cosmos DBLaura Villa
In un mondo sommerso da contenuti e prodotti, i sistemi di raccomandazione offrono un aiuto agli utenti e rappresentano una opportunità per le aziende in molti settori. In questa sessione vedremo le basi per attraversare un grafo alla ricerca di spunti per i nostri utenti, in modo da creare un semplice Recommendation Engine da integrare nelle nostre applicazioni. Il tutto utilizzando le Gremlin API di Cosmos DB, con un occhio di riguardo ai costi.
Strumenti open source per il giornalismo: come usare gli open data Alfredo Parisi
Strumenti open source per il giornalismo: come usare gli open data - Sonia Montegiove, Alfredo Parisi, Italo Vignoli
Quali strumenti utilizzare per rielaborare e presentare in modo chiaro i dati aperti messi a disposizione dalle Pubbliche Amministrazioni. Useremo LibreOffice per la rielaborazione statistica delle informazioni e altri programmi open source utili per la presentazione dei dati in forma grafica.
Hai mai pensato di poter inviare un messaggio a tutti gli utenti connessi al tuo sito internet in un particolare momento?
In un momento di picco di traffico della giornata e solo in quell’istante segnalare a tutti una pagina, un appuntamento, richiamarli attraverso una call in action?
SBAAAM! è un sistema di notifiche web che ti consente di farlo.
Il suo funzionamento è molto simile e simile alle notifiche push che vengono utilizzate dalle applicazioni smartphone, ed il suo utilizzo ideale è il crosslinking
La presentazione spiega il servizio e ti da i contatti con il produttore
http://www.xaos.it
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Lavoro da remoto, come Solution Architect, per Particular Software. Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team "dispersed" cresce, più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono “dispersi” su 17 time zone.
Esploriamo assieme come il linguaggio C# e il concetto di “universal”, declinato sulle varie piattaforme hardware, si possono fondere assieme, con poca teoria e molta pratica.
THE ROAD TO A SERVICE ORIENTED ARCHITECTURE (SOA)Mauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
L'utilizzo dei software open source può diventare una vera e propria opportunità per sviluppare la propria azienda, oppure per abbattere i costi di un'azienda esistente.
Tutto questo senza rinunciare alla qualità ed alla sicurezza del software, ma utilizzando prodotti sviluppati e testati da migliaia di persone.
Daniele Barcella "Kowalski", al Linux Day 2016, ha spiegato come si gestisce un progetto open-source. I motivi per i quali condividere un progetto e quali strumenti utilizzare per sviluppo, versionamento, testing. Non manca una panoramica sulle principali licenze open-source.
Costruire un Recommendation Engine con Cosmos DBLaura Villa
In un mondo sommerso da contenuti e prodotti, i sistemi di raccomandazione offrono un aiuto agli utenti e rappresentano una opportunità per le aziende in molti settori. In questa sessione vedremo le basi per attraversare un grafo alla ricerca di spunti per i nostri utenti, in modo da creare un semplice Recommendation Engine da integrare nelle nostre applicazioni. Il tutto utilizzando le Gremlin API di Cosmos DB, con un occhio di riguardo ai costi.
Strumenti open source per il giornalismo: come usare gli open data Alfredo Parisi
Strumenti open source per il giornalismo: come usare gli open data - Sonia Montegiove, Alfredo Parisi, Italo Vignoli
Quali strumenti utilizzare per rielaborare e presentare in modo chiaro i dati aperti messi a disposizione dalle Pubbliche Amministrazioni. Useremo LibreOffice per la rielaborazione statistica delle informazioni e altri programmi open source utili per la presentazione dei dati in forma grafica.
Hai mai pensato di poter inviare un messaggio a tutti gli utenti connessi al tuo sito internet in un particolare momento?
In un momento di picco di traffico della giornata e solo in quell’istante segnalare a tutti una pagina, un appuntamento, richiamarli attraverso una call in action?
SBAAAM! è un sistema di notifiche web che ti consente di farlo.
Il suo funzionamento è molto simile e simile alle notifiche push che vengono utilizzate dalle applicazioni smartphone, ed il suo utilizzo ideale è il crosslinking
La presentazione spiega il servizio e ti da i contatti con il produttore
http://www.xaos.it
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
Come possiamo progettare una UI quando il back-end è composto da decine (se non di più) di Microservices? Abbiamo la giusta separazione e autonomia lato back-end, ma tutto alla fine deve tornare insieme lato front-end. Come evitiamo che si trasformi nel solito caos di spaghetti code? Come evitiamo che operazioni semplici si trasformino in un tornado di web request? Durante questa sessione costruiremo un esempio di UI per Microservices, usando .NET Core, in modo da capire a fondo cosa sia la Services UI Composition e come progettare e implementare con successo una UI per i nostri Microservices.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
3. Evoluzione della specie
• Piccolo software (o POC)
• Successo, crescita e aggiunta di funzionalità
• Il team scala e diventa più grande o distribuito
• Il mantenimento diventa un incubo
• Con sonseguenti alti rischi
Va a finire che parte sempre bene e finisce sempre...
7. SOA Tenets
1. «Boundaries Are Explicit»
2. «Services Are Autonomous»
3. «Services Share Schema and Contract, Not Class»
4. «Service Compatibility Is Based Upon Policy»
8. Boundaries Are Explicit
• I servizi* interagiscono grazie al passaggio esplicito
di «messaggi» che possono attraversare i confini.
• Attraversare i confini di un servizio può essere costoso.
• Un confine rappresenta la netta separazione tra
l’API pubblica di un servizio e la sua
implementazione interna e privata.
* Nel mondo SOA i servizi sono semplici componenti software non servizi intesi come Servizi per Windows
o Demoni
9.
10. Accoppiamento
• Afferente: relativo a, che conduce verso di se
• Altri componenti dipendono da noi
• Efferente: che porta fuori
• Noi dipendiamo da altri componenti
• Temporale
• Ad esempio RPC
• Spaziale
• deployment, indirizzi, topologia di rete
• Tecnologico
• Protocolli (es. .Net Remoting)
13. Messaggi, Comandi ed Eventi
• Messaggi:
• un pezzo di informazione atomica;
• Utilizzati per portare il sistema ad un nuovo stato
consistente;
• Comandi:
• messaggi imperativi;
• diretti verso un destinatario ben preciso;
• Eventi:
• una rappresentazione immutabile del passato;
• Diretti a chiunque sia interessato;
15. Request / Response
• Un messaggio viene inviato ad un destinatario;
• Il destinatario può rispondere;
• Il mittente conosce perfettamente il destinatario:
• Sa dove è;
• Sa cosa mandare;
• Il destinatario:
• Non è tenuto a sapere dove sia il mittente;
• Sa cosa il mittente si aspetta come risposta;
• Abbiamo accoppiamento tra mittente e destinatario;
• Esiste anche Request/Reply
16. Publish / Subscribe
• Un attore nel sistema agisce su qualche cosa:
• L’attore può pubblicare un evento verso l’intero sistema;
• Colui che pubblica non ha nessun interesse nei confronti di
chi sottoscrive;
• Un altro attore può essere interessato ad uno o più
eventi:
• L`attore sottoscriverà gli eventi di suo interesse;
• Tutta l`intenzione è dal lato di chi sottoscrive:
• Chi sottoscrive conosce chi pubblica, non il contrario;
• Chi pubblica manderà in maniera asincrona una copia
dell’evento a tutti i sottoscrittori;
• C’è meno accoppiamento tra chi pubblica e chi
sottoscrive;
17. Accoppiamento: il problema?
• In una parola sola: versioning;
• Request / Response: al cambio di uno degli attori è
quasi certamente necessario aggiornare anche
l’altro;
• Publish / Subscribe: chi pubblica può molto
facilmente garantire la retro-compatibilità;