Molto spesso si identificano scenari in cui si richiede l'esposizione di servizi WCF nei confronti di client che utilizzano bindings (protocolli) differenti. Pensiamo ad esempio ad applicazioni intranet/internet le cui infrastrutture di comunicazione sono basate su MSMQ piuttosto che su HTTP. Come è facile intuire, una delle comodità fornite da WCF è il supporto a binding differenti per lo stesso servizio, il che permette di definire endpoint multipli tramite cui i client possono interfacciarsi in maniera diversificata sia da un punto di vista di protocollo di comunicazione che di scenario applicativo. Per questo dobbiamo sempre porre attenzione ai binding da considerare ogni volta che esponiamo un servizio WCF. Di solito i parametri in gioco possono spaziare dallo stile di comunicazione fino ai requisiti di interoperabilità, sicurezza, performance, transazionalità. In base a queste riflessioni, una possibile tassonomia di riferimento può essere la seguente:
- HTTP-based Bindings: tipicamente usata per scenari internet, extranet e di integrazione. Massimo livello di interoperabilità, meno performance.
- BasicHttpBinding per scenari WS-I Basic Profile 1.1
- WsHttpBinding per scenari WS-*
- WsDualHttpBinding analogo a WsHttpBinding con supporto a scenari 'duplex' di invio/ricezione messaggi. In particolare, il client deve avere un URL pubblico e definire un endpoint di callback per il servizio
- WsFederationHttpBinding per scenari che utilizzano il protocollo WS-Federation, finalizzato alla condivisione di identità (utenti o macchine) tra sistemi eterogenei per quanto concerne l'autenticazione e l'autorizzazione
- Connection-Oriented Bindings: da usare preferibilmente in scenari LAN e intranet. Massimi livelli di performance e ottimizzazione.
- NetTcpBinding offre supporto alla comunicazione WCF-to-WCF tra host diversi (security e reliable messaging disabilitati di default)
- NetNamedPipeBinding per la comunicazione con altri servizi nella stessa macchina
- Queue-Based Bindings: anch'essi usati tipicamente in scenari LAN e intranet per massimizzare l'affidabilità ed il throughput.
- NetMsmqBinding dedicato all'utilizzo di MSMQ a livello di trasporto (es. per applicazioni fortemente disaccoppiate e operazioni in modalità disconnessa)
- MsmqIntegrationBinding fornisce il mapping di messaggi MSMQ provenienti da applicazioni COM e C++ nativo in messaggi WCF e viceversa
Riporto infine un classico esempio di configurazione di un servizio WCF che definisce endpoint multipli in grado di supportare, su porte diverse ovviamente, sia WS-I (basicHttpBinding) che WS-* (wsHttpBinding):
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="DemoWCF.AuthenticationService">
<endpoint address="AuthenticationService" binding="wsHttpBinding"
contract="DemoWcfServiceLibrary.IAuthentication"></endpoint>
<endpoint address="AuthenticationService" binding="basicHttpBinding"
contract="DemoWcfServiceLibrary.IAuthentication"></endpoint>
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/DemoWcfService" />
<add baseAddress="http://localhost:9000/DemoWcfService" />
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
</configuration>
Technorati tags: 
WCF