Embed Size (px)
Citation preview
Pub/Subbasics
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...
...solve the problem you want?
SOA your solution
Coupling your problem is
SOA Tenets1. «Boundaries Are Explicit»2. «Services Are Autonomous»3. «Services Share Schema and Contract, Not Class»4. «Service Compatibility Is Based Upon Policy»
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
...coupling your problem is
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)
E quindi?Come disaccoppiare?
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;
Messaging patterns
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
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;
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à;
Possiamo declinare tutto ciò su una UI?Un esempio con AngularJS
