Se avete “seriamente” bisogno di “performance” nelle vostre applicazioni vi consiglio di guardare questa sessione del pdc 2009 su Windows HPC Server 2008.

Praticamente questa estensione al sistema operativo Windows Server 2008(x64) permette di creare un cluster di server su cui distribuire calcoli. Nella sessione si vede come è possibile semplicemente aggiungendo qualche riga di codice .NET, permettere ad un servizio WCF(attraverso le HPC SOA Api) di essere utilizzato sfruttando il parallelismo del cluster, senza che il client debba sapere l’effettivo endpoint, ma usandone uno solo fornito dall’infrastruttura(il sistema prevede un broker che coordina le chiamate verso il cluster).

Come spiegato nel video questa tecnologia permette impostazioni e possibilità più “fini” confronto le classiche tecnologie di “load balancing” e il supporto a livello di Visual Studio e .NET framework rende il tutto molto appetibile e a basso impatto per uno sviluppatore “medio”.

E’ ancora in beta…ma non vedo l’ora di provarlo…buona visione.

Una delle caratteristiche principali dell'architettura "REST style" consiste nel fatto che ogni risorsa sulla quale possiamo effettuare delle operazioni (HTTP verbs) viene univocamente identificata attraverso una URI. Avere delle URIs “ben progettate” diventa quindi molto importante.

Quando creiamo un servizio REST con WCF ci rendiamo conto che le URIs che ne risultano potrebbero essere “disturbate” dall’estensione .svc, la quale permette all’infrastruttura IIS/ASP.NET di processare correttamente le richieste.

Le URIs risultanti sono simili a questa: http://www.domain.com/ServiceName.svc/Resource
Le URIs che noi vorremmo poter utilizzare dovrebbero essere invece strutturate in questo modo : http://www.domain.com/ServiceName/Resource

Come fare in modo che il tutto funzioni con le URIs "REST style"?

Una delle strade possibili consiste nello scrivere un HttpModule che ci permetterà di mappare l'URI "REST style" con l'URI originaria(con l'estensione .svc). Per implementare questa tecnica di url rewrite, dobbiamo creare una classe che implementi l'interfaccia IHttpModule che consta di 2 metodi Init e Dispose. Nel metodo Init ci viene passato dall'infrastruttura di ASP.NET l'oggetto HttpApplication che utilizzeremo per abbonarci all'evento BeginRequest, nel quale gestore attraverso uno degli overload del metodo RewritePath dell'oggetto di contesto HttpContext (HttpContext.Current) possiamo eseguire il "re-write" dell'URI "REST style" all' URI originaria, utilizzata dall'infrastruttura di IIS/ASP.NET/WCF per attivare l'oggetto che implementa la logica del nostro servizio.
Una volta scritto il nostro HttpModule, basterà registrare lo stesso nella sezione <httpModules> della configurazione di ASP.NET.

Chiaramente rimuovere l’estensione .svc rende la URI molto più “elegante” e “significativa”. Utilizzare una URI “non-elegante” non va comunque contro i principi fondamentali dell'architettura "REST style", però qualche purista potrebbe storcere il naso :-) .

Se a qualcuno interessa una implementazione dell'HttpModule fatemelo sapere che ve la mando o la pubblico.

Un pò di tempo fa mi è stato chiesto se era possibile conoscere quale binding venisse utilizzato per il dispatch di una determinata Operation con WCF.
La soluzione più elegante IMHO è quella di utilizzare l'oggetto OperationContext che porta con se tutto il contesto di chiamata e ci permette di ispezionarne tutte le caratteristiche, comprese quelle del channel su cui è stata effettuata.
Precisamente per conoscere il tipo di binding possiamo affidarci alla proprietà Scheme del Listener che ha ricevuto la chiamata:

 OperationContext.Current.EndpointDispatcher.ChannelDispatcher.Listener.Uri.Scheme

la proprietà Scheme è di tipo string, ad esempio se stiamo ricevendo una chiamata su un binding di tipo http troveremo che la proprietà sarà "http".
Detto questo spetta a noi decidere dove controllare questa proprietà a seconda dell'utilizzo che ne vogliamo fare, potrebbe essere in uno dei tanti punti di estensione di WCF come direttamente nel corpo della chiamata al servizio (che non mi piace molto, ma dipende dal problema da risolvere)

Lascio lo snippet del codice completo creato con il tempate di VS 2008:

public class Service : IService

{

    public string GetScheme(){

                  return OperationContext.Current.EndpointDispatcher.ChannelDispatcher.Listener.Uri.Scheme; 

         }  

}

Ho chiaramente modificato il contratto.