Partager via

Choix des options de communication dans .NET

  • Article

Le .NET Framework fournit plusieurs manières de communiquer avec des objets dans différents domaines d'application, chacun ayant été conçu en tenant compte d'un niveau particulier de compétence et de souplesse. Par exemple, le développement d'Internet a fait des services Web XML une méthode attrayante de communication car ces services reposent sur l'infrastructure répandue du protocole HTTP et du format SOAP qui utilise XML. Ce sont des normes publiques qui peuvent être utilisées immédiatement avec les infrastructures Web existantes sans se préoccuper des questions de pare-feu ou de proxy supplémentaires.

Cependant, toutes les applications ne doivent pas être générées à l'aide d'une forme de service Web XML, ne serait-ce que pour les raisons de performances qui tiennent à l'utilisation de la sérialisation SOAP sur une connexion HTTP. Utilisez cette section pour vous aider à décider de la forme de communication inter-objet souhaitée pour votre application.

ASP.NET ou Remoting ?

ASP.NET et .NET Remoting sont des implémentations de communication entre processus. ASP.NET fournit une infrastructure hébergée par IIS (Internet Information Services) qui gère bien les types de base et qui est connue des développeurs d'applications Web. .NET Remoting est un système de communication entre processus, générique et extensible que vous pouvez utiliser pour créer des services Web XML hébergés dans IIS (qui disposent tous de la sécurité, de l'évolutivité ainsi que de l'état de session et d'application de ASP.NET et IIS) ou des applications utilisant n'importe quel autre type de protocole de communication ou de format de sérialisation.

Le type de communication dont vous avez besoin et le modèle de programmation qui vous est familier sont les deux critères principaux qui doivent guider votre choix entre ces deux modèles de programmation. Vous devez choisir le type de communication entre processus et le modèle de programmation vous permettant d'implémenter le plus facilement vos décisions. Voici quelques critères (par ordre de priorité) pour choisir le type de communication entre processus dont vous avez besoin, ainsi qu'une comparaison entre les services Web XML créés avec ASP.NET et les services Web XML créés avec .NET Remoting :

  1. Besoins de sécurité

    Si vous devez crypter vos appels ou authentifier votre client, il vous faut utiliser une application HTTP hébergée dans IIS, qu'il s'agisse d'une application ASP.NET ou d'une application distante. En effet, ASP.NET et .NET Remoting utilisent les services de sécurité fournis par IIS. .NET Remoting ne fournit aucun service de sécurité lorsqu'il est hébergé en dehors de IIS (par exemple, dans un service Windows). Même si vous pouvez utiliser .NET Remoting dans n'importe quel domaine d'application (contrairement aux services Web XML créés avec ASP.NET, qui doivent être hébergés dans IIS), vous devez fournir les fonctionnalités de sécurité dont vous avez besoin lorsque vous utilisez .NET Remoting en dehors de IIS. Vous n'êtes pas obligé d'utiliser le format de codage SOAP lors de l'utilisation d'une connexion HTTP ; vous pouvez utiliser le codage binaire pour augmenter la vitesse.

  2. Vitesse.

    .NET Remoting possède un avantage de performances éventuel par rapport aux services Web XML créés avec ASP.NET car il vous offre la possibilité d'utiliser un codage binaire et le canal par défaut TcpChannel, qui offre les meilleures performances de communication entre processus. Vous pouvez spécifier un codage binaire même si vous n'utilisez pas le canal par défaut TcpChannel en utilisant le formateur binaire avec la classe HttpChannel qui utilise la communication POST avec IIS (ou n'importe quelle application d'écoute HttpChannel à distance). L'utilisation d'un format binaire augmente à lui seul nettement les performances des appels dans l'accès distant, même si vous utilisez HttpChannel. Si la sécurité ne constitue pas un problème (par exemple, si vous créez une petite application qui s'exécute entièrement à l'intérieur d'un pare-feu), le canal par défaut TcpChannel avec un format binaire offre de meilleures performances. Les services Web XML créés avec ASP.NET utilisent toujours l'encodage SOAP, dont les performances sont généralement moins bonnes que celles de l'encodage binaire. Cependant, dans les situations où les fonctionnalités de .NET Remoting ne sont pas nécessaires, mais où le protocole HTTP et les messages SOAP sont requis, les services Web XML créés avec ASP.NET offrent de meilleures performances.

  3. Interopération.

    Si vous devez interagir entre différents systèmes d'exploitation, vous ferez généralement appel au protocole de format SOAP, que vous utilisiez .NET Remoting ou ASP.NET. Les services Web XML créés avec ASP.NET vous offrent une souplesse beaucoup plus importante que .NET Remoting pour définir la forme et le style de communication SOAP. Cela peut faciliter l'interopération avec différentes plates-formes et différents clients. .NET Remoting est optimisé pour une communication avec des clients .NET, mais vous pouvez interagir entre différents systèmes d'exploitation à l'aide d'une application distante.

  4. Évolutivité.

    L'hébergement de votre application à l'intérieur de IIS vous donne l'évolutivité dont vous avez besoin, que vous utilisiez .NET Remoting ou ASP.NET.

  5. Utilisation des fonctionnalités du Common Language Runtime.

    Étant donné que .NET Remoting peut tirer un meilleur parti des clients .NET, vous pouvez utiliser des fonctionnalités .NET dans une application distante qui ne sont pas accessibles à un service Web XML créé avec ASP.NET. Ces fonctionnalités sont entre autre :

    • les interfaces ;
    • CallContext ;
    • les propriétés ;
    • les indexeurs ;
    • les extensions managées pour C++ ;
    • le respect des types entre les applications clientes et serveur ;
    • les délégués.

  6. Design d'application orientée objet.

    Les services Web XML créés avec ASP.NET ne représentent pas un paradigme de design orienté objet. Ce sont essentiellement des ressources Web sans état, comme des pages Web, même si l'infrastructure ASP.NET et IIS fournissent des services d'état. Les objets .NET Remoting peuvent être traités comme d'autres objets. Vous pouvez donc utiliser les fonctionnalités .NET orientées objet suivantes, dont ASP.NET ne dispose pas :

    • Références d'objets à des objets distants.
    • Plusieurs options d'activation d'objets.
    • Gestion d'états orientée objet.
    • Gestion distribuée de la durée de vie des objets.

