Choix d'options de communication dans .NET

Avec l'introduction de .NET Framework 3.0 et de Windows Communication Foundation (WCF), diverses technologies ont été réunies dans un modèle de programmation unifié. WCF représente la prochaine version d'Enterprise Services, des services Web ASMX, de WSE, de MSMQ et de .NET Remoting. La rubrique suivante s'applique au .NET Framework 2.0. Pour plus d'informations sur WCF et à .NET Framework 3.0, consultez : Windows Communication Foundation (page pouvant être en anglais).

Le .NETFramework fournit plusieurs moyens de communiquer avec des objets situés dans différents domaines d'application et chacun a été conçu pour nécessiter un niveau d'expertise différent et offrir plus ou moins de flexibilité. Par exemple, grâce à la croissance de l'Internet, les services Web XML sont devenus une méthode de communication intéressante, car ils sont construits sur l'infrastructure commune du protocole HTTP et du formatage SOAP, qui fait lui-même appel au XML. Il s'agit de standards publics utilisables immédiatement avec les infrastructures Web actuelles, qui ne posent aucun problème lié à des proxys supplémentaires ou aux pare-feux.

Comme de nombreuses applications requièrent des fonctionnalités que les services Web créés à l'aide d'ASP.NET ne prennent pas en charge, certaines applications ne peuvent pas utiliser les services Web ASP.NET. Utilisez la section suivante pour décider quel type d'application distribuée vous souhaitez que votre application prenne en charge.

ASP.NET, Entreprise Services ou .NET Remoting

ASP.NET, Entreprise Services et .NET Remoting sont des implémentations de communication entre processus (IPC). ASP.NET fournit une infrastructure, hébergée par les services Internet (IIS), qui gère les types de base, prend en charge certains protocoles de service Web avancés (en conjonction avec les extensions de service Web (WSE)) et est bien connue des développeurs d'applications Web. Entreprise Services est une implémentation managée de COM+ et donne accès à toute la souplesse et à toute la richesse de l'architecture COM+. .L'accès distant .NET est un système IPC générique et extensible qui peut s'auto-héberger ou être hébergé dans IIS pour développer et déployer des applications distribuées orientées objet. L'architecture de l'accès distant .NET rend possible l'utilisation de protocoles et de formats de transmission personnalisés.

Vous devez choisir un modèle de programmation en fonction de trois critères principaux : les besoins de l'entreprise, les besoins d'intégration et le modèle de programmation dont vous êtes familier. De plus, les critères suivants (répertoriés par ordre de priorité) peuvent vous aider à choisir le type de technologie d'application distribuée qui vous convient :

1. Conditions de sécurité

   Des trois modèles de programmation, Entreprise Services offre le plus grand nombre de fonctionnalités de sécurité et fonctionne dans la plupart des scénarios. IIS est responsable de l'authentification pour ASP.NET et le chiffrement s'effectue grâce à SSL. IIS est utile pour sécuriser des applications à l'échelle Internet. La sécurité de .NET Remoting a été améliorée avec la version la plus récente du .NETFramework. Dans les versions antérieures de .NET Remoting, vous deviez utiliser une application basée sur HTTP hébergée dans IIS pour chiffrer vos appels ou authentifier votre client, que ce soit une application ASP.NET ou une application distante. Dans sa version actuelle, le TcpChannel et le HttpChannel prennent en charge le chiffrement SSPI et l'Authentification intégrée à Windows. Le IpcChannel prend également en charge l'authentification Windows et le paramétrage direct de la liste de contrôle d'accès (ACL) sur le canal nommé. Comme il n'est pas recommandé d'utiliser des objets distants sur Internet, peu de scénarios requièrent HttpChannel. Si vous devez communiquer sur Internet, il est recommandé d'utiliser ASP.NET pour créer des services Web XML.

   Remarque :
   Pour des raisons de sécurité, il est fortement recommandé de rendre les points de terminaison de l'accès distant disponibles via des canaux sécurisés. N'affichez jamais des points de terminaison d'accès distant non sécurisés sur Internet.

2. Interopérabilité

   Si vous devez interopérer entre différents systèmes d'exploitation, utilisez des services Web XML créés par ASP.NET. Les fichiers ASP.NET vous offrent bien plus de souplesse dans la définition de la forme et du style des communications SOAP que .NET Remoting. Cette souplesse rend plus aisée l'interopérabilité entre différentes plateformes et différents clients. .NET Remoting n'est pas prévu pour interagir avec d'autres plateformes que .NET.

   L'accès distant du .NETFramework n'est pas destiné à une interopérabilité avec les services Web. Pour plus d'informations sur le choix entre les services Web et l'accès distant, consultez « Comment choisir entre services Web, accès distant et Entreprise Services » dans Meilleures pratiques en matière de performances en un coup d'œil et Guide pour choisir entre services Web, Enterprise Services, et .NET Remoting.

