Tout le monde a IIS fonctionnant de manière fiable en tant que client WCF

Question

J'essaie de faire fonctionner IIS6 de manière fiable avec un service WCF que j'ai hébergé dans une application Windows Service distincte sur la même machine. Les utilisateurs se connectent à IIS via certains services exposés HTTP, ce qui fonctionne correctement, puis IIS doit obtenir des informations du service Windows pour mettre la réponse HTTP. J'ai également besoin d'un canal de rappel entre le service Windows et IIS. Après beaucoup d'efforts, je l'ai fait fonctionner avec un netTcpBinding et tout serait rosey pendant 5 ou 10 minutes, mais après cela, IIS signalerait le canal WCF comme étant fautif, puis claquer et arrêter le traitement des demandes jusqu'à ce que le travailleur le processus a été recyclé et le tout a été répété.

J'ai essayé de passer à un netNamedPipeBinding mais IIS refuse ou se voit refuser l'accès au canal avec une erreur "Il n'y avait pas d'endpoint d'écoute sur net.pipe: // localhost/mon_nom_nom". Je peux me connecter à la pipe bien à partir d'une application de la console. Donc, ma question est: quelqu'un a-t-il eu l'une ou l'autre de ces deux liaisons avec IIS en tant que client ou avez-vous d'autres approches?

Answer 1

Nous utilisons IIS 7 hébergeant environ 20 services avec les liaisons net.tcp et net.pipe et cela fonctionne très bien.

Votre problème avec le tuyau ressemble à une mauvaise configuration pour moi. Si elle aide, voici comment nous les avons configuré:

Serveur:

<endpoint address ="" binding="fooBinding" 
      contract="Bla.IBlaAPI" 
      bindingConfiguration="BlaAPI.BindingConfig"> 

config Reliure:

<binding name="BlaAPI.BindingConfig" 
       receiveTimeout = "10:50:00" 
       sendTimeout = "10:50:00" 
       maxReceivedMessageSize="2147483647" 
       maxBufferSize="2147483647" 
       maxBufferPoolSize="2147483647" 
       transactionFlow="false"> 
      <readerQuotas maxDepth="32" 
         maxStringContentLength="2147483647" 
         maxArrayLength="2147483647" 
         maxBytesPerRead="8192" 
         maxNameTableCharCount="2147483647" /> 
      <security mode="None"/> 
</binding> 

Notez que nous utilisons de longs délais d'attente et nous avons vraiment élevé des quotas pour la taille des messages, etc. parce que nous passons de gros morceaux de données à travers ce service. Vous pouvez ajuster pour vos propres besoins. La sécurité est définie sur "none" car le service est uniquement en contact avec la machine locale sécurisée. Encore une fois, votre kilométrage peut varier.

Client:

<endpoint name="Bla.Bindings.BlaAPI" address="net.pipe://localhost/bla/IBlaAPI.svc" 
       behaviorConfiguration="BlaAPI.ServiceBehavior" 
       binding="netNamedPipeBinding" bindingConfiguration="BlaAPI.BindingConfig" 
       contract="Bla.IBlaAPI" /> 

A propos du problème de l'état Faulted, s'il vous plaît noter que si une exception non gérée se produit pendant l'exécution du code de service, l'instance de service demeurera en état de défaut jusqu'à ce qu'il soit fermé. Pour éviter cela, gérez les exceptions au niveau supérieur du service ou utilisez, par exemple, les blocs de gestion de l'excexption de la bibliothèque d'entreprise.

Answer 2

Pouvez-vous me montrer le code que vous utilisez pour disposer du proxy client wcf? N'utilisez jamais 'using' sur un proxy wcf, car il ne sera pas éliminé correctement à chaque fois. Cela peut éventuellement conduire à l'état fautif.

Answer 3

Re NetNamedPipeBinding et "Il n'y avait pas à l'écoute point final net.pipe: // localhost/mypipename"

est votre application web empruntez l'identité de ses utilisateurs? L'erreur ci-dessus est ce que vous obtenez si vous essayez d'accéder à un service WCF via la liaison de canal nommé, dans un contexte de sécurité dont le jeton d'ouverture de session est membre de NETWORK USERS. La pile de canaux côté client WCF ne fait pas la distinction entre les erreurs d'accès refusé et les erreurs «introuvables» lorsqu'elle tente de lire l'objet de mémoire partagée créé par le service pour publier le nom du canal en cours d'utilisation.(Voir http://blogs.charteris.com/blogs/chrisdi/archive/2008/05.aspx etc.)

Les jetons d'usurpation d'identité dans une application IIS auront toujours l'appartenance aux utilisateurs du RÉSEAU.