Ce qui suit est un bref résumé de certaines différences entre les services Web XML créés avec ASP.NET, l'espace de noms System.Net et .NET Remoting.

Services Web XML

Si vous créez des applications ASP à l'aide du modèle d'application Web et que vous disposez de la puissance du runtime HTTP ASP.NET (y compris une forte prise en charge dans Microsoft Visual Studio. NET), les services Web XML créés avec ASP.NET conviennent à vos besoins. Avec l'infrastructure des services Web XML, vous pouvez créer facilement des composants pour une utilisation par d'autres applications, ou utiliser des composants tiers qui utilisent les protocoles, les formats et les types de données les plus appropriés aux applications Web. Le respect exact des types entre des ordinateurs n'est pas pris en charge et seuls certains types d'arguments peuvent être passés. Pour plus d'informations, consultez Services Web XML créés à l'aide de clients de service Web XML et d'ASP.NET.

Espace de noms System.Net

Vous pouvez utiliser les classes dans l'espace de noms System.Net pour générer de toutes pièces une structure complète de communication. Vous pouvez également utiliser les classes System.Net pour implémenter des protocoles de communication et des formats de sérialisation que vous pouvez intégrer à l'architecture distante. Pour plus d'informations, consultez Accès à Internet.

.Net Remoting

.NET Remoting fournit les outils pour un nombre illimité de scénarios de communication complets comprenant, entre autres, les services Web XML. À l'aide de .NET Remoting, vous pouvez effectuer l'une des actions suivantes :

  • Publier ou consommer des services dans n'importe quel type de domaine d'application, que ce domaine soit une application de console, un Windows Form, des services IIS (Internet Information Services), un service Web XML, ou un service Windows.

  • Conserver le respect complet des types système de code managé dans les communications au format binaire.

    Remarque   Les services Web XML utilisent le format SOAP qui ne conserve pas toutes les informations de type.

  • Passer des objets par référence et retourner à un objet particulier dans un domaine d'application particulier.

  • Contrôler directement les caractéristiques d'activation et les durées de vie des objets.

  • Implémenter et utiliser des canaux ou des protocoles tiers pour étendre la communication afin de répondre à vos besoins spécifiques.

  • Participer directement au processus de communication pour créer les fonctionnalités dont vous avez besoin.

Voir aussi

Accès aux objets dans d'autres domaines d'application à l'aide de .NET Remoting | Vue d'ensemble de .NET Remoting | Exemples d'accès distant | Accès distant avancé