Esporta (0) Stampa
Espandi tutto

Hosting dei servizi WCF con gli endpoint di Service Bus su IIS

Aggiornamento: gennaio 2014

Autore: Santosh Chandwani

Revisore: Seth Manheim

In questo argomento viene descritto come ospitare servizi WCF con endpoint Service Bus di Microsoft Azure in Internet Information Services (IIS) versione 7.5, incluso in Windows Server 2008 R2 e Windows 7. Service Bus di Microsoft Azure fornisce le funzionalità di connettività e messaggistica richieste dalle applicazioni in esecuzione nella piattaforma o in scenari ibridi. In questo argomento vengono descritti i passaggi richiesti per ospitare i servizi sviluppati utilizzando SDK 1.5 o versioni successive, in IIS.

Service Bus di Microsoft Azure offre un'infrastruttura ospitata, sicura e altamente disponibile per una comunicazione capillare, una distribuzione di eventi su larga scala, denominazione e pubblicazione di servizi. Service Bus fornisce opzioni di connettività per WCF e altri endpoint servizio, inclusi quelli REST, che altrimenti sarebbero difficili o impossibili da acquisire. Gli endpoint possono trovarsi nei limiti NAT (Network Address Translation), essere associati a indirizzi IP che cambiano di frequente, assegnati dinamicamente oppure per gli endpoint possono sussistere entrambe le condizioni.

Service Bus fornisce funzionalità di messaggistica "inoltrata" e "negoziata" Nel modello di messaggistica inoltrata, il servizio di inoltro supporta la messaggistica unidirezionale diretta, la messaggistica di richiesta/risposta, la messaggistica full duplex e la messaggistica peer-to-peer. La messaggistica negoziata fornisce componenti di messaggistica asincrona durevole quali code, argomenti e sottoscrizioni, con funzionalità che supportano la pubblicazione-sottoscrizione e il disaccoppiamento temporale: i mittenti e i ricevitori non devono quindi essere contemporaneamente online; l'infrastruttura di messaggistica consente di archiviare in modo affidabile i messaggi finché il ricevente non è pronto a riceverli. Questi modelli sono importanti per applicazioni di cui viene eseguita la migrazione nella piattaforma .

Gli strumenti Service Bus inclusi con SDK semplificano l'integrazione di applicazioni .NET locali con il servizio. L'SDK fornisce un'integrazione continua con Windows Communication Foundation (WCF) e altre tecnologie Microsoft per sfruttare i set di competenze degli sviluppatori esistenti il più possibile. Service Bus SDK include associazioni Service Bus per diverse associazioni di inoltro HTTP e net.TCP e un'associazione per la messaggistica negoziata. È possibile trovare l'elenco completo di associazioni di "inoltro" Service Bus in Binding di Service Bus e l'associazione di messaggistica in NetMessagingBinding.

Sebbene questi servizi siano stati progettati per fornire un'esperienza di sviluppatore di .NET di prima classe, è importante tenere presente che ciascuno di essi fornisce interfacce basate su protocolli standard del settore, rendendo possibile l'integrazione delle applicazioni eseguite in qualsiasi piattaforma mediante i protocolli REST, SOAP o WS-*. Esistono anche Service Bus SDK per Java e Ruby disponibili per il download qui.

Il problema principale relativo all'hosting di un servizio WCF utilizzando associazioni Service Bus in IIS è correlato all'attivazione. Per impostazione predefinita, IIS inizializza un'applicazione Web quando viene ricevuta la prima richiesta.

Tuttavia, affinché il servizio WCF locale con un'associazione di inoltro Service Bus inizi a ricevere messaggi da Service Bus nel cloud, il servizio locale deve aprire una porta in uscita e creare un socket bidirezionale per la comunicazione. Si connette a Service Bus, esegue l'autenticazione e inizia ad ascoltare i messaggi prima che il client invii le relative richieste. Il servizio di inoltro invia i messaggi al servizio locale attraverso il socket bidirezionale già creato.

