Un Service Bus è un’attore che fornisce connettività tra sistemi di differente topologia e spesso, differenti. Talvolta fornisce anche una serie di strumenti per la gestione del messaging e dell’orchestration al fine di orchestrare appunto processi di business complessi ed integrare sistemi diversi. Nell’ottica Cloud, un service bus potrebbe facilmente essere visto come strumento a supporto dell’integrazione tra le applicazioni on-premise e quelle cloud-based.

Un esempio che Microsoft ci ha da sempre fornito per intendere meglio ciò che potrebbe fare il SB di Azure è il seguente: supponiamo di avere un servizio all’interno della nostra struttura on-premise e supponiamo di doverlo fare consumare anche da Internet. In uno scenario siffatto, è chiaro considerare l’approccio “1.0” di aprire un firewall, gestire un eventuale NAT e/o demilitarizzare il server contenente il servizio. Con AppFabric SB invece è possibile registrare un Relay sul Cloud che punterà effettivamente al servizio on-premise sulla rete locale.

image

Non è solo un problema di Firewall, anche se in strutture complesse (come quelle in figura sotto), traversare un firewall o configurarlo opportunamente può essere estremente complesso se non addirittura non fattibile. Questo porta spesso alla creazione di workarounds che rischiano di creare problemi di sicurezza.

image

Da qui arriviamo al semplice concetto che se facciamo in modo che il nostro servizio si “registri” al Relay di Azure (uscendo di fatto autonomamente dalla rete on-premise), le successive comunicazioni verranno girate dal Cloud al servizio agganciato.

Sebbene SB sia abbastanza isolato come comportamento e funzionalità, erogando un servizio di Naming, Messaging e Registry, esso può operare in sintonia costruttiva con Access Control, di cui abbiamo già parlato precedentemente.

image

Naming

Il DNS va benissimo per risorse che rimangono tali e definite per un certo intervallo di tempo. Si adattano bene a gestire il naming per gli Hosts, un pò meno per quanto riguarda i servizi, soprattutto per la lunga latenza nella propagazione dei record DNS. Un sistema di naming per i servizi dovrebbe gestire granularmente gli endpoint e non le macchine fisiche; inoltre dovrebbe garantire una bassa latenza per gli update. Siccome però gli URI sono molto diffusi e il DNS è il sistema campione per il naming su internet, il servizio di naming di SB dicesi “DNS-integrated” ovvero adeguato allo standard. Esso sfrutta infatti le alberature dell’URI per mappare i singoli servizi:

image

Registry

Sul registry c’è non molto da dire, fuori dall’ovvio. Esso è fondamentalmente un registry limitato alla registrazione di Service Endpoints, accessibile sia in fase amministrativa che programmaticamente via API. Esso fornisce l’infrastruttura per il sistema di Naming.

Messaging

La funzionalità essenziale è lo scambio di messaggi (orientato principalmente al mondo WCF) basato su Relays. Infatti per ogni binding WCF ne esiste un analogo su SB che ne gestisca il relay:

image