Exporter (0) Imprimer
Développer tout

Hébergement des services WCF avec des points de terminaison Service Bus sur IIS

Mis à jour: janvier 2014

Auteurs : Santosh Chandwani

Réviseur : Seth Manheim

Cette rubrique décrit comment héberger les services WCF avec les points de terminaison Windows Azure Service Bus sur Internet Information Services (IIS) version 7.5, qui est inclus dans Windows‎‎ Server 2008 R2 et‏ Windows 7. Windows Azure Service Bus fournit la connectivité et les fonctions de messagerie requises par les applications qui s'exécutent sur la plateforme Windows Azure ou dans des scénarios hybrides. Cette rubrique traite des étapes nécessaires à l'hébergement des services qui ont été développés à l'aide de Windows Azure SDK 1.5 ou version ultérieure, sur IIS.

Présentation de Windows Azure Service Bus

Windows Azure Service Bus fournit une infrastructure hébergée, sécurisée et largement disponible pour la communication généralisée, la distribution des événements à grande échelle, la dénomination et la publication de services. Service Bus offre des options de connectivité pour WCF et d'autres points de terminaison de service, y compris les points de terminaison REST qui autrement seraient difficiles ou impossibles à atteindre. Les points de terminaison peuvent être situés derrière les limites NAT (Network Address Translation) ou liés à des adresses IP attribuées dynamiquement ou qui changent souvent, ou les deux.

Service Bus fournit des fonctionnalités de messagerie à la fois « relayée » et « répartie ». Dans le modèle de messagerie répartie, le service de relais prend en charge la messagerie directe unidirectionnelle, la messagerie demande-réponse, la messagerie en duplex intégral et la messagerie d'égal à égal. La messagerie répartie fournit des composants de messagerie durables et asynchrones tels que des files d'attente, des rubriques et des abonnements, avec des fonctionnalités qui prennent en charge la publication-abonnement et le découplage temporel : les expéditeurs et les récepteurs ne sont pas obligés d'être en ligne au même moment ; l'infrastructure de messagerie stocke les messages de façon fiable jusqu'à ce que le destinataire soit prêt à les recevoir. Ces modèles sont importants pour la migration des applications vers la plateforme Windows Azure.

Les outils Service Bus inclus avec le kit de développement logiciel (SDK) Windows Azure simplifie l'intégration des applications .NET sur site avec le service. Le kit de développement logiciel (SDK) assure une intégration fluide avec Windows Communication Foundation (WCF) et d'autres technologies Microsoft pour tirer parti autant que possible des jeux de compétences actuelles des développeurs. Le kit de développement logiciel (SDK) Service Bus inclut des liaisons Service Bus vers diverses liaisons de relais HTTP et net.TCP, et une liaison de messagerie pour la messagerie répartie. Vous trouverez la liste complète des liaisons de « relais » Service Bus à l'adresse Liaisons Service Bus et la liaison de messagerie à l'adresse NetMessagingBinding.

Bien que ces services aient été conçus pour offrir une expérience de développeur . NET de première classe, il est important de noter que chacun d'eux fournit des interfaces basées sur des protocoles standard du secteur, ce qui permet aux applications qui s'exécutent sur toute plateforme de s'intégrer avec elles via les protocoles REST, SOAP WS-*. Il existe aussi les kits de développement logiciel (SDK) Service Bus pour Java et Ruby qui sont disponibles en téléchargement ici.

Défis liés à l'activation des services hébergés sur IIS

Le principal défi de l'hébergement d'un service WCF à l'aide de liaisons Service Bus sur IIS est lié à l'activation. Par défaut, IIS initialise une application Web à la réception de la première demande.

Cependant, pour que le service WCF sur site avec une liaison de relais Service Bus commence à recevoir des messages à partir de Service Bus dans le cloud, le service sur site doit ouvrir un port sortant et créer un socket bidirectionnel pour la communication. Il se connecte à Service Bus, s'authentifie et se met à l'écoute des messages avant que le client envoie ses demandes. Le service de relais envoie ensuite les messages au services sur site via le socket bidirectionnel déjà en place.