3. Vitesse

   Si la vitesse est pour vous un facteur important, Entreprise Services offre les meilleures performances pour les applications distribuées. Il existe très peu de différence de performance entre les fichiers .NET Remoting et ASP.NET une fois qu'une application requiert un traitement réel. Si vous utilisez .NET Remoting, le TcpChannel en conjonction avec BinaryFormatter offre les meilleures performances dans un environnement comptant plusieurs ordinateurs. Sur le même ordinateur, utilisez le IpcChannel en conjonction avec le BinaryFormatter.

4. Évolutivité

   L'hébergement de votre application dans IIS vous donne l'évolutivité dont vous avez besoin. L'auto-hébergement de .NET Remoting nécessite la génération de votre propre infrastructure d'évolutivité. Si vous envisagez d'utiliser IIS avec .NET Remoting pour gagner en évolutivité, nous vous conseillons plutôt d'utiliser les services Web créés à l'aide d'ASP.NET.

5. Utilisation des fonctionnalités de common language runtime

   Entreprise Services et .NET Remoting sont plus efficaces avec les clients .NET. Vous pouvez ainsi utiliser dans votre application les fonctionnalités de .NET qui sont non disponibles pour un service Web XML créé à l'aide d'ASP.NET, dont :

   • Interfaces.

   • CallContext.

   • Propriétés.

   • Indexeurs.

   • C++.

   • Respect des types entre les applications client et serveur.

   Si ces fonctionnalités sont importantes pour vous, choisissez si possible en priorité Entreprise Services, puis .NET Remoting.

6. Conception d'applications orientées objet

   Entreprise Services et .NET Remoting sont des objets et peuvent être traités comme tels. En conséquence, vous pouvez utiliser les fonctionnalités orientées objet suivantes, non disponibles pour ASP.NET, dans votre application.

   • Références d'objet aux objets distants.

   • Plusieurs options d'activation d'objet.

   • Gestion d'état orientée objet.

   • Gestion de la durée de vie d'un objet distribué.

   Si ces fonctionnalités sont importantes pour vous, choisissez si possible en priorité Entreprise Services, puis .NET Remoting.

7. Transports et formats de transmission personnalisés

   Si vous devez prendre en charge des transports personnalisés (par exemple, le protocole UDP (User Datagram Protocol)) ou des formats de transmission personnalisés (par exemple, CSV), .NET Remoting est la seule architecture enfichable qui répond à ces spécifications.

8. Communications de domaines d'applications croisées

   Si vous devez prendre en charge dans le même processus la communication entre des objets situés dans des domaines d'application différents, vous devez utiliser .NET Remoting.

Les sections suivantes incluent un bref résumé de quelques-unes des différences entre les services Web XML créés à l'aide d'ASP.NET, l'espace de noms System.Net, Entreprise Services et .NET Remoting.

services Web XML

Les services Web XML créés à l'aide d'ASP.NET fonctionnent bien si vous générez des applications Active Server Pages (ASP) en utilisant le modèle d'application Web et le runtime ASP.NET HTTP, et sont très bien pris en charge dans Microsoft Visual Studio .NET. Avec l'infrastructure des services Web XML, vous pouvez créer facilement des composants pour d'autres applications ou utiliser des composants que d'autres applications ont créés en utilisant les protocoles, les formats et les types de données les plus appropriés pour les applications Web. Le respect exact des types entre les ordinateurs n'est pas pris en charge, et seuls quelques types d'arguments peuvent être passés. Pour plus d'informations, consultez Création de services Web XML à l'aide de clients de service Web XML et ASP.NET.

Espace de noms System.Net

Vous pouvez utiliser les classes de l'espace de noms System.Net pour générer une structure de communication entière à partir du niveau de 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 enficher dans l'architecture d'accès distant. Pour plus d'informations, consultez Network Programming.

Enterprise Services

Entreprise Services utilise l'infrastructure d'accès distant .NET pour offrir toute la richesse et la souplesse du modèle d'objet distribué COM+, y compris la prise en charge des transactions distribuées à grande échelle.

.NET Remoting

.NET Remoting fournit des outils pour un grand nombre de scénarios de communication complets qui incluent des services Web XML. Grâce à .NET Remoting, vous pouvez :

• Publier ou accéder à des services dans tout type de domaine d'application, qu'il s'agisse d'une application console, de Windows Form, d'IIS, d'un service Web XML ou d'un service Windows.

• Conserver le respect du système de type du code complètement managé dans les communications sous forme binaire, avec prise en charge des types génériques.

  Remarque :
  Les services Web XML utilisent la mise en forme SOAP, qui ne conserve pas tous les détails de type.

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

• Bénéficier d'un contrôle direct sur les caractéristiques d'activation et la durée de vie des objets.

• Implémenter et utiliser des canaux des protocoles tiers pour étendre les communications et répondre à vos besoins particuliers.

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

Voir aussi

Autres ressources

.Accès distant .NET
Vue d'ensemble de l'accès distant .NET Framework
Exemples d'accès distant
Accès distant avancé
Windows Communication Foundation

Copyright ©2007 par Microsoft Corporation. Tous droits réservés.