Pub/Sub Basics
Download as PPTX, PDF1 like911 views
Il documento esplora i principi fondamentali dell'architettura orientata ai servizi (SOA) e come gestire il disaccoppiamento tra i servizi attraverso l'uso di messaggi, comandi ed eventi. Viene analizzato il confronto tra i modelli di comunicazione 'request/response' e 'publish/subscribe', evidenziando i vantaggi di quest'ultimo in termini di minore accoppiamento e compatibilità retroattiva. Infine, si menziona un esempio di implementazione di tali concetti in un'interfaccia utente utilizzando AngularJS.
Pub/Sub Basics
- 2. Mauro Servienti Architetto @ Particular Software mauro.servienti@particular.net @mauroservienti //github.com/mauroservienti
- 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...
- 6. SOA your solution Coupling your problem is
- 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
- 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à;
- 18. Possiamo declinare tutto ciò su una UI? Un esempio con AngularJS