Partager via

Adresses de point de terminaison

Chaque point de terminaison a une adresse associée, qui est utilisée pour localiser et identifier le point de terminaison. Cette adresse se compose principalement d’un URI (Uniform Resource Identifier), qui spécifie l’emplacement du point de terminaison. L’adresse du point de terminaison est représentée dans le modèle de programmation Windows Communication Foundation (WCF) par la EndpointAddress classe, qui contient une propriété facultative Identity qui permet l’authentification du point de terminaison par d’autres points de terminaison qui échangent des messages avec lui et un ensemble de propriétés facultatives Headers , qui définissent les autres en-têtes SOAP requis pour atteindre le service. Les en-têtes facultatifs fournissent des informations d’adressage supplémentaires et plus détaillées pour identifier ou interagir avec le point de terminaison de service. L’adresse d’un point de terminaison est représentée sur le câble sous la forme d’une référence de point de terminaison WS-Addressing (EPR).

Structure URI d’une adresse

L’URI d’adresse de la plupart des transports comporte quatre parties. Par exemple, les quatre parties de l’URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint peuvent être détaillées comme suit :

  • Schéma: http:

  • Machine : www.fabrikam.com

  • (facultatif) Port : 322

  • Chemin d’accès : /mathservice.svc/secureEndpoint

Définition d’une adresse pour un service

L’adresse de point de terminaison d’un service peut être spécifiée de manière impérative à l’aide du code ou de manière déclarative par le biais de la configuration. La définition de points de terminaison dans le code n’est généralement pas pratique, car les liaisons et adresses d’un service déployé sont généralement différentes de celles utilisées pendant le développement du service. En règle générale, il est plus pratique de définir des points de terminaison de service à l’aide de la configuration plutôt que du code. La conservation des informations de liaison et d’adressage hors du code leur permet de changer sans avoir à recompiler ou à redéployer l’application.

Définition d’une adresse dans la configuration

Pour définir un point de terminaison dans un fichier de configuration, utilisez l’élément <de point de terminaison> . Pour plus d’informations et un exemple, consultez Spécification d’une adresse de point de terminaison.

Définition d’une adresse dans le code

Une adresse de point de terminaison peut être créée dans le code avec la EndpointAddress classe. Pour plus d’informations et un exemple, consultez Spécification d’une adresse de point de terminaison.

Points de terminaison dans WSDL

Une adresse de point de terminaison peut également être représentée dans WSDL en tant qu’élément EPR WS-Addressing à l’intérieur de l’élément correspondant du point de terminaison wsdl:port. L’EPR contient l’adresse du point de terminaison ainsi que toutes les propriétés d’adresse. Pour plus d’informations et un exemple, consultez Spécification d’une adresse de point de terminaison.

Prise en charge de plusieurs liaisons IIS dans .NET Framework 3.5

Les fournisseurs de services Internet hébergent souvent de nombreuses applications sur le même serveur et le même site pour augmenter la densité du site et réduire le coût total de possession. Ces applications sont généralement liées à différentes adresses de base. Un site web IIS (Internet Information Services) peut contenir plusieurs applications. Les applications d’un site sont accessibles via une ou plusieurs liaisons IIS.

Les liaisons IIS fournissent deux informations : un protocole de liaison et des informations de liaison. Le protocole de liaison définit le schéma sur lequel se produit la communication et les informations de liaison sont les informations utilisées pour accéder au site.

L’exemple suivant montre les composants qui peuvent être présents dans une liaison IIS :

  • Protocole de liaison : HTTP

  • Informations de liaison : adresse IP, port, en-tête d’hôte

IIS peut spécifier plusieurs liaisons pour chaque site, ce qui entraîne plusieurs adresses de base pour chaque schéma. Avant .NET Framework 3.5, WCF ne prenait pas en charge plusieurs adresses pour un schéma et, s’ils étaient spécifiés, lançait une ArgumentException erreur lors de l’activation.

.NET Framework 3.5 permet aux fournisseurs de services Internet d’héberger plusieurs applications avec différentes adresses de base pour le même schéma sur le même site.

Par exemple, un site peut contenir les adresses de base suivantes :

  • http://payroll.myorg.com/Service.svc

  • http://shipping.myorg.com/Service.svc

Avec .NET Framework 3.5, vous spécifiez un filtre de préfixe au niveau AppDomain dans le fichier de configuration. Pour ce faire, utilisez l’élément <baseAddressPrefixFilters> , qui contient une liste de préfixes. Les adresses de base entrantes, fournies par IIS, sont filtrées en fonction de la liste de préfixes facultative. Par défaut, lorsqu’un préfixe n’est pas spécifié, toutes les adresses sont transmises. Si vous spécifiez le préfixe, seule l’adresse de base correspondante pour ce schéma doit être transmise.

Voici un exemple de code de configuration qui utilise les filtres de préfixe.

<system.serviceModel>  
  <serviceHostingEnvironment>  
     <baseAddressPrefixFilters>  
        <add prefix="net.tcp://payroll.myorg.com:8000"/>  
        <add prefix="http://shipping.myorg.com:8000"/>  
    </baseAddressPrefixFilters>  
  </serviceHostingEnvironment>  
