Con l'introduzione del .NET Framework 3.0, ormai avvenuta nel novembre 2006, Microsoft ha rilasciato anche un nuovo framework di cui si è parlato ampiamente nella community di WinFXItalia.com: Windows Communication Foundation.

La sua architettura è così ben fatta e flessibile che fino ad oggi ha subito piccoli ritocchi oppure è stato fornito di nuove funzionalità basandosi sull'infrastruttura già esistente per dare supporto ai servizi REST o ai servizi basati su workflow. Utilizzando questo approccio inoltre, il team di Silverlight ha sviluppato un nuovo binding basato su HTTP, che permette di realizzare servizi appositi per applicazioni Silverlight che necessitano di un canale bidirezionale.

Nell'articolo dedicato alla costruzione di una chat in WCF, si è visto come è possibile costruire una chat con l'ausilio delle session di WCF e delle funzionalità di callback dal servizio al client. In questo modo infatti, sia il server che il client si invertono in continuazione le parti, poiché l'applicativo WinForms/WPF invia la richiesta al server che notifica poi a tutti i client connessi il fatto che un nuovo utente è entrato od ha mandato un nuovo messaggio.

Purtroppo però questa tecnica non è adottabile, perché non è proponibile per motivi di sicurezza che un'applicazione Silverlight si metta in ascolto su una porta, con tutti i problemi di firewall, NAT, ecc annessi a questa tecnica. Il PollingDuplexHttpBinding risolve questa problematica con una tecnica che genera più traffico, ma comunque efficiente e affidabile. Basandosi sul BasicHttpBinding permette infatti al client di chiedere ad intervalli regolari se nella coda dei messaggi di sessione del servizio è disponibile un nuovo messaggio che, se disponibile, viene restituito.

Definizione del contratto

Come ogni servizio WCF, tutto parte dalla definizione del contratto e delle operazioni che si vogliono esporre. A questo proposito valgono tutte le informazioni dell'articolo indicato in precedenza, poiché lato server il motore è sempre WCF, perciò vanno definiti i callback, gli attributi di sessione e di rientranza del servizio.

[ServiceContract(SessionMode = SessionMode.Required,
  CallbackContract = typeof(IChatClient),
  Namespace = "http://ws.winfxitalia.com/SL/Chat/Service")]
public interface IChatService
{
  [OperationContract(Action = "http://ws.winfxitalia.com/SL/Chat/Send", IsOneWay = true)]
  void Send(Message request);

  [OperationContract(Action = "http://ws.winfxitalia.com/SL/Chat/SignIn", IsOneWay = true)]
  void SignIn(Message request);

  [OperationContract(Action = "http://ws.winfxitalia.com/SL/Chat/SignOut", IsOneWay = true)]
  void SignOut(Message request);
}

Nel codice precedente viene quindi definito un servizio con tre operazioni per entrare, uscire dalla chat e per inviare dei messaggi. Per semplificare inoltre, non sono stati definiti gli attributi IsInitiating o IsTerminating, ma si ricorda che tutte queste informazioni sono comunque valide. Le uniche accortezze da dover fare riguardano la specifica indicazione dell'azione di un'operazione per facilitare poi le chiamate esplicitando quale effettuare. Inoltre non bisogna inserire caratteristiche, come sicurezza, crittografia che non sono supportate dal BasicHttpBinding.

Il servizio fa poi uso del callback di tipo IChatClient per notificare al client che un utente è entrato, uscito oppure ha mandato un messaggio. Nell'esempio successivo lo si fa definendo l'operazione NewAction:

[ServiceContract()]
public interface IChatClient
{
  [OperationContract(Action = "http://ws.winfxitalia.com/SL/Chat/NewAction", IsOneWay = true)]
  void NewAction(Message message);
}

Come si può vedere da entrambe le interfacce, tutte le operazioni ricevono la classe Message, tipo di WCF che permette di leggere direttamente il SOAP message ricevuto. Questo perché in Silverlight 2.0 non è possibile aggiungere semplicemente la service reference e ottenere un proxy automaticamente generato, ma bensì si deve creare e interrogare manualmente il messaggio da inviare al servizio.

Anche il callback che si può ricevere in Silverlight è semplicemente il messaggio e non porta nessuna informazione sulla action che lo include, perciò si è definita una singola operazione che fa da un unico pentolone dove inserire una per volta tutte le notifiche da inviare al client.