Con Silverlight3 arrivano una lunga serie di enhancements anche per la parte webservices, tra questi l’utilizzo del BinaryMessageEncoding in sostituzione del precedente TextMessageEncoding.
La nuova modalità diventa il default quando aggiungete al vostro progetto un nuovo Silverlight enabled WCF service e ha lo scopo di di diminuire la dimensione del messaggio aumentando il quindi thoughtput del server.

La nuova configurazione del file Web.Config diventa quindi:

   1: <bindings>

   2:     <customBinding>

   3:         <binding name="binaryBinding">

   4:             <binaryMessageEncoding />

   5:             <httpTransport/>

   6:         </binding>

   7:     </customBinding>

   8: </bindings>

   9: <services>

  10:     <service behaviorConfiguration="WSBinaryFormatter.Web.MyServiceBehavior" name="WSBinaryFormatter.Web.MyService">

  11:         <endpoint address="" binding="customBinding" bindingConfiguration="binaryBinding" contract="WSBinaryFormatter.Web.MyService"/>

  12:         <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

  13:     </service>

  14: </services>

Ovviamente la precedente modalità (basicHttpBinding) è comunque supportata e disponibile in tutti i casi in cui la nuova modalità binaria non è applicabile, ad esempio per interoperabilità con altri sistemi.
Una nota: Non sono personalmente riuscito a utilizzare l’opzione Add service reference di Visual Studio 2008 in presenza di questa nuova modalità in quanto il file di configurazione lato client risulta sempre vuoto, in compenso la nuova utility da riga di comando “slsvcutil.exe” (in pratica è l’equivalente di svcutil.exe per Silverlight3) funziona correttamente. *Update* : Il problema è sparito rimuovendo l’SDK di Silverlight 2.0

Per analizzare meglio quanto viaggiava ho utilizzato il noto tool Fiddler, a tal proposito segnalo questo utilissimo post che spiega come configurarlo per far si che loggi anche le comunicazioni dirette verso localhost.