Da quando Windows Communication Foundation (WCF) è stato rilasciato, è sempre stato presentato come un framework capace di fornire ai programmatori tutto il supporto necessario per sviluppare applicazioni distribuite e basate su servizi. Infatti uno degli obiettivi che ne hanno giustificato l'introduzione è stato la necessità di identificare un modello di programmazione comune che uniformasse l'approccio usato nello sviluppo delle applicazioni distribuite. Prima di WCF le tecnologie esistenti erano diverse: ASP.NET Web Services (ASMX), WS-*, Remoting, MSMQ, Component Services avevano ciascuna protocolli, regole e motivazioni proprie. Il programmatore era chiamato a scegliere la tecnologia in funzione dei propri obiettivi di sviluppo, privilegiando a seconda dei casi l'interoperabilità a discapito della tipizzazione e delle performance e viceversa.

Tecnologie come gli ASP.NET Web Services (noti anche come servizi ASMX) permettevano l'integrazione cross-platform sfruttando messaggi formattati in XML e SOAP scambiati sopra il protocollo HTTP. Questo approccio permetteva la massima interoperabilità dal momento che XML, SOAP e HTTP erano (e rimangono) standard condivisi tra le diverse piattaforme esistenti sul mercato. Per contro tecnologie come Remoting (ovvero i servizi remoti) consentivano la distribuzione applicativa su più nodi fisici e garantivano la comunicazione cross-process e cross-appdomain, pur rimanendo sempre nell'ambito della piattaforma .NET. Dal momento che Remoting si basava su meccanismi proprietari, il suo obiettivo di impiego non era chiaramente l'interoperabilità, ma la possibilità di rendere possibile la comunicazione out-of-process mantenendo la tipizzazione e ottimizzando i meccanismi di interazione.

Massima interoperabilità con WCF

Oggi Windows Communication Foundation fornisce diversi meccanismi di binding che riprendono le motivazioni che hanno giustificato l'uso delle tecnologie di qualche anno fa. Se l'obiettivo è la massima interoperabilità, ecco allora che la scelta ricade inevitabilmente su BasicHttpBinding, in sostituzione dei vecchi servizi ASMX. Per poter utilizzare servizi WCF al posto dei servizi ASMX per colloquiare con applicazioni basate su tecnologie alternative a quelle presenti nel .NET Framework, come per esempio PHP oppure Flash e ActionScript, la scelta di BasicHttpBinding si rivela in molti casi la più azzeccata. Come era per i servizi ASMX, anche BasicHttpBinding si basa su standard condivisi e consolidati come XML, XSD, SOAP, WSDL e HTTP. Questo garantisce la compatibilità nella comunicazione tra le diverse piattaforme di sviluppo.

Non tutto però in WCF è direttamente compatibile. A differenza di quanto avveniva nei servizi ASMX, la versione standard del WSDL prodotta in WCF è strutturata in modo gerarchico e suddivisa in diverse parti, ciascuna delle quali contiene informazioni parziali utili a descrivere il servizio e le sue modalità di chiamata. La descrizione complessiva del servizio è data dall'unione delle informazioni contenute nelle parti del WSDL e, al fine di creare la classe proxy in modo corretto, è compito del client ricostruire la totalità della descrizione importando le descrizioni parziali dalle diverse "location" (nell'esempio seguente: schemaLocation).

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions name="MyService" targetNamespace="http://www.winfxitalia.com/Services/MyService/V1/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:tns="http://www.winfxitalia.com/Services/MyService/V1/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">
  <wsdl:types>
    <xsd:schema targetNamespace="http://www.winfxitalia.com/Services/MyService/V1/Imports">
      <xsd:import schemaLocation="http://ServerName/MyService.svc?xsd=xsd0" namespace="http://www.winfxitalia.com/Services/MyService/V1/"/>
      <xsd:import schemaLocation="http://ServerName/MyService.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
    </xsd:schema>
  </wsdl:types>

  ...omissis...
  
</wsdl:definitions>

Ovviamente in .NET la suddivisione del WSDL in diverse parti non rappresenta un problema nella generazione delle classi proxy. Non si può dire la stessa cosa per PHP e Flash. Il nuovo modo di generare i metadati di WCF "non piace" a PHP e Flash, di conseguenza questa novità rappresenta a tutti gli effetti una breaking-change che non consente una diretta compatibilità tra le tecnologie menzionate. In particolare il tag <xsd:import> non viene interpretato in modo corretto, pertanto diventa impossibile ricostruire in modo completo la descrizione del servizio per la generazione delle classi proxy.

Per fortuna WCF nasce come un framework caratterizzato da un alto grado di personalizzazione ed estendibilità. Oltre alle diverse opzioni già direttamente contemplate e disponibili in modo nativo in WCF, lo sviluppatore può aggiungere funzionalità personalizzate in modo tale da modificare il comportamento standard. La modalità con cui viene generato il WSDL non fa eccezione. Infatti è possibile istruire WCF in modo tale che il WSDL non sia suddiviso in parti, ma venga generato come un'entità unica, come avveniva nel caso dei servizi ASMX. Vediamo come si può fare.