Analogamente, un'associazione di "messaggistica" fornisce un message pump automatico che effettua il pull dei messaggi da una coda o una sottoscrizione e si integra con il meccanismo ReceiveContext di WCF. Questa associazione deve anche avviare una connessione in uscita a Service Bus nel cloud ed eseguire l'autenticazione prima che il message pump venga attivato.

Poiché IIS e Windows Activation Service (WAS) sfruttano l'attivazione basata su messaggi, per impostazione predefinita le applicazioni Web ospitate in IIS/WAS vengono inizializzate solo dopo l'arrivo della prima richiesta. Pertanto, la classica attivazione basata su messaggi di IIS/WAS non funziona per i servizi WCF con le associazioni Service Bus dal momento che quest'ultime stabiliscono una connessione in uscita al servizio al fine di ricevere messaggi. Questo requisito significa che quando ospitati in IIS, tali servizi WCF devono essere inizializzati in modo esplicito oppure richiedono meccanismi alternativi per inizializzare automaticamente l'applicazione. In questo argomento vengono descritti due metodi per inizializzare automaticamente l'applicazione utilizzando il meccanismo Avvio automatico di ASP.NET e la funzionalità Avvio automatico di Microsoft AppFabric. In alternativa, è possibile utilizzare un servizio NT come host.

Le associazioni Service Bus che utilizzando HTTP non sono integrate con le pipeline HTTP gestite/non gestite. Di conseguenza, la compatibilità di ASP.NET viene interrotta e alcuni scenari, come ad esempio la condivisione dello stato della sessione tra il servizio e un'applicazione ASP.NET ospitata nello stesso dominio dell'applicazione, non funzionano per i servizi WCF con le associazioni Service Bus.

Per compilare servizi WCF con endpoint Service Bus, vedere la sezione Sviluppo di applicazioni che utilizzano Service Bus in MSDN. Sono disponibili diverse applicazioni di esempio.

Si consideri un semplice servizio Echo di WCF con un endpoint webHttpBinding WCF standard. Viene visualizzato un frammento di codice per il servizio come il seguente:

public class WebHttpService : IWebHttpService
{
    public string Echo(string value)
    {
        return string.Format("Echoing: ‘{0}’", value);
    }
}

Il passaggio successivo è aggiornare il servizio per utilizzare due endpoint Service Bus che utilizzano l'associazione webHttpRelayBinding. È possibile ospitare questo servizio in IIS per trarre vantaggio dalle funzionalità di hosting di IIS/WAS.

Nell'esempio seguente vengono aggiunte informazioni sugli endpoint alla sezione Services del file Web.config. In questo frammento, sostituire lo spazio dei nomi del servizio EchoService, le informazioni sul nome del servizio sb-test e le informazioni sull'autorità emittente con il proprio servizio e il proprio spazio dei nomi del servizio.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.serviceModel>
  <services>
    <clear />
    <service behaviorConfiguration="MyServiceTypeBehavior" 
      name="Microsoft.ServiceBus.Samples.WebHttpService">
      <endpoint address="https://sb-test.servicebus.windows.net/WebHttpService/"
      behaviorConfiguration="sharedSecretClientCredentials" 
binding="webHttpRelayBinding"
      bindingConfiguration="WebHttpRelayEndpointConfig" 
name="RelayEndpoint"
      contract="Microsoft.ServiceBus.Samples.IWebHttpService" />
    </service>
  </services>

    <bindings>
      <webHttpRelayBinding>
        <binding name="WebHttpRelayEndpointConfig">
          <security relayClientAuthenticationType="None" />
        </binding>
      </webHttpRelayBinding>
    </bindings>

    <behaviors>
        <!-- Service Bus endpoint behavior-->
        <endpointBehaviors>
          <behavior name="sharedSecretClientCredentials">
            <webHttp/>
            <transportClientEndpointBehavior credentialType="SharedSecret">
              <clientCredentials>
                <sharedSecret issuerName="ISSUER_NAME" issuerSecret="ISSUER_KEY" />
              </clientCredentials>
            </transportClientEndpointBehavior>
          </behavior>
        </endpointBehaviors>
   </behaviors>
  </system.serviceModel>

