HttpListener vs HttpHandler dilemme

Dans un service Windows, j'ai implémenté un HttpListener qui gère les requêtes HTTP entrantes sur un port donné, analyse la chaîne de requête, l'insère dans la base de données et envoie une réponse de confirmation. Tout fonctionne bien et j'étais plutôt satisfait de ma solution. Cependant, les clients ont dit qu'ils étaient un peu sceptiques et ont demandé si la même chose aurait pu être faite via une page Web. Comme avoir un HTTPHandler écouter un certain port. J'ai réfléchi. Vous feriez quoi dans ma situation?HttpListener vs HttpHandler dilemme

Optez pour le service HttpListener/Windows ou HTTPHandler/.aspx?

Merci beaucoup!

Source

2011-03-31 Dragan

Si personne n'utilise le produit avec une interface web, il n'y a absolument aucun intérêt à exposer un site ASP.NET sur le web - un service implique une exigence de fiabilité, les pages web sont 't _that_. –

Oui, c'est un argument valable et je vais en parler demain. Est-ce que la même chose pourrait être faite par un Web Service? – Dragan

Techniquement, oui, bien sûr; mais pratiquement il n'y a aucun point ou bénéfice (que je connaisse) en l'hébergeant dans IIS à moins qu'il ne réside à côté d'un site Web d'accompagnement - juste un ensemble supplémentaire d'enregistrements quelque part plus apparent dans le système. –

Y a-t-il une raison pour laquelle vous ne voulez pas utiliser un serveur Web? Nous avons implémenté nos propres services de traitement Http car ils sont assez inhabituels dans la façon dont ils traitent les requêtes et se révèlent taxer sur une instance IIS normalement configurée.

Dans votre situation, cela ne semble pas être le cas, alors oui, je me demande pourquoi vous n'êtes pas allé la route du serveur web non plus.

EDIT

est-il une autre face web partie de votre application? Si non, je suis d'accord que le raisonnement de @ Dis Disrignement est solide. Vous n'exposez que ce dont vous avez besoin, ce qui réduit considérablement la surface d'attaque par rapport à une instance IIS.

Source

2011-03-31 14:23:09 spender

le service de gain que j'ai mis en place est simplement une partie d'accompagnement à une boutique en ligne par laquelle les gens peuvent acheter des abonnements aux journaux électroniques. J'utilise le service Windows pour synchroniser notre base de données avec celle de nos clients. Je pensais que ce serait une option réalisable pour installer les services Windows sur notre serveur, ainsi que sur le serveur de notre client (les éditeurs). Je ne vois pas les avantages d'utiliser un service web quand j'ai déjà un service Windows qui utilise le threading. Je suis vraiment intéressé par votre point de vue puisque vous avez 15.4k réputation :) – Dragan

Je pense que c'est un détail d'implémentation. Si la solution est robuste et fonctionne selon les spécifications, il n'y a pas de problème. Les techniciens de serveurs ont tendance à hésiter à installer un logiciel en tant que service car ils perçoivent qu'il est plus difficile de verrouiller/sécuriser un peu de logiciels propriétaires que les logiciels fonctionnant sous IIS. A partir du point de vue d'un développeur, il est plus facile de limiter le fonctionnement d'un service et de garder la mémoire sous un contrôle plus strict. À la fin de la journée, si vous avez livré correctement, c'est probablement une chance d'arracher plus de travail de la transaction s'ils placent une exigence tardive sur le type de livraison. – spender

J'utiliserais quelque chose via IIS, simplement parce que je pense que les équipes informatiques de mes clients auraient besoin d'un argument assez significatif pour que je leur dise d'installer des services personnalisés sur leurs serveurs. Je ne connais pas assez le comportement de threading de HttpListener (utilise-t-il des pools de threads? Nombre maximum de threads? En file d'attente une fois qu'un max a été atteint?), Mais j'imagine que votre client a des préoccupations similaires .

Source

2011-03-31 14:32:00 joelt

Je comprends ce que vous voulez dire, mais nos clients veulent simplement connaître les avantages de l'utilisation d'un service Windows sur .aspx ou winservice. Pour commencer, je me sens très à l'aise de travailler avec la classe HttpListener. BTW vous avez raison à propos de HttpListener en utilisant des pools de threads. Cela réduit considérablement les frais généraux du processeur. Tu ne penses pas? Merci pour votre réponse. Appréciez-le. – Dragan

Le point que @joelt était en train de faire est que IIS vous offre un contrôle plus fin sur le nombre de processus et de threads que vous souhaitez dédier à votre service Web, les demandes de file d'attente, le recyclage, etc. –

HttpListener vs HttpHandler dilemme

Répondre

Questions connexes