De même, une liaison de « messagerie » fournit une pompe automatique de messagerie qui extrait les messages d'une file d'attente ou d'un abonnement, et est intégrée dans le mécanisme ReceiveContext de WCF. Cette liaison doit également amorcer une connexion sortante vers Service Bus dans le cloud et s'authentifier avant que le pompe de messagerie ne soit activée.

Dans la mesure où IIS et Windows Activation Service (WAS) s'appuient sur l'activation basée sur des messages, les applications Web hébergées dans IIS/WAS sont initialisées par défaut seulement à la réception de la première demande. Par conséquent, l'activation basée sur les messages IIS/WAS ne fonctionne pas pour les services WCF avec les liaisons Service Bus, car ces liaisons doivent d'abord établir une connexion sortante vers le service afin de recevoir des messages. Cette exigence signifie que lorsqu'ils sont hébergés sur IIS, ces services WCF doivent être explicitement initialisés, sinon ils nécessitent d'autres mécanismes pour initialiser automatiquement l'application. Cette rubrique décrit deux méthodes permettant d'initialiser automatiquement l'application en utilisant le mécanisme de démarrage automatique ASP.NET et la fonctionnalité de démarrage automatique de Microsoft AppFabric. Vous pouvez également utiliser un service NT comme hôte.

Intégration avec le pipeline HTTP

Les liaisons Service Bus qui utilisent HTTP ne sont pas intégrées avec les pipelines HTTP gérés/non gérés. Ainsi, la compatibilité ASP.NET est cassée et certains scénarios, tels que le partage de l'état session entre le service et une application ASP.NET hébergée dans le même domaine d'application, ne fonctionnent pas pour les services WCF avec des liaisons Service Bus.

Développement de services WCF utilisant des points de terminaison Service Bus

Pour créer des services WCF avec des points de terminaison Service Bus, consultez la section Développement d’applications utilisant Service Bus sur MSDN. Un certain nombre d'exemples d'applications sont disponibles.

Prenons l'exemple d'un service WCF Echo simple ayant un point de terminaison WCF webHttpBinding standard. Un extrait de code pour le service apparaît comme suit :

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

L'étape suivante consiste à mettre à jour le service de façon à ce qu'il utilise deux points de terminaison Service Bus employant la liaison webHttpRelayBinding. Vous pouvez héberger ce service dans IIS pour bénéficier des capacités d'hébergement IIS/WAS.

Mise à jour de Web.config

L'exemple suivant ajoute les informations de point de terminaison à la section Services du fichier Web.config. Dans cet extrait, remplacez l'espace de noms du service EchoService, les informations du nom du service sb-test et les informations sur l'émetteur par votre service et votre espace de noms.

<?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>

Extensions du comportement des paramètres ServiceRegistry

Par défaut, les services publiés sur le relais Service Bus sont « masqués » et ne sont pas visibles dans le flux ATOM du Registre de service. Pour les détails, consultez la section Découverte et exposition de Service Bus Service. Notez que cette étape destinée à rendre le service visible dans le flux du Registre de service est facultative.

Pour définir la stratégie de découverte sur « Public », créez d'abord un BehaviorExtensionElement pour ServiceRegisterySettings dans la section system.serviceModel du fichier 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>

L'étape suivante consiste à créer une classe appelée MyServiceRegistrySettingsElement qui hérite de BehaviorExtensionElement. Par exemple :

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; }
    }
}

Activation du suivi de diagnostic pour le service

Pour activer facultativement le suivi de diagnostic pour le service WCF, vous devez activer un écouteur de trace. Pour cela, ajoutez la section suivante dans le fichier 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>

