3. Learn to build better systems
from Udi Dahan
Advanced Distributed Systems Design
2 days (out of 5) for FREE
Sign up here: http://go.particular.net/COPItaly
Access code: MPNGNC
Expiration date: 25/5/2015
4. Agenda
• Di cosa stiamo parlando?
• Long running workflows: se avete bisogno di uno stato?
5. Tenets
• NServiceBus è un toolkit costruito secoindo i seguenti dettami ed è
pensato per aiutarci a rispettarli:
• Boundaries are explicit
• Services are autonomous
• Services share schema & contract, not class
• Service compatibility is based upon policy
6. 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;
• Comandi ed Eventi sono messaggi con una semantica:
• NServiceBus garantisce la semantica di comandi ed eventi;
8. 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;
9. 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;
10. Accoppiamento: perché è un 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
retrocompatibilità;
• Comandi ad uso interno;
• Eventi ad uso pubblico;
12. Handling
• Ogni volta che un messaggio è ricevuto un handler viene invocato;
• Un handler è il “contenitore” (classe) che ospita il nostro codice;
• Un handler è stateless:
• Ogni volta che arriva un messaggio una nuova istanza viene creata e invocata;
• Ripetete con me «Stateless»;
14. E un handler quindi dove lo piazziamo?
• Gli handler sono raggruppati per servizio (logico);
• I servizi sono ospitati in endpoint;
• Endpoint instance vengono eseguite su Windows:
• Come servizi per Windows:
• Possono essere self hosted;
• Possono usare NServiceBus.Host;
• In qualsiasi tipo di applicazione .NET full framework:
• web, console, WPF, etc…;
16. Recap
• Abbiamo visto cosa sono Endpoint, Messaggi e Handler;
• Come configurare un endpoint tramite BusConfiguration;
• Come scambiare messaggi:
• via request/response;
• via publish/subscribe;
• Come funziona il routing;
18. Trasporti supportati
Il trasporto deve essere affidabile e persistente
al fine di garantire la consegna e sopravvivere ai problemi
• MSMQ
• RabbitMQ
• Sql Server
• Azure ServiceBus
• Azure Storage Queues
20. Saga
• Una saga è un workflow persistente, affidabile e state full:
• Può essere scalato orizzontalmente;
• Sopravvive agli errori;
• È altamente disponibile;
• Una saga garantisce la persistenza dello stato durante
l’orchestramento di più messaggi;
• Garantisce inoltre la consistenza in un ambiente con scalabilità orizzontale;
• Consente di configurare la correlazione tra i messaggi e lo stato;
• Utilizza i “timeout” per prendere decisioni in un mondo asincrono;
22. Recap
• La persistenza può essere:
• RavenDB;
• qualsiasi RDBMS supportato da NHibernate;
• Azure Storage Tables;
• Saga:
• Orchestratore;
• Può essere avviata sia da comandi che da eventi;
• Può essere avviata da più di un messaggio;