Per impostazione predefinita, i servizi pubblicati nell'inoltro Service Bus sono "mascherati" e non sono visibili nel feed ATOM del Registro di sistema dei servizi. Per informazioni dettagliate, vedere la sezione Individuazione ed esposizione di un servizio di Service Bus. Si noti che questo passaggio per rendere visibile il servizio nel feed del Registro di sistema dei servizi è facoltativo.

Per impostare il criterio di individuabilità su "Public", creare prima una classe BehaviorExtensionElement personalizzata per ServiceRegistrySettings nella sezione system.serviceModel del file Web.config.

<system.serviceModel>
  <extensions>
    <behaviorExtensions>
<add name="ServiceRegistrySettings"
type="Microsoft.ServiceBus.Samples.MyServiceRegistrySettingsElement, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
  </extensions>

Il passaggio successivo è creare una classe denominata MyServiceRegistrySettingsElement ereditata da BehaviorExtensionElement. Ad esempio:

public class MyServiceRegistrySettingsElement : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get { return typeof(ServiceRegistrySettings); }
    }

    protected override object CreateBehavior()
    {
        return new ServiceRegistrySettings() 
{ DiscoveryMode = this.DiscoveryMode, 
  DisplayName = this.DisplayName };
    }

    [ConfigurationProperty("discoveryMode", DefaultValue = DiscoveryType.Public)]
    public DiscoveryType DiscoveryMode
    {
        get { return (DiscoveryType)this["discoveryMode"]; }
        set { this["discoveryMode"] = value; }
    }

    [ConfigurationProperty("displayName")]
    public string DisplayName
    {
        get { return (string)this["displayName"]; }
        set { this["displayName"] = value; }
    }
}

Per abilitare facoltativamente l'analisi diagnostica per il servizio WCF, è possibile abilitare un listener di traccia. A tale scopo, aggiungere la seguente sezione al file Web.config:

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Warning">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener" 
             initializeData="C:\Log\Traces.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Si noti che la cartella in cui si desidera salvare le tracce ("C:\Log" nel frammento riportato sopra) non verrà creata automaticamente; tale operazione deve essere eseguita dall'utente.

È possibile ospitare i servizi WCF con endpoint Service Bus in IIS sfruttando la funzionalità Avvio automatico di ASP.NET per l'inizializzazione. La funzionalità Avvio automatico consente l'inizializzazione delle applicazioni Web senza dover attendere una richiesta esterna. Questa funzionalità carica e inizializza in modo proattivo eventuali dipendenze come ad esempio l'apertura di connessioni al database, il caricamento di moduli e così via. Precarica i processi di lavoro all'avvio del server Web prima dell'arrivo della prima richiesta. Consente anche il recupero da errori e plug-in di codice personalizzato per eseguire l'inizializzazione avanzata.

È necessario apportate tre modifiche per sfruttare la funzionalità di avvio automatico di ASP.NET:

  • Configurazione del pool di applicazioni

  • Aggiunta di un provider di avvio automatico personalizzato

  • Utilizzo di una factory dell'host di servizi personalizzati per il recupero da errori

Per sfruttare la funzionalità Avvio automatico, ospitare il servizio WCF in un'applicazione virtuale che a sua volta viene associata a un pool di applicazioni destinato al runtime .NET versione 4.0.

HostingWCFServices1

Successivamente, deve essere configurato il pool di applicazioni IIS per tale funzionalità. Questa operazione può essere eseguita modificando il file applicationHost.config. L'attributo startMode per il pool di applicazioni utilizzato deve essere impostato su AlwaysRunning nel file di configurazione in %windir%\System32\inetsrv\config\applicationHost.config.

In questo esempio, il pool di applicazioni è "WebHttpServicePool":

add name=" WebHttpServicePool" autoStart=“true” managedRuntimeVersion="v4.0" startMode="AlwaysRunning" />