Notez que le dossier dans lequel vous voulez que les traces soient émises (« C:\Log » dans l'extrait de code ci-dessus) ne sera pas créé automatiquement ; il doit exister.

Hébergement des services WCF avec les points de terminaison Service Bus sur IIS 7.5

Vous pouvez héberger des services WCF avec des points de terminaison Service Bus sur IIS en tirant parti de la fonctionnalité de démarrage automatique ASP.NET pour l'initialisation. La fonction de démarrage automatique permet d'initialiser des applications Web sans avoir à attendre une demande externe. Cette fonction se charge de manière proactive et initialise toutes les dépendances telles que l'ouverture de connexions de bases de données, le chargement de modules, et ainsi de suite. Elle précharge les processus de travail au démarrage du serveur Web avant l'arrivée de la première demande. Elle permet aussi la récupération après des dysfonctionnements, et permet aux plug-ins de code personnalisé d'effectuer une initialisation avancée.

Trois changements devraient être effectués pour tirer parti de la fonctionnalité de démarrage automatique ASP.NET :

  • Configuration du pool d'applications

  • Ajout d'un fournisseur de démarrage automatique personnalisé

  • Utilisation d'une fabrique d'hôte de service personnalisé pour la récupération après incident

Configuration du pool d'applications

Pour tirer parti de la fonction de démarrage automatique, hébergez le service WCF dans une application virtuelle qui est à son tour associée à un pool d'applications ciblant la version .NET runtime version 4.0.

HostingWCFServices1

Ensuite, le pool d'applications IIS doit être configuré pour le démarrage automatique. Pour cela, éditez le fichier applicationHost.config. L'attribut startMode du pool d'applications doit être défini sur AlwaysRunning dans le fichier de configuration à l'adresse %windir%\System32\inetsrv\config\applicationHost.config.

Dans cet exemple, le pool d'applications est « WebHttpServicePool » :

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

Notez qu'un pool d'applications IIS peut héberger plusieurs applications virtuelles. Dans cet exemple, l'application est « /WebHttpService » : Vous pouvez configurer ceci en ajoutant les attributs serviceAutoStartEnabled et serviceAutoStartProvider à l'entrée de l'application dans le fichier applicationHost.config. Par exemple :

<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>

Notez que dans IIS, si le pool d'applications est explicitement arrêté pour une raison quelconque, l'attribut serviceAutoStartEnabled est réinitialisé sur false. Dans ce cas, vous pourriez avoir à le remettre sur true pour restaurer cette fonctionnalité.

Ajout d'un fournisseur de démarrage automatique (AutoStart) personnalisé pour le service

L'attribut serviceAutoStartProvider référencé à l'étape précédente se réfère à une classe personnalisée qui encapsule la logique de démarrage pour l'application. La classe ServiceAutoStart est automatiquement appelée lorsque le pool d'applications et l'application sont préchargés (avant que toutes les demandes Web externes soient reçues pour l'application). La classe ServiceAutoStart est automatiquement appelée pour démarrer l'hôte de service qui enregistre ensuite le point de terminaison Service Bus dans le cloud. Quand la méthode de la classe Preload est appelée, elle fait en sorte que l'hôte du service soit activé par un appel à ServiceHostingEnvironment.EnsureServiceAvailable().

Dans cet exemple, la classe ServiceAutoStart fait partie de l'assembly Microsoft.ServiceBus.Samples. Le fichier applicationHost.config doit être mis à jour comme suit :

<system.applicationHost>

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

</system.applicationHost>

Le code pour la classe AutoStartWebHttpService figure ci-dessous.

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;
                }
            }
        }
    }
}

Notez que dans l'exemple ci-dessus, virtualPath doit être correctement mis à jour pour l'application.

Utilisation d'une fabrique d'hôte de service personnalisé pour la récupération après incident

En cas d'échec de l'hôte du service WCF, IIS/WAS ne peut pas recréer l'objet hôte. Dans ce cas, vous pouvez recycler manuellement le pool d'applications.

