15

Nov

WCF4 RouterService – Il router soap gratuito di Microsoft

Ciao a tutti

 

WCF4 porta con se una interessante funzionalità: un router soap completamente configurabile in base ai nostri filtri, da file di configurazione.

 

Uso principale:

Fondamentalmente un router non è necessario al funzionamento di un servizio WCF, ma offre alcune interessanti funzionalità altrimenti non disponibili come: l’accesso esterno ad un unico endpoint grazie al mascheramento degli URI dei servizi reali, così come la gestione delle priorità e delle versioni dei servizi.

 

Un esempio:

creiamo una nuova webaplication vuota

aggiungiamo i riferimenti agli assembly del System.ServiceModel.*

aggiungiamo questa configurazione nel web.config

 

 
 
   
     
   

 
 
 
   
                      binding="wsHttpBinding"
                contract="System.ServiceModel.Routing.IRequestReplyRouter"
                />
   

 
 
 
   
     
       
     

   

 

 
   
     
   

   
     
       
     

   

 

 
                  address="
http://localhost:1289/DateTimeService.svc"
              binding="wsHttpBinding"
              contract="*" />
 

 

analizziamo l’xml.

ho impostato un servizio di tipo System.ServiceModel.Routing.RoutingService, il servizio gentilmente realizzato da Microsoft per noi. questo servizio implementa varie interfacce per le varie modalità di funzionamento: request-reply, simplex (one way), duplex. nel nostro caso abbiamo utilizzato la modalità classica request-reply impostando come contratto di servizio esposto il System.ServiceModel.Routing.IRequestReplyRouter.

successivamente abbiamo creato un behavior in cui abbiamo impostato il routing in base ad una configurazione, la tabella di routing scelta.

in alto, alla voce serviceActivations abbiamo detto di rispondere alle chiamate al file router.svc con quel servizio.

il resto invece è la configurazione del router stesso in cui abbiamo impostato un semplice filtro di tipo MatchAll che dirotta ogni comunicazione allo stesso indirizzo.

 

se avessimo invece più servizi (come probabilmente è) dovremmo impostare dei filtri più intelligenti. ricordiamo sempre che i filtri funzionano tipo subscribe, in pratica il router fa il multicast del messaggio per ogni filtro che corrisponde!

vediamo il nuovo web.config:


 
   
     
   

 

 
 
   
                      binding="wsHttpBinding"
                contract="System.ServiceModel.Routing.IRequestReplyRouter"
                />
   

 

 
 
   
     
       
     

   

 

 
   
      http://datetime.service.it/IDateTimeService/GetDateTime" />
      http://echoservice.services.it/IEchoService/Echo" />
   

   
   
     
       
       
     

   

 

 
                  address="
http://localhost:1289/DateTimeService.svc"
              binding="wsHttpBinding"
              contract="*" />
   
                  address="
http://localhost:1289/EchoService.svc"
              binding="wsHttpBinding"
              contract="*" />   
 

in questo esempio vediamo come abbiamo utilizzato l’action come discriminante per richiamare 2 servizi diversi.

il client invece utilizza un semplice app.config così composto:


   
        http://localhost:1232/router.svc" binding="wsHttpBinding"
            contract="ServiceReference1.IDateTimeService" name="WSHttpBinding_IDateTimeService" />
        http://localhost:1232/router.svc" binding="wsHttpBinding"
            contract="ServiceReference2.IEchoService" name="WSHttpBinding_IEchoService"/>
   

 

1 consiglio? nel .config del router è bene configurare un trace di questo tipo:


 
   
     
       
     

   
   
     
       
     

   
 

per poter capire se e perchè un messaggio non viene correttamente dirottato.

 

infine ricordo che con una webapplication è bene aggiungere il flag “Copy Local” al riferimento System.ServiceModel.Routing

 

a presto

by Antonio Esposito on 11/15/2010