Si noti che un pool di applicazioni IIS può ospitare più applicazioni virtuali. In questo esempio, il pool di applicazioni è "/WebHttpService". È possibile configurare questo elemento aggiungendo gli attributi serviceAutoStartEnabled e serviceAutoStartProvider alla voce dell'applicazione nel file applicationHost.config. Ad esempio:

<sites>
    <site name="Default Web Site" id="1">
        <application path="/WebHttpService" 
                     applicationPool="WebHttpServicePool" 
                     serviceAutoStartEnabled="true" serviceAutoStartProvider="AutoStartWebHttpService">
             <virtualDirectory path="/"
                     physicalPath="C:\inetpub\WebHttpService" />
        </application>
    </site>
</sites>

Si noti che in IIS, se il pool di applicazioni viene interrotto in modo esplicito per un qualsiasi motivo, l'attributo serviceAutoStartEnabled viene reimpostato su false. In questo caso, potrebbe essere necessario reimpostarlo su true per ripristinare questa funzionalità.

L'attributo serviceAutoStartProvider riportato nel passaggio precedente fa riferimento a una classe personalizzata che incapsula la logica di avvio per l'applicazione. La classe ServiceAutoStart viene automaticamente richiamata quando il pool di applicazioni e l'applicazione stessa vengono precaricate (prima della ricezione di eventuali richieste Web esterne per l'applicazione). La classe ServiceAutoStart viene automaticamente richiamata per avviare l'host servizio che a sua volta registra l'endpoint Service Bus nel cloud. Quando il metodo Preload della classe viene richiamato, garantisce che l'host servizio venga attivato mediante una chiamata a ServiceHostingEnvironment.EnsureServiceAvailable().

In questo esempio, la classe ServiceAutoStart fa parte dell'assembly Microsoft.ServiceBus.Samples. Il file applicationHost.config deve essere aggiornato nel modo seguente:

<system.applicationHost>

...
<serviceAutoStartProviders>
    <add name="AutoStartWebHttpService" 
         type="Microsoft.ServiceBus.Samples.AutoStartWebHttpService, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</serviceAutoStartProviders>

</system.applicationHost>

Il codice per la classe AutoStartWebHttpService è come mostrato di seguito.

public class AutoStartWebHttpService : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        bool isServceActivated = false;
        int attempts = 0;
        while (!isServceActivated && (attempts <10))
        {
            Thread.Sleep(1 * 1000);
            try
            {
                string virtualPath = "/WebHttpService/WebHttpService.svc";
                ServiceHostingEnvironment.EnsureServiceAvailable(virtualPath);
                isServceActivated = true;
            }
            catch (Exception exception)
            {
                attempts++;
                //continue on these exceptions, otherwise fail fast
                if (exception is EndpointNotFoundException
                    || exception is ServiceActivationException
                    || exception is ArgumentException)
                {
                    //log
                }
                else
                {
                    throw;
                }
            }
        }
    }
}

Si noti che nell'esempio riportato sopra, l'attributo virtualPath deve essere aggiornato in modo appropriato per l'applicazione.

Se si verifica un errore nell'host del servizio WCF, IIS/WAS non possono ricreare l'oggetto host. In questo caso, è possibile riciclare il pool di applicazioni manualmente.

Per ricreare l'oggetto host automaticamente in uno scenario di errore, è possibile utilizzare il modello di factory dell'host di servizi personalizzati di WCF. Per informazioni dettagliate, vedere Host di servizi personalizzati.

È possibile aggiungere la classe di factory dell'host di servizi personalizzati al servizio WCF. Ad esempio:

public class ServiceHostFactoryWebHttpService : ServiceHostFactory
{
    Type incomingServiceType;
    Uri[] incomingBaseAddresses;

