Partager via

Considérations relatives à la publication de services WCF à l'aide des adaptateurs de réception WCF

  • Article

Cette rubrique fournit des informations à prendre en compte lors de la publication des services WCF à l'aide des adaptateurs de réception WCF. La publication d'un service à l'aide d'un adaptateur WCF permet son appel par un client WCF comme s'il s'agissait d'un service WCF classique.

Hébergement in-process

L’hébergement de l’emplacement de réception dans l’espace de processus BizTalk Server, btsntsvc.exe, offre les avantages d’un développement et d’un déploiement simplifiés. En outre, il crée plus d’instances hôtes que l’hébergement dans IIS pour tirer parti des fonctionnalités de haute disponibilité et d’équilibrage de charge de BizTalk Server. Pour plus d’informations sur l’hébergement en dehors du processus de BizTalk Server dans IIS, consultez Configuration d’IIS pour les adaptateurs de réception WCF isolés.

Définition sur false de la propriété IsOneWay des services WCF publiés à l'aide des adaptateurs WCF (à l'exception de l'adaptateur de réception WCF-NetMsmq)

La propriété System.ServiceModel.OperationContractAttribute.IsOneWay des services WCF publiés avec les adaptateurs WCF, à l’exception des services publiés avec l’adaptateur de réception WCF-NetMsmq où il est défini sur true , est définie sur false même pour les emplacements de réception unidirectionnel. Si la propriété IsOneWay a la valeur false, même les méthodes qui retournent un void entraînent un message de réponse. Dans ce cas, l'infrastructure crée et envoie un message vide pour indiquer à l'appelant que la méthode a été retournée. Grâce à cette approche, l'infrastructure peut renvoyer au client des exceptions générées par l'opération du service.

Pour utiliser les services WCF publiés avec les adaptateurs WCF (à l’exception de l’adaptateur de réception WCF-NetMsmq) dans lesquels IsOneWay a la valeur false, la propriété IsOneWay côté client doit être définie sur false comme suit :

