Services WCF et pare-feu ... Des problèmes?

Problème simple. Je travaille sur une preuve de concept pour une application avec une connexion de base de données supplémentaire, donc je vais créer un service WCF pour faire le tour de la base de données. Les environnements multi-utilisateurs vont obtenir ce service installé sur un serveur centralisé avec une application client sur leur système local. Ces utilisateurs devront automatiquement gérer les problèmes de pare-feu, ce qui est acceptable.Services WCF et pare-feu ... Des problèmes?

Toutefois, dans les environnements mono-utilisateur, le service et l'application client s'exécuteront sur un seul système. L'hôte du service n'a pas de forme définitive pour le moment, mais il est probable qu'il sera hébergé dans l'application elle-même ou en tant que service Windows.

Malheureusement, l'application cliente est une application WIN32 Delphi qui nécessite un moyen simple d'accéder au service. De préférence, la version mono-utilisateur doit utiliser la même technique pour accéder au serveur que la version multi-utilisateur, ce qui signifie qu'elle se comporte comme un client SOAP, avec un fichier WSDL importé et converti en code Delphi.

Toujours pas un problème, mais je dois considérer les problèmes possibles que nous pouvons rencontrer dans cette configuration, avec le problème le plus important: pare-feu possible qui a fermé le port de connexion. Par conséquent, est-ce que quelqu'un est au courant des problèmes de pare-feu qui peuvent survenir dans cet environnement mono-utilisateur?

Source

2009-12-10 Wim ten Brink

Vous n'avez pas mentionné le canal WCF que vous utilisez. Je suppose que basicHttpBinding. Généralement, si votre service local est lié à 127.0.0.1 en utilisant l'auto-hébergement, et que le client sur site l'accède de cette façon, cela devrait aller. Aucun pare-feu à ma connaissance ne vissera avec votre adaptateur loopback. Si vous liez le service à l'adresse IP de la machine, vous pouvez vous soumettre au pare-feu.

Si vous avez WCF 3.5 disponible sur le client sur les deux extrémités (désolé, je ne sais rien à propos de Delphi), allez-y avec netNamedPipeBinding.

Source

2009-12-10 09:39:45 nitzmahone

Nous pouvons fondamentalement utiliser n'importe quel canal WCF, mais Delphi aime se connecter à une sorte de liaison HTTP. C'est toujours une preuve de concept, donc d'autres alternatives sont encore ouvertes. –

Ajouté netNamedPipeBinding comme la meilleure option pour les choses locales seulement - pas sûr si par "Win32" Delphi vous voulez dire non.NET, ma connaissance Delphi est zilch. – nitzmahone

Oui, Delphi est non-NET ce qui limite un peu mes options. Avec une solution de pipe nommée, j'aurai beaucoup à découvrir sur la façon de construire un client pipe nommé. J'ai de l'expérience avec les pipes nommés, je ne sais pas comment .NET enverra les données. Donc, pour le POC, une solution HTTP plus basique est préférée ... –

Vous n'avez pas mentionné la version de Delphi que vous utilisez mais j'ai eu du mal à faire en sorte que Delphi 2005 importe un service WCF avec basicHttpBinding. Comme le WSDL est divisé en plusieurs pages, l'assistant d'importation SOAP dans Delphi n'était pas capable de le comprendre. J'ai finalement fini par écrire un wrapper ASMX autour du service WCF pour les clients Delphi.

Source

2009-12-10 09:51:15

J'ai utilisé la balise Delphi 2007. :-) Le service lui-même sera simple, car nous n'utiliserons aucune classe complexe pour ce projet. (Seuls les types de données de base et certaines données seront transmis en tant que chaînes XML.) Le service est un wrapper autour d'un simple magasin de données. Delphi 2007 fait également un meilleur travail à l'importation. WSDL .NET. Cela a été amélioré. –

Services WCF et pare-feu ... Des problèmes?

Répondre

Questions connexes