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.

1. 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)

11. E quindi?
Come disaccoppiare?

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;

14. Messaging patterns

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