</system.serviceModel>

Dans l’exemple précédent, net.tcp://payroll.myorg.com:8000 et http://shipping.myorg.com:8000 sont les seules adresses de base, pour leurs schémas respectifs, qui sont transmis.

Le baseAddressPrefixFilter ne prend pas en charge de caractères génériques.

Les adresses de base fournies par IIS peuvent avoir des adresses liées à d’autres schémas non présents dans la baseAddressPrefixFilters liste. Ces adresses ne sont pas filtrées.

Prise en charge de plusieurs liaisons IIS dans .NET Framework 4 et version ultérieure

À compter de .NET 4, vous pouvez activer la prise en charge de plusieurs liaisons dans IIS sans avoir à choisir une seule adresse de base, en définissant ServiceHostingEnvironmentle MultipleSiteBindingsEnabled paramètre sur true. Cette prise en charge est limitée aux schémas de protocole HTTP.

Voici un exemple de code de configuration qui utilise plusieursSiteBindingsEnabled sur <serviceHostingEnvironment>.

<system.serviceModel>  
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >  
  </serviceHostingEnvironment>  
</system.serviceModel>

Tous les paramètres baseAddressPrefixFilters sont ignorés, pour les protocoles HTTP et non HTTP, lorsque plusieurs liaisons de site sont activées à l’aide de ce paramètre.

Pour obtenir plus d’informations et des exemples, consultez Prise en charge de plusieurs liaisons de site IIS et MultipleSiteBindingsEnabled.

Extension de l’adressage dans les services WCF

Le modèle d’adressage par défaut des services WCF utilise l’URI d’adresse de point de terminaison à des fins suivantes :

  • Pour spécifier l’adresse d’écoute du service, emplacement auquel le point de terminaison écoute les messages,

  • Pour spécifier le filtre d’adresse SOAP, l’adresse qu’un point de terminaison attend comme en-tête SOAP.

Les valeurs de chacune de ces fins peuvent être spécifiées séparément, ce qui permet plusieurs extensions d’adressage qui couvrent des scénarios utiles :

  • Intermédiaires SOAP : un message envoyé par un client traverse un ou plusieurs services supplémentaires qui traitent le message avant qu’il n’atteigne sa destination finale. Les intermédiaires SOAP peuvent effectuer différentes tâches, telles que la mise en cache, le routage, l’équilibrage de charge ou la validation de schéma sur les messages. Ce scénario s’effectue en envoyant des messages à une adresse physique distincte (via) qui cible l’intermédiaire plutôt qu’à une adresse logique (wsa:To) qui cible la destination finale.

  • L’adresse d’écoute du point de terminaison est un URI privé et est définie sur une valeur différente de sa listenURI propriété.

L’adresse de transport spécifiée via est l’emplacement auquel un message doit initialement être envoyé en chemin vers une autre adresse distante spécifiée par le to paramètre où se trouve le service. Dans la plupart des scénarios Internet, l’URI via est identique à la Uri propriété de l’adresse finale to du service. Vous ne faites que la distinction entre ces deux adresses lorsque vous devez effectuer un routage manuel.

En-têtes d'adressage

Un point de terminaison peut être traité par un ou plusieurs en-têtes SOAP en plus de son URI de base. Un ensemble de scénarios où cela est utile est un ensemble de scénarios intermédiaires SOAP où un point de terminaison exige que les clients de ce point de terminaison incluent des en-têtes SOAP ciblés sur les intermédiaires.

Vous pouvez définir des en-têtes d’adresse personnalisés de deux manières : à l’aide de code ou de configuration :

La configuration est généralement préférable au code, car elle vous permet de modifier les en-têtes après le déploiement.

Adresses d’écoute personnalisées

Vous pouvez définir l’adresse d’écoute sur une valeur différente de l’URI du point de terminaison. Cela est utile dans les scénarios intermédiaires où l’adresse SOAP à exposer est celle d’un intermédiaire SOAP public, tandis que l’adresse où le point de terminaison écoute réellement est une adresse réseau privée.

Vous pouvez spécifier une adresse d’écoute personnalisée à l’aide du code ou de la configuration :

  • Dans le code, spécifiez une adresse d’écoute personnalisée en ajoutant une ClientViaBehavior classe à la collection de comportements du point de terminaison.

  • Dans la configuration, spécifiez une adresse d’écoute personnalisée avec l’attribut ListenUri de l’élément de point de terminaison< de service>.

Filtre d’adresse SOAP personnalisé

Il Uri est utilisé conjointement avec n’importe quelle Headers propriété pour définir le filtre d’adresse SOAP d’un point de terminaison (AddressFilter). Par défaut, ce filtre vérifie qu’un message entrant a un To en-tête de message qui correspond à l’URI du point de terminaison et que tous les en-têtes de point de terminaison requis sont présents dans le message.

Dans certains scénarios, un point de terminaison reçoit tous les messages qui arrivent sur le transport sous-jacent, et pas seulement ceux avec l’en-tête approprié To . Pour l’activer, l’utilisateur peut utiliser la MatchAllMessageFilter classe.

Voir aussi

  • Last updated on