    private void OnServiceHostFaulted(object sender, EventArgs e)
    {
        ICommunicationObject faultedHost = (ICommunicationObject) sender;
        faultedHost.Abort();

        ServiceHost host = new ServiceHost(this.incomingServiceType, this.incomingBaseAddresses);
        host.Faulted += this.OnServiceHostFaulted;

        // Sleep to allow time for resource to come back – may require over 10s 
        // for remote services. Without wait/retry logic, process may throw
        // StackOverflow exception if resource is unavailable for an extended 
        // period of time.
        System.Threading.Thread.Sleep(TimeSpan.FromSeconds(10)); 

        host.Open();
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        this.incomingServiceType = serviceType;
        this.incomingBaseAddresses = baseAddresses;
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);
        host.Faulted += this.OnServiceHostFaulted; 
        return host;
    }
}

Il codice Thread.Sleep in questo frammento è illustrativo. Per servizi di produzione, utilizzare la logica di attesa/ripetizione tentativi appropriata.

Per richiamare la factory dell'host servizio, è possibile aggiungere l'attributo Factory al file .svc per il servizio WCF. In questo caso, è il file WebHttpService.svc.

<%@ServiceHost language="C#" Debug="true" 
    Service="EchoServiceMicrosoft.ServiceBus.Samples.WebHttpService" 
    Factory="Microsoft.ServiceBus.Samples.ServiceHostFactoryWebHttpService" 
    CodeBehind="WebHttpService.svc.cs" %>

Microsoft AppFabric 1.1 per Windows Server è un set di estensioni IIS che consente di configurare, gestire e monitorare facilmente le applicazioni WCF e WF in IIS. Vedere Microsoft AppFabric 1.1 per Windows Server per una panoramica su Microsoft AppFabric 1.1 per Windows Server e sulle relative funzionalità.

In questa sezione vengono descritti i passaggi per utilizzare le funzionalità di Microsoft AppFabric per i servizi WCF con endpoint Service Bus.

Microsoft AppFabric utilizza le API di Microsoft.Web.Administration (MWA) per leggere e scrivere lo schema di configurazione. Le API di MWA utilizzano gli schemi memorizzati in %SystemRoot%\System32\inetsrv\config\schema. Poiché il file Web.config per il servizio in questo esempio contiene una configurazione dell'endpoint personalizzata per le associazioni Service Bus, è necessario aggiungere lo schema MWA per gli endpoint Service Bus (collegamento a ServiceBus_schema.xml) e inserirlo nella cartella degli schemi MWA indicata in precedenza. MWA sceglie automaticamente lo schema e analizza la configurazione specifica di Service Bus correttamente.

La funzionalità di avvio automatico di Microsoft AppFabric per i servizi WCF e WF si basa sulla funzionalità di avvio automatico di ASP.NET 4. Consente l'avvio automatico del servizio quando viene riavviato IIS o se viene riciclato il pool di applicazioni.

In IIS Manager, selezionare l'applicazione (in questo esempio, WebHttpService) e fare clic su Configura sotto la sezione Gestisci servizi WCF e WF del riquadro Azioni sul lato destro.

HostingWCFServices2

Dopo questa selezione, viene visualizzata la finestra di dialogo Configura WCF e WF per l'applicazione. Fare clic su Avvio automatico nel menu a sinistra, quindi su Abilitato (avvio automatico di tutti i servizi). Fare clic su per impostare startMode su AlwaysRunning per il pool di applicazioni.

HostingWCFServices3

Per il recupero automatico e per ricreare l'oggetto host in uno scenario di errore, utilizzare il modello di factory dell'host di servizi personalizzati di WCF indicato nella sezione Utilizzo di una factory dell'host di servizi personalizzati per il recupero da errori. L'utilizzo del modello di factory dell'host di servizi personalizzati di WCF è richiesto per i servizi WCF con endpoint Service Bus ospitati in Microsoft AppFabric.

Service Bus di Microsoft Azure supporta le associazioni per la relativa funzionalità di inoltro e messaggistica, semplificando l'accesso a Service Bus nel cloud dai servizi WCF. In questo articolo è stato documentato un set di aggiornamenti di configurazione richiesti per l'hosting di tali servizi WCF in IIS. Viene inoltre descritto l'utilizzo del modello di factory dell'host di servizi personalizzati di WCF richiesto per il recupero automatico da errori.

Mostra:
© 2014 Microsoft