Pour récréer automatiquement l'objet hôte dans un scénario de défaillance, vous pouvez utiliser le modèle de fabrique d'hôte de service personnalisé de WCF. Pour plus de détails, consultez Custom Service Host.

Vous pouvez ajouter la classe de fabrique d'hôte de service personnalisé au service WCF. Par exemple :

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;
    }
}

Le code Thread.Sleep dans cet extrait est fourni à titre d'illustration. Pour les services de production, utilisez la logique wait/retry appropriée.

Pour appeler la fabrique d'hôte de service, vous pouvez ajouter l'attribut Factory au fichier .svc pour le service WCF. Dans ce cas, il s'agit du fichier WebHttpService.svc.

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

Hébergement des services WCF avec des points de terminaison Service Bus dans Microsoft AppFabric

Microsoft AppFabric 1.1 pour Windows Server est un ensemble d'extensions IIS qui permettent de facilement configurer, gérer et surveiller les applications WCF et WF sur IIS. Consultez Microsoft AppFabric 1.1 pour Windows Server pour une vue d'ensemble de Microsoft AppFabric 1.1 pour Windows Server et ses fonctionnalités.

Cette section décrit les étapes d'utilisation des fonctionnalités de Microsoft AppFabric pour les services WCF avec des points de terminaison Service Bus.

Ajout d'un schéma Service Bus pour Microsoft.Web.Administration

Microsoft AppFabric utilise les API MWA (Microsoft.Web.Administration) pour lire et écrire le schéma de configuration. Les API MWA utilisent les schémas stockés dans %SystemRoot%\System32\inetsrv\config\schema. Dans la mesure où le fichier Web.config pour le service dans cet exemple contient une configuration de points de terminaison personnalisé pour les liaisons Service Bus, vous devez ajouter le schéma MWA pour les points de terminaison Service Bus (lien vers ServiceBus_schema.xml) et les placer dans le dossier de schéma MWA mentionné précédemment. MWA sélectionne automatiquement le schéma et analyse correctement la configuration spécifique à Service Bus.

Configuration du démarrage automatique

La fonction de démarrage automatique de Microsoft AppFabric pour les services WCF et WF s'appuie sur la fonction de démarrage automatique d'ASP.NET 4. Elle permet au service de démarrer automatiquement lorsque IIS est redémarré ou si le pool d'applications subit un recyclage.

Dans IIS Manager, sélectionnez l'application (dans cet exemple, WebHttpService) et cliquez sur Configurer… sous la section Gérer les services WCF et WF du volet Actions sur le côté droit.

HostingWCFServices2

Cette sélection affiche la boîte de dialogue Configurer WCF et WF pour l'application. Cliquez sur Démarrage automatique dans le menu de gauche, puis cliquez sur Activé (tous les services seront démarrés automatiquement). Cliquez sur Oui pour définir le startMode sur AlwaysRunning pour le pool d'applications.

HostingWCFServices3

Récupération après un incident à l'aide d'une fabrique d'hôte de service personnalisé

Pour la récupération automatique et la recréation de l'objet hôte dans un scénario de panne, utilisez le modèle de fabrique d'hôte de service personnalisé de WCF mentionné dans la section Utilisation d'une fabrique d'hôte de service personnalisé pour la récupération après incident. L'utilisation du modèle de fabrique d'hôte de service personnalisé de WCF est obligatoire pour les services WCF avec des points de terminaison Service Bus qui sont hébergés sur Microsoft AppFabric.

Résumé

Windows Azure Service Bus prend en charge les liaisons pour sa fonctionnalité de messagerie et relais, ce qui facilite l'accès à Service Bus dans le cloud à partir des services WCF. Cet article documente un ensemble de mises à jour de configuration requises pour l'hébergement de tels services WCF sur IIS. Cet article décrit également l'utilisation du modèle WCF de fabrique d'hôte de service personnalisé qui est nécessaire pour la récupération automatique à la suite de pannes.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft