Choix des options de communication dans .NET
Le .NET Framework fournit plusieurs manières de communiquer avec des objets dans différents domaines d'application, chacun ayant été conçu avec 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.
Dans la mesure où de nombreuses applications nécessitent une fonctionnalité qui n'est pas prise en charge par les services Web créés à l'aide d'ASP.NET, certaines applications ne peuvent pas utiliser les services Web ASP.NET. Utilisez la section suivante pour vous aider à décider du type de prise en charge des applications distribuées souhaité pour votre application.
ASP.NET, Enterprise Services ou .NET Remoting ?
ASP.NET, Enterprise Services et .NET Remoting sont des implémentations de communication entre processus (IPC, Interprocess Communication). ASP.NET fournit une infrastructure hébergée par IIS (Internet Information Services) qui gère bien les types de base, qui prend en charge certains protocoles avancés de services Web (lorsqu'il est utilisé avec les extensions du service Web (WSE - Web Service Extensions)) et qui est connue des développeurs d'applications Web. Enterprise Services est une implémentation managée de COM+ qui offre toute la souplesse et la richesse de l'architecture COM+. .NET Remoting est un système IPC générique et extensible qui peut être auto-hébergé ou hébergé par IIS pour développer et déployer des applications orientées objet distribuées. L'architecture enfichable de .NET Remoting autorise les formats de transmission et les protocoles personnalisés.
Le choix entre les modèles de programmation doit reposer sur les trois principaux critères suivants : les exigences de l'entreprise, les besoins en intégration et le modèle de programmation que vous connaissez déjà. De plus, les critères suivants (classés par ordre de priorité) peuvent vous aider à choisir le type de technologie d'applications distribuées dont vous avez besoin.
Besoins de sécurité
Des trois modèles de programmation, Enterprise Services est celui qui dispose de l'ensemble de fonctionnalités de sécurité le plus complet et correspondra à la majorité des scénarios. ASP.NET garantit l'authentification via IIS et le chiffrement via SSL et permet de sécuriser des applications Internet. La sécurité de .NET Remoting a été améliorée dans la dernière version de .NET Framework. Dans les versions antérieures de .NET Remoting, si vous deviez chiffrer vos appels ou authentifier votre client, vous deviez utiliser une application HTTP hébergée dans IIS, qu'il s'agisse d'une application ASP.NET ou d'une application distante. Dans la version actuelle, les canaux TcpChannel et HttpChannel prennent en charge le chiffrement SSPI et l'authentification intégrée Windows. Le canal IpcChannel prend également en charge l'authentification Windows et le paramétrage direct de la liste de contrôle d'accès (ACL, Access Control Lists) sur le canal nommé. L'utilisation d'objets distants sur Internet n'étant pas recommandée, les scénarios nécessitant le canal HttpChannel sont désormais rares. Si vous devez communiquer via Internet, il est recommandé d'utiliser ASP.NET pour créer des services Web XML.
Notes
Pour des raisons de sécurité, il est vivement recommandé d'exposer des points d'entrée d'accès distant sur des canaux sécurisés. N'exposez jamais de points d'entrée d'accès distant non sécurisés sur Internet.
Interopérabilité
Si vous devez interagir avec différents systèmes d'exploitation, utilisez les services Web XML créés par ASP.NET. Les fichiers ASP.NET vous offrent beaucoup plus de souplesse beaucoup plus importante que .NET Remoting pour définir la forme et le style de communication SOAP. Cette souplesse peut faciliter l'interopérabilité avec différentes plateformes et différents clients. .NET Remoting n'est pas conçu pour l'interopérabilité avec des plateformes autres que .NET.
.NET Framework Remoting n'est pas conçu pour l'interopérabilité avec des services Web. Pour plus d'informations sur le choix entre les services Web et Remoting, voir l'article "Comment choisir entre les services Web, Remoting et Enterprise Services" dans le document Vue d'ensemble des méthodes conseillées pour les performances, et "Guide pour choisir entre les services Web, Enterprise Services et .NET Remoting" dans Amélioration des performances et de l'évolutivité d'une application .NET.
Vitesse
Si la vitesse constitue un facteur important, Enterprise Services fournit les meilleures performances pour les applications distribuées. La différence de performances est infime entre .NET Remoting et les fichiers ASP.NET une fois qu'une application nécessite un traitement réel. Si vous utilisez .NET Remoting, le canal TcpChannel avec BinaryFormatter permet d'obtenir les meilleures performances entre ordinateurs. Sur le même ordinateur, utilisez le canal IpcChannel avec BinaryFormatter.
Évolutivité
L'hébergement de votre application à l'intérieur d'IIS vous donne l'évolutivité dont vous avez besoin. Si vous optez pour l'auto-hébergement de .NET Remoting, vous devrez créer votre propre infrastructure de mise à l'échelle. Si vous envisagez d'utiliser IIS avec .NET Remoting pour améliorer l'évolutivité, il est préférable d'utiliser plutôt les services Web créés à l'aide d'ASP.NET.
Utilisation des fonctionnalités du Common Language Runtime
Enterprise Services et .NET Remoting tirant un meilleur parti des clients .NET, vous pouvez utiliser les fonctionnalités .NET dans votre application qui ne sont pas accessibles à un service Web XML créé à l'aide d'ASP.NET, notamment :
Interfaces
CallContext
Propriétés
Indexeurs
C++
Respect des types entre les applications clientes et serveur
Si ces fonctionnalités sont critiques, choisissez dans l'ordre Enterprise Services, si possible, puis .NET Remoting.
Conception d'applications orientées objet
Les objets Enterprise Services et .NET Remoting peuvent être traités comme d'autres objets. Vous pouvez donc utiliser les fonctionnalités orientées objet suivantes dans votre application, 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
Si ces fonctionnalités sont critiques, choisissez dans l'ordre Enterprise Services, si possible, puis .NET Remoting.
Transports personnalisés ou formats de transmission Si vous devez prendre en charge des transports personnalisés (UDP (User Datagram Protocol), par exemple) ou des formats de transmission personnalisés (CSV, par exemple), .NET Remoting est la seule architecture enfichable pouvant répondre à ces besoins.
Communications entre domaines d'application Si vous devez prendre en charge la communication entre des objets de domaines d'application différents dans le même processus, vous devez utiliser .NET Remoting.
Les sections suivantes comprennent un bref résumé de certaines différences entre les services Web XML créés à l'aide d'ASP.NET, l'espace de noms System.Net, Enterprise Services et .NET Remoting.
Services Web XML
Les services Web XML créés à l'aide d'ASP.NET fonctionnent bien si vous créez les applications ASP (Active Server Pages) à l'aide du modèle d'application Web et du runtime HTTP ASP.NET, y compris une forte prise en charge dans Microsoft Visual Studio. NET. Avec l'infrastructure des services Web XML, vous pouvez créer facilement des composants pour une utilisation par d'autres applications, ou employer des composants tiers qui utilisent les protocoles, les formats et les types de données les mieux adapté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, voir 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 une structure complète de communication depuis le niveau du socket. 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, voir Programmation réseau.
Enterprise Services
Enterprise Services tire parti de l'infrastructure de .NET Remoting pour offrir toute la souplesse et la richesse du modèle objet distribué COM+, notamment la prise en charge de transactions largement distribuées.
.NET Remoting
.NET Remoting fournit les outils pour un nombre illimité de scénarios de communication complets, y compris les services Web XML. À l'aide de .NET Remoting, vous pouvez :
Publier ou consommer des services dans n'importe quel type de domaine d'application, que ce domaine soit une application console, un Windows Form, un service IIS, 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, y compris la prise en charge des types génériques.
Notes
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
Autres ressources
Objets distants
Vue d'ensemble de .NET Framework Remoting
Exemples d'accès distant
Accès distant avancé