Esporta (0) Stampa
Espandi tutto
Questo argomento non è stato ancora valutato - Valuta questo argomento

Binding di Service Bus

Aggiornamento: gennaio 2014

Windows Azure SDK include un set di binding WCF che automatizzano l'integrazione tra i client e i servizi WCF con il servizio di inoltro offerto da Service Bus di Windows Azure. Nella maggior parte dei casi è sufficiente sostituire il binding WCF corrente in uso con uno dei binding di "inoltro" di Service Bus.

Nella tabella riportata di seguito sono elencati tutti i binding WCF di Service Bus e i binding WCF standard a cui corrispondono. I binding WCF più utilizzati, ad esempio System.ServiceModel.BasicHttpBinding, T:System.ServiceModel.WebHttpBinding, System.ServiceModel.WS2007HttpBinding e System.ServiceModel.NetTcpBinding, corrispondono tutti a un binding di Service Bus con un nome molto simile. È sufficiente inserire "Relay" prima di "Binding". Esistono solo pochi binding di inoltro, ad esempio Microsoft.ServiceBus.NetOnewayRelayBinding and Microsoft.ServiceBus.NetEventRelayBinding, che non hanno un binding WCF corrispondente.

 

Binding WCF standard Binding di inoltro equivalente

System.ServiceModel.BasicHttpBinding

Microsoft.ServiceBus.BasicHttpRelayBinding

System.ServiceModel.WebHttpBinding

Microsoft.ServiceBus.WebHttpRelayBinding

System.ServiceModel.WS2007HttpBinding

Microsoft.ServiceBus.WS2007HttpRelayBinding

System.ServiceModel.NetTcpBinding

Microsoft.ServiceBus.NetTcpRelayBinding

N/D

Microsoft.ServiceBus.NetOnewayRelayBinding

N/D

Microsoft.ServiceBus.NetEventRelayBinding

I binding di inoltro funzionano in modo simile ai binding WCF standard. Supportano ad esempio le diverse versioni di messaggi WCF (SOAP 1.1, SOAP 1.2 e None), i diversi scenari di sicurezza WS-*, servizi di messaggistica affidabili, le funzionalità di flusso e di scambio di metadati, il modello di programmazione Web (ad esempio [WebGet] e [WebInvoke]) e molte altre funzionalità WCF standard. Solo poche funzionalità WCF non sono supportate, ad esempio il flusso di transazioni atomiche e l'autenticazione a livello di trasporto.

