I tre pattern architetturali in cui cadono gli scenari gestibili da SB sono questi:

  • Eventing
  • Service Remoting
  • Tunneling

Con Eventing intendiamo proprio i classici meccanismi Publish/Subscribe o di comunicazione One-Way. Inoltre si possono architettare soluzioni con SB che permettano lo storage di messaggi per abilitare scenari di client fortemente disconnessi.

image

Implementare un pattern del genere è molto semplice e si può riassumere in linea generale così:

  • Implementazione di un contratto con operazioni One-Way e MulticastService behavior
  • Autenticazione all’endpoint SB
  • Connessione al service bus da parte del servizio in ascolto
  • Connessione del/dei client per l’invio dei messaggi

Con Service Remoting invece stiamo parlando del “solito discorso” di abilitare servizi intra-net in ambiente cloud, basandoci su una architettura a Relay che agganci il nostro servizio on-premise rendendolo disponibile su Internet.

La parte servizio in questo caso non ha da essere modificata, in quanto in via di configurazione è possibile autenticare il servizio e connetterlo a SB. Il client dovrà invece interrogare il service Registry per ottenere la lista degli endpoints, scegliere quello desiderato e stabilire la connessione.

Con Tunneling intendiamo che, tramite SB, si può implementare un meccanismo per fare  tunneling di altri servizi, nel caso in cui non ci interessi nè l’eventing ne SOA. In pratica l’idea è di implementare dei ponti che ci facciano interconnettere applicazioni su TCP che non siano servizi. Si può partire con un esempio pronto nelle samples del training kit, in cui si mostra come costruire un agente e un bridge (operazioni comunque per utenti esperti).