[ServiceContract(Namespace="Microsoft.WCF.Documentation")]
  public interface ISampleService{
    [OperationContract(IsOneWay=false, ReplyAction="*",Action="…"]
    string SampleMethod(string msg);
}

Notes

Étant donné que la valeur par défaut de la propriété IsOneWay est false, vous n’avez pas besoin de spécifier la propriété dans le code.

La propriété ReplyAction de OperationContractAttribute côté client doit être définie sur « * » (astérisque) lors de l'utilisation de services WCF publiés à l'aide d'emplacements de réception unidirectionnels

La propriété System.ServiceModel.OperationContractAttribute.ReplyAction de System.ServiceModel.OperationContractAttribute peut être utilisée côté client pour spécifier la valeur de l’action SOAP pour les messages de réponse des services WCF.

En plus d'attribuer une valeur particulière à l'en-tête d'action du message de réponse (pour informer le client qu'il s'agit d'une réponse et lui indiquer l'action à effectuer), vous pouvez spécifier la chaîne « * » (astérisque). Dans une application cliente, cet astérisque permet de demander au client de ne pas valider l'action de réponse dans les messages de réponse envoyés par le service.

Pour utiliser un service WCF publié par un emplacement de réception unidirectionnel, la méthode proxy pour le service WCF doit retourner void, auquel cas la méthode proxy s’attend à ce que le service WCF envoie un message vide pour indiquer à l’appelant que la méthode a retourné. Pour que la méthode proxy reçoive ce message vide, la propriété ReplyAction de OperationContractAttribute doit être définie sur « * » (un astérisque) comme suit :

[ServiceContract(Namespace="Microsoft.WCF.Documentation")]
  public interface ISampleService{
    [OperationContract(IsOneWay=false, ReplyAction="*",Action="…"]
    string SampleMethod(string msg);
}

Notes

Vous n’avez pas besoin de définir la propriété ReplyAction sur « * » (un astérisque) pour l’adaptateur WCF-NetMsmq, car l’adaptateur WCF-NetMsmq nécessite que les clients WCF définissent la propriété IsOneWay sur true.

Une instance d'hôte isolé ne peut exécuter qu'un seul adaptateur

Une instance d'hôte isolé ne peut exécuter qu'un seul adaptateur. Si vous configurez les gestionnaires de réception de plusieurs adaptateurs isolés, tels que des adaptateurs HTTP, SOAP et WCF, avec un seul hôte isolé, vous devez créer plusieurs pools d'applications, soit un pool d'applications par adaptateur. Pour plus d’informations sur les hôtes isolés BizTalk, consultez Activation des services web.

Utilisation de l'option « Modèle -- contenu spécifié par le modèle » lors de l'envoi de contenu non-XML en tant que messages de réponse

Les adaptateurs WCF avec corps - l’option Corps du message de réponse BizTalk (valeur par défaut) n’autorisent pas l’envoi de messages non XML tels que des données de caractères et des images bitmap. Vous pouvez utiliser l’option Modèle -- contenu spécifié par le modèle pour que les adaptateurs WCF envoient des messages non XML. Pour plus d’informations sur l’utilisation du modèle, consultez Spécification du corps du message pour les adaptateurs WCF.

Configuration des autorisations pour un service WCF publié à l'aide de l'Assistant Publication de services WCF

Lors de l’utilisation d’applications ASP.NET créées avec l’Assistant Publication de service WCF sur la plateforme Windows Server 2008 SP2 ou Windows Server 2008 R2, des erreurs liées à l’accès aux DLL pendant l’appel du service WCF peuvent se produire. Ces erreurs sont généralement liées à des problèmes de sécurité windows Server 2008 SP2 et Windows Server 2008 R2 par défaut. Pour plus d’informations sur ces erreurs, consultez l’article Aide et support Microsoft intitulé « Vous recevez une erreur « System.IO.FileNotFoundException » lorsque l’application cliente appelle un service web » sur le site Web d’aide et de support à l’adresse https://go.microsoft.com/fwlink/?LinkId=43659.

BizTalk Server nécessite que le processus exécutant le service WCF dispose des autorisations appropriées, qu’un hôte in-process ou un hôte isolé exécute le service. Sous Windows Server 2008 SP2 et Windows Server 2008 R2, le groupe Windows par défaut pour les hôtes isolés est le groupe Utilisateurs de l’hôte isolé. Par conséquent, l’ajout des autorisations au groupe Utilisateurs hôtes isolés doit résoudre ce problème.

Pour ajouter les autorisations au Groupe d'utilisateurs d'hôtes isolés

  1. Dans l'Explorateur Microsoft Windows, localisez le répertoire % windir%\temp.

  2. Cliquez avec le bouton droit sur %windir%\temp, puis cliquez sur Propriétés.

  3. Dans la boîte de dialogue Propriétés, cliquez sur l’onglet Sécurité.

  4. Cliquez sur Ajouter, sélectionnez le groupe Utilisateurs hôtes isolés, puis cliquez sur OK.

Configuration des autorisations pour un emplacement de réception WCF à l'aide de l'adaptateur WCF-NetMsmq

Lorsqu'un client WCF utilisant NetMsmqBinding envoie un message à un service WCF publié à l'aide de l'adaptateur WCF-NetMsmq, il adresse le message à la file d'attente cible, qui est la file d'attente gérée par le gestionnaire de files d'attente du service. Le gestionnaire de files d'attente sur le client envoie le message à une file d'attente de transmission (ou sortante). La file d'attente de transmission est une file d'attente, située sur le gestionnaire de files d'attente côté client, qui stocke des messages pour les transmettre à la file d'attente cible.

Le gestionnaire de files d'attente du service accepte des messages adressés aux files d'attente cibles qu'il possède et stocke les messages. Ensuite, le service lance des demandes de lecture à partir de la file d'attente cible. Le gestionnaire de files d'attente livre alors les messages au service. C'est la raison pour laquelle le compte de service pour l'instance d'hôte BizTalk hébergeant l'emplacement de réception doit disposer des autorisations de lecture à partir de la file d'attente cible.

Utilisation d'une expression de chemin de corps vide pour recevoir un message SOAP contenant des données de type caractère dans l'élément SOAP Body

Pour qu’un adaptateur de réception WCF crée un message BizTalk à partir d’un message de réponse entrant avec des données caractères dans le contenu de l’élément SOAP Body , comme illustré dans l’exemple suivant, vous devez laisser la zone de texte Expression du chemin d’accès au corps vide sous l’onglet Message de la boîte de dialogue Propriétés de transport de l’adaptateur WCF.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
      ...
    </s:Header>
    <s:Body>Contoso</s:Body>
</s:Envelope>

Si vous sélectionnez l’option Enveloppe ou Corps , l’adaptateur ne peut pas créer le message BizTalk à partir du message entrant précédent. Le message n'est pas interrompu car les messages échouant au cours du traitement de marshaling SOAP entrant ne sont pas interrompus. Pour plus d’informations sur l’utilisation de l’expression de chemin du corps sous l’onglet Message , consultez Spécification du corps du message pour les adaptateurs WCF.

Notes

Vous pouvez utiliser l'outil TraceViewer (SvcTraceViewer.exe) du Kit de développement Windows SDK en configurant le fichier BTSNTSvc.exe.config. Pour plus d’informations sur le Kit de développement logiciel (SDK) Windows, consultez « Nouveautés du Kit de développement logiciel (SDK) Windows » à l’adresse https://go.microsoft.com/fwlink/?LinkId=75219. Pour plus d’informations sur l’outil TraceViewer, consultez « Outil TraceViewer (SvcTraceViewer.exe) » à l’adresse https://go.microsoft.com/fwlink/?LinkId=75218.

Utilisation des schémas faisant référence à d'autres schémas

Vous pouvez utiliser les éléments redéfinir, inclure et importer lorsque vos schémas deviennent volumineux et complexes, ou lorsque les schémas qui représentent vos différents types de messages instance ont certaines parties en commun. Il peut être utile de combiner des schémas plus petits en des schémas qui définiront la structure finale des messages d'instance que vous prévoyez d'échanger avec des partenaires commerciaux. Vous pouvez publier ces schémas sous la forme de services WCF à l'aide de l'Assistant Publication de services WCF BizTalk.

Vous devez utiliser l'Assistant Consommation de service WCF BizTalk pour créer les artefacts de BizTalk nécessaires à l'utilisation des services WCF à partir d'un projet BizTalk. Si vous voulez utiliser les services WCF à partir d'une application .NET, vous devez utiliser l'outil Service Model Metadata Utility (Svcutil.exe) pour créer la classe proxy pour les services WCF. Pour plus d’informations sur l’utilisation de schémas qui référencent d’autres schémas, consultez Schémas qui utilisent d’autres schémas et Comment créer des schémas qui utilisent d’autres schémas. Pour plus d’informations sur Svcutil.exe, consultez « Service Model Metadata Utility Tool (Svcutil.exe) » à l’adresse https://go.microsoft.com/fwlink/?LinkID=74696.

Le tableau suivant montre les restrictions et considérations à prendre en compte lors de l'utilisation de services WCF publiés à l'aide de schémas utilisant d'autres schémas.

Élément de schéma XML Utilisation de services WCF publiés à l'aide de l'Assistant Publication de services WCF BizTalk Utilisation de services WCF hébergés par des applications .NET
<import> Prise en charge par l'Assistant Consommation de service WCF BizTalk et Svcutil.exe Prise en charge par l'Assistant Consommation de service WCF BizTalk et Svcutil.exe
<include> Pris en charge avec l’Assistant Consommation de services WCF BizTalk et Svcutil.exe Remarque : Svcutil.exe peut déclencher un message d’avertissement lors de la création de la classe proxy. Pris en charge avec l’Assistant Consommation de services WCF BizTalk et Svcutil.exe Remarque : Svcutil.exe peut déclencher un message d’avertissement lors de la création de la classe proxy.
<redefine> - Pris en charge avec l’Assistant Consommation de services WCF BizTalk
- Prise en charge limitée par Svcutil.exe Remarque : Svcutil.exe a la même limitation pour l’élément redéfinissant que XSD.exe.		 Pris en charge avec l’Assistant Consommation de services WCF BizTalk et Svcutil.exe Remarque : Svcutil.exe peut déclencher un message d’avertissement lors de la création de la classe proxy.

Notes

Svcutil.exe peut déclencher un message d’avertissement lors de la création de la classe proxy sur le service WCF BizTalk publié avec les schémas à l’aide des éléments include et redéfinissez . Par exemple, « L'élément global a déjà été déclaré ».

Vérification qu'un emplacement de réception WCF in-process n'est pas désactivé après la modification du nom de l'ordinateur indiqué dans l'adresse de point de terminaison de son service

Si vous modifiez la partie nom de l’ordinateur dans la zone de texte Adresse (URI) d’un emplacement de réception WCF in-process en cours d’exécution, nous vous recommandons d’utiliser la console Administration BizTalk pour case activée si l’emplacement de réception est toujours en cours d’exécution. Par exemple, si vous modifiez une adresse de point de terminaison de service à l’aide de l’adaptateur de réception WCF-NetTcp, net.tcp ://<Your Computer Name>/samplepath, en net.tcp ://localhost/samplepath, l’emplacement de réception peut être désactivé avec une exception Service.InvalidOperationException. Si vous modifiez uniquement le nom de l'ordinateur indiqué dans l'adresse de point de terminaison de service sans changer le chemin d'accès, assurez-vous que l'emplacement de réception n'est pas désactivé et activez-le si nécessaire.

Définition des options de configuration de la sécurité MSDTC appropriées sur les ordinateurs clients communiquant avec des emplacements de réception WCF distants via un protocole de transaction

Les adaptateurs de réception WCF-NetTcp, WCF-WSHttp et WCF-NetNamedPipe peuvent participer à des processus de coordination transactionnelle que les clients WCF gèrent avec les protocoles de transaction WS-AtomicTransaction et OleTransaction . Les messages peuvent être transmis aux emplacements de réception de destination et supprimés de la base de données MessageBox, dans un contexte transactionnel, à l'aide des protocoles de transaction.

Pour communiquer avec des emplacements de réception WCF distants à l’aide des protocoles de transaction, vous devez configurer de manière appropriée les options de configuration de sécurité MSDTC sur les ordinateurs clients WCF. Le tableau suivant répertorie les valeurs requises pour les options disponibles dans la boîte de dialogue Configuration de la sécurité MSDTC :

Option de configuration Valeur par défaut Valeur recommandée
Accès DTC réseau Désactivé activé
Autoriser les transactions sortantes Désactivé activé
Authentification mutuelle requise activé Activé si les emplacements de réception distants correspondants exécutent Windows Server 2003 SP1 ou SP2 et sont configurés avec l’authentification mutuelle requise.
Autorisation de l'appelant entrant requise Désactivé Activé si MSDTC est exécuté sur un cluster.

Après avoir appliqué ces modifications, vous devez redémarrer le service MSDTC.

Pour accéder à la boîte de dialogue Configuration de la sécurité MSDTC, procédez comme suit :

  1. Cliquez sur Démarrer, sur Exécuter, puis tapez dcomcnfg pour lancer la console gestion des services de composants.

  2. Développez Services de composants, développez Ordinateurs, cliquez avec le bouton droit sur Poste de travail, puis cliquez sur Propriétés.

  3. Dans la boîte de dialogue Propriétés du poste de travail , cliquez sur l’onglet MSDTC , puis sur Configuration de la sécurité pour afficher la boîte de dialogue Configuration de la sécurité .

Wrapper SOAP avec l'Assistant Publication de services WCF BizTalk

Lorsqu’une orchestration est exposée en tant que service Windows Communication Foundation (WCF) à l’aide de l’Assistant Publication du service WCF, un wrapper est généré. Ce wrapper utilise le nom de méthode du port, présent dans le message XML, auquel le message est envoyé. Ce wrapper est la valeur par défaut pour les enveloppes SOAP de Microsoft. Cela permet à WCF d’encapsuler le message SOAP en plusieurs parties dans un message WCF à transmettre au point de terminaison par l’adaptateur.

En guise de bonne pratique, l’expéditeur doit utiliser un wrapper et le récepteur doit s’y attendre, ou l’expéditeur ne doit pas utiliser de wrapper et le récepteur doit s’attendre au message WCF brut. L'absence d'accord préalable sur l'utilisation ou non d'un wrapper peut causer des problèmes d'incompatibilité entre ce qui est envoyé et ce qui est reçu.