Se si ha familiarità con il funzionamento di WCF, potrebbe essere interessante conoscere il mapping tra i nuovi binding (elencati precedentemente nell'argomento) e gli elementi di binding di trasporto WCF sottostanti. Nella tabella riportata di seguito viene specificato l'elemento di binding di trasporto per ciascun binding di inoltro. Come è possibile osservare, l'SDK include diversi nuovi elementi di binding di trasporto WCF, tra cui Microsoft.ServiceBus.HttpRelayTransportBindingElement, Microsoft.ServiceBus.HttpsRelayTransportBindingElement, Microsoft.ServiceBus.TcpRelayTransportBindingElement e Microsoft.ServiceBus.RelayedOnewayTransportBindingElement.

 

Binding di inoltro Elemento di binding di trasporto

Microsoft.ServiceBus.BasicHttpRelayBinding

Microsoft.ServiceBus.HttpRelayTransportBindingElement

Microsoft.ServiceBus.HttpsRelayTransportBindingElement

Microsoft.ServiceBus.WebHttpRelayBinding

Microsoft.ServiceBus.HttpRelayTransportBindingElement

Microsoft.ServiceBus.HttpsRelayTransportBindingElement

Microsoft.ServiceBus.WS2007HttpRelayBinding

Microsoft.ServiceBus.HttpRelayTransportBindingElement

Microsoft.ServiceBus.HttpsRelayTransportBindingElement

Microsoft.ServiceBus.NetTcpRelayBinding

Microsoft.ServiceBus.TcpRelayTransportBindingElement

Microsoft.ServiceBus.NetOnewayRelayBinding

Microsoft.ServiceBus.RelayedOnewayTransportBindingElement

Microsoft.ServiceBus.NetEventRelayBinding

Microsoft.ServiceBus.RelayedOnewayTransportBindingElement

Queste nuove primitive WCF forniscono l'effettiva integrazione di canali a basso livello con il servizio di inoltro in modo non visibile, ma questi dettagli sono nascosti dietro al binding. Nelle sezioni che seguono vengono descritti nei dettagli i binding di inoltro WCF principali e ne viene illustrato l'utilizzo.

NetMessagingBinding

NetMessagingBinding può essere utilizzato dalle applicazioni abilitate per WCF per l'invio e la ricezione di messaggi tramite code, argomenti e sottoscrizioni. Per ulteriori informazioni, vedere NetMessagingBinding.

NetOnewayRelayBinding

NetOnewayRelayBinding è il binding di inoltro maggiormente soggetto a vincoli, poiché supporta solo messaggi unidirezionali. È tuttavia ottimizzato in modo specifico per tale scenario. Per impostazione predefinita, il binding NetOnewayRelayBinding utilizza SOAP 1.2 su TCP insieme a una codifica binaria dei messaggi, benché queste impostazioni di comunicazione siano configurabili mediante tecniche di configurazione dei binding standard. Nei servizi basati su questo binding deve essere utilizzato sempre lo schema di protocollo "sb".

Quando si utilizza questo binding nella configurazione predefinita, il servizio WCF locale tenta di stabilire una connessione in uscita con il servizio di inoltro in modo da creare un socket bidirezionale. In questo caso, crea sempre una connessione TCP/SSL sicura tramite la porta in uscita 828. Durante il processo di connessione, il servizio WCF esegue l'autenticazione fornendo un token acquisito dal Access Control, specifica un nome su cui rimanere in ascolto nel servizio di inoltro e indica al servizio di inoltro il tipo di listener da creare. Quando utilizza questo binding nella configurazione predefinita, un client WCF crea una connessione TCP con il servizio di inoltro attraverso la porta 9350 (TCP) o 9351 (TCP/SSL), a seconda della configurazione del binding. Durante il processo di connessione, deve eseguire l'autenticazione con il servizio di inoltro fornendo un token acquisito dal Access Control. Una volta connesso, il client può iniziare a inviare messaggi unidirezionali a Service Bus da "inoltrare" al servizio locale tramite la connessione TCP.

Se si imposta la proprietà della modalità di sicurezza del binding NetOnewayRelayBinding su Transport, il canale richiederà la protezione SSL. In questo caso, tutto il traffico in entrata e in uscita dal servizio di inoltro sarà protetto tramite SSL. È importante tuttavia realizzare che il messaggio attraverserà il servizio di inoltro senza essere crittografato. Se si desidera garantire la privacy completa, è consigliabile utilizzare la modalità di sicurezza Message, che consente di crittografare tutto tranne le informazioni di indirizzamento nel messaggio che attraversa il servizio di inoltro.

Il binding NetOnewayRelayBinding richiede che tutte le operazioni del contratto del servizio vengano contrassegnate come operazioni unidirezionali (IsOneWay=true). Presupponendo uno scenario di questo tipo, per utilizzare questo binding WCF è necessario specificarlo nelle definizioni degli endpoint e fornire le credenziali necessarie.

Modalità di connettività del sistema

Quando si utilizza NetOnewayRelayBinding, per impostazione predefinita il servizio WCF locale si connette al servizio di inoltro su TCP. Se si utilizza un ambiente di rete che non consente connessioni TCP in uscita oltre a HTTP(s), è possibile configurare i diversi binding di inoltro per l'utilizzo di una modalità di connessione più aggressiva in modo da ovviare a queste limitazioni. A tale scopo, configurare il servizio WCF locale in modo da stabilire una connessione HTTP con il servizio di inoltro (anziché una connessione TCP). In Service Bus è disponibile un'impostazione ConnectivityMode a livello di sistema che può essere configurata con uno dei tre seguenti valori: Tcp, Http e AutoDetect (vedere la tabella riportata di seguito). Se si desidera che i servizi si connettano tramite HTTP, impostare questa proprietà su Http.

 

ConnectivityMode Descrizione

Tcp

I servizi creano connessioni TCP con il servizio di inoltro tramite la porta 9351 (SSL).

Http

I servizi creano una connessione HTTP con il servizio di inoltro in modo da ovviare ai vincoli delle porte TCP.

AutoDetect (impostazione predefinita)

Con questa modalità viene scelta automaticamente la modalità Tcp o Http in base a un meccanismo di rilevamento automatico che controlla se è disponibile una delle due opzioni di connettività per l'ambiente di rete corrente e viene preferita la modalità Tcp.

AutoDetect è la modalità predefinita, in base alla quale i binding di inoltro determineranno automaticamente se utilizzare TCP o HTTP per la connessione del servizio locale al servizio di inoltro. Se nella configurazione di rete è supportata la modalità TCP, per impostazione predefinita verrà utilizzata tale modalità. In pratica, si tenta di utilizzare TCP inviando un messaggio ping a un URL di rilevamento di connessione. Se la connessione TCP ha esito negativo, si passa automaticamente alla modalità HTTP. Nella maggior parte dei casi non è necessario pertanto impostare questa proprietà in modo esplicito, poiché la modalità viene determinata automaticamente dal comportamento predefinito di "rilevamento automatico". Questa proprietà deve essere impostata in modo esplicito solo se si desidera forzare la modalità TCP o HTTP.

È possibile impostare la modalità di connettività a livello di AppDomain tramite la classe ServiceBusEnvironment statica, che fornisce una proprietà SystemConnectivity in cui è possibile specificare uno dei tre valori di ConnectivityMode illustrati precedentemente in questa sezione. Nel codice riportato di seguito viene illustrato come modificare un'applicazione in modo che venga utilizzata la modalità di connettività HTTP:

...
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
ServiceHost host = new ServiceHost(typeof(OnewayService), address);
host.Open();
...

L'impostazione della modalità di connettività del sistema ha effetto su tutti i binding di inoltro.

NetEventRelayBinding

NetEventRelayBinding è molto simile al binding NetOnewayRelayBinding nel modo in cui viene implementato. I valori predefiniti e le opzioni di sicurezza del binding sono identici a quelli di NetOnewayRelayBinding. Inoltre, il meccanismo di interazione dei client e dei servizi con il servizio di inoltro è in pratica lo stesso. Infatti la classe NetEventRelayBinding deriva in realtà dalla classe NetOnewayRelayBinding.

Il binding NetEventRelayBinding si differenzia principalmente per la possibilità di registrare più servizi WCF con lo stesso indirizzo di Service Bus. Quando un client invia un messaggio a questo indirizzo, il servizio di inoltro distribuisce tramite multicast il messaggio a tutti i servizi WCF locali che hanno attualmente sottoscritto l'indirizzo.

Il binding NetEventRelayBinding supporta le stesse opzioni SystemConnectivity di NetEventRelayBinding. Quando si configura la proprietà SystemConnectivity nella classe ServiceBusEnvironment, tale proprietà viene applicata a tutti gli endpoint. È quindi possibile utilizzare la modalità di connettività HTTP aggressiva per tutti gli endpoint NetEventRelayBinding locali se sono ospitati in un ambiente di rete bloccato che impedisce le connessioni TCP in uscita.

NetTcpRelayBinding

Il binding NetTcpRelayBinding supporta la semantica di messaggistica bidirezionale ed è strettamente allineato al binding standard NetTcpBinding WCF. La differenza principale consiste nel fatto che NetTcpRelayBinding crea un endpoint TCP pubblicamente raggiungibile nel servizio di inoltro.

Per impostazione predefinita, il binding NetTcpRelayBinding supporta SOAP 1.2 su TCP e utilizza la serializzazione binaria per garantire una maggiore efficienza. Benché la configurazione sia molto simile a quella di NetTcpBinding, i livelli socket TCP sottostanti sono diversi e pertanto non sono direttamente compatibili tra loro. Per garantire l'integrazione sarà necessario quindi configurare le applicazioni client per l'utilizzo di NetTcpRelayBinding.

Innanzitutto, il servizio WCF locale stabilisce una connessione TCP in uscita sicura con il servizio di inoltro. Durante il processo, deve eseguire l'autenticazione, specificare un indirizzo su cui rimanere in attesa e indicare il tipo di listener da creare nel servizio di inoltro. Fino a questo punto è molto simile al binding NetOnewayRelayBinding. All'arrivo di un messaggio in entrata in uno dei nodi front-end, viene instradato un messaggio di controllo al servizio WCF locale per indicare come creare una connessione di rendezvous con il nodo front-end del client. In questo modo viene stabilito un server d'inoltro da socket a socket diretto per l'inoltro dei messaggi TCP.

Il binding NetTcpRelayBinding supporta due modalità di connessione (vedere TcpRelayConnectionMode) che controllano la modalità di comunicazione tra client e servizio tramite il servizio di inoltro (vedere la tabella riportata di seguito).

 

TcpConnectionMode Descrizione

Relayed (impostazione predefinita)

Tutte le comunicazioni vengono inoltrate tramite il servizio di inoltro. La connessione di controllo protetta tramite SSL viene utilizzata per negoziare una connessione socket end-to-end inoltrata attraverso la quale passano tutte le connessioni. Una volta stabilita la connessione, il servizio di inoltro funziona come proxy server d'inoltro socket che inoltra un flusso di byte bidirezionali.

Hybrid

La comunicazione iniziale viene inoltrata tramite l'infrastruttura del servizio di inoltro mentre il client/servizio negozia una connessione socket diretta reciproca. La connessione diretta viene coordinata dal servizio di inoltro. L'algoritmo di connessione socket diretta può stabilire connessioni dirette tra due parti protette da firewall e dispositivi NAT contrapposti. L'algoritmo utilizza solo connessioni in uscita per l'attraversamento del firewall e si basa su un algoritmo di previsione porta reciproca per l'attraversamento NAT. Nel momento in cui viene stabilita una connessione diretta, la connessione inoltrata viene automaticamente aggiornata a connessione diretta senza perdita di messaggi o di dati. Se non è possibile stabilire la connessione diretta, il flusso dei dati continuerà normalmente attraverso il servizio di inoltro.

Relayed è la modalità predefinita, mentre la modalità Hybrid indica al servizio di inoltro di stabilire una connessione diretta tra le applicazioni client e di servizio. Non devono passare pertanto dati attraverso il servizio di inoltro. Questa modalità viene considerata "ibrida" perché inizia inoltrando le informazioni attraverso il servizio di inoltro mentre tenta di trasformarsi in una connessione diretta. Se il tentativo ha esito positivo, diventerà una connessione diretta senza perdita di dati. Se invece non riesce a stabilire una connessione diretta, continuerà a utilizzare il servizio di inoltro. Il binding NetTcpRelayBinding supporta anche la funzionalità SystemConnectivity quando è necessario configurare il servizio locale per la connessione al servizio di inoltro su HTTP. Quando viene configurata, la proprietà SystemConnectivity viene applicata a tutti gli endpoint. È quindi possibile utilizzare la modalità di connettività HTTP aggressiva per tutti gli endpoint NetTcpRelayBinding locali se sono ospitati in un ambiente di rete bloccato che impedisce le connessioni TCP in uscita.

Binding di inoltro HTTP

Tutti i binding illustrati fino a questo punto necessitano di client per l'utilizzo di WCF sul lato client dell'interazione. Se si necessita di client non WCF per l'integrazione con gli endpoint di Service Bus, è possibile supportare l'inoltro di messaggi basati su HTTP selezionando uno dei diversi binding di inoltro HTTP.

Service Bus include diversi binding HTTP: WebHttpRelayBinding, BasicHttpRelayBinding e WS2007HttpRelayBinding. Questi binding HTTP garantiscono una portata più ampia e una maggiore interoperabilità perché possono supportare qualsiasi client in grado di utilizzare i protocolli standard supportati da ognuno di questi binding. WebHttpRelayBinding e BasicHttpRelayBinding garantiscono la portata più ampia perché si basano rispettivamente su HTTP/REST e sul protocollo SOAP di base. Il binding WS2007HttpRelayBinding può fornire livelli di funzionalità aggiuntivi tramite i protocolli WS-*. Quando si utilizza il binding WS2007HttpRelayBinding, i client devono supportare la stessa suite di protocolli WS-* abilitati nell'endpoint.

Indipendentemente dal binding di inoltro HTTP utilizzato, il meccanismo di quanto avviene nel servizio di inoltro è in pratica lo stesso. Il servizio WCF locale stabilisce innanzitutto una connessione TCP o HTTP con il servizio di inoltro in base all'impostazione di ConnectivityMode in uso. La funzionalità ConnectivityMode ha lo stesso comportamento in tutti i binding di inoltro HTTP. I client quindi iniziano a inviare messaggi all'endpoint HTTP esposto dal servizio di inoltro. Questo significa che WCF non è più necessario nel client. È sufficiente qualsiasi libreria compatibile con HTTP/SOAP. All'arrivo di un messaggio in entrata in uno dei nodi front-end, viene instradato un messaggio di controllo al servizio per indicare come creare una connessione rendezvous con il nodo front-end del client. In questo modo viene stabilito un server d'inoltro da HTTP a socket diretto per l'inoltro dei messaggi HTTP.

Il servizio di inoltro conosce la procedura per instradare i messaggi SOAP 1.1, SOAP 1.2 e HTTP comuni (REST) in modo trasparente. Per definire lo stile di messaggistica e i diversi protocolli WS-* che si desidera utilizzare, configurare uno dei binding di inoltro HTTP procedendo come per qualsiasi altro binding WCF.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

AGGIUNGI
Mostra:
© 2014 Microsoft. Tutti i diritti riservati.