Auswählen von Kommunikationsoptionen in .NET

Mit der Einführung von .NET Framework 3.0 und Windows Communication Foundation (WCF) wurde eine Reihe von verschiedenen Technologien in einem einheitlichen Programmiermodell zusammengefasst. WCF dient als nächste Version von Enterprise Services, ASMX Web Services, WSE, MSMQ und .NET Remoting. Das folgende Thema bezieht sich auf .NET Framework 2.0. Weitere Informationen zu WCF und .NET Framework 3.0 finden Sie unter: Windows Communication Foundation (möglicherweise in englischer Sprache).

.NET Framework bietet mehrere Möglichkeiten für die Kommunikation mit Objekten in verschiedenen Anwendungsdomänen. Jede dieser Möglichkeiten wurde mit Blick auf ein bestimmtes Maß an Fachkenntnis und Flexibilität konzipiert. So wurden z. B. XML-Webdienste durch die Verbreitung des Internets zu einer attraktiven Kommunikationsmethode, weil XML-Webdienste auf der allgemeinen Infrastruktur von HTTP und SOAP-Formatierung basieren, die XML verwendet. Hierbei handelt es sich um öffentliche Standards, die sofort mit aktuellen Webinfrastrukturen genutzt werden können, ohne sich über zusätzliche Proxy- oder Firewallprobleme Gedanken machen zu müssen.

Da viele Anwendungen Funktionen benötigen, die mithilfe von ASP.NET erstellte Webdienste nicht unterstützen, können manche Anwendungen keine ASP.NET-Webdienste verwenden. Entscheiden Sie mithilfe des folgenden Abschnitts, welche Art der Unterstützung für verteilte Anwendungen Sie für Ihre Anwendung benötigen.

ASP.NET, Enterprise Services oder .NET-Remoting

ASP.NET, Enterprise Services und .NET-Remoting sind prozessübergreifende Kommunikationsimplementierungen. ASP.NET stellt eine Infrastruktur bereit, die von Internetinformationsdiensten (Internet Information Services, IIS) gehostet wird. Sie ermöglicht eine gute Behandlung der Basistypen, unterstützt eine Reihe erweiterter Webdienstprotokolle (bei Verwendung mit Web Service Extensions (WSE)) und ist Entwicklern von Webanwendungen vertraut. Enterprise Services sind eine verwaltete Implementierung von COM+, die die gesamte Flexibilität sowie die zahlreichen Möglichkeiten der COM+-Architektur bereitstellen. .NET-Remoting ist ein generisches und erweiterbares IPC-System, das in IIS oder selbst gehostet werden kann, um verteilte, objektorientierte Anwendungen zu entwickeln und bereitzustellen. Die Architektur von .NET-Remoting berücksichtigt benutzerdefinierte Protokolle und Übertragungsformate.

Die Wahl zwischen den verschiedenen Programmiermodellen muss von drei Hauptkriterien bestimmt sein: den Geschäftsanforderungen, den Integrationsanforderungen und dem Programmiermodell, mit dem Sie vertraut sind. Außerdem können die folgenden, nach der Priorität aufgelisteten Kriterien bei der Wahl des geeigneten Technologietyps für verteilte Anwendungen hilfreich sein:

1. Sicherheitsanforderungen

   Von den drei Programmiermodellen bieten die Enterprise Services die umfangreichsten Sicherheitsfeatures, und sie sind in den meisten Szenarien einsetzbar. ASP.NET stellt Authentifizierung durch IIS und Verschlüsselung durch SSL bereit und ist zum Sichern von Anwendungen auf Internetebene nützlich. Die Sicherheit von .NET-Remoting wurde mit der neuesten Version von .NET Framework erhöht. In älteren Versionen von .NET-Remoting mussten Sie, wenn Sie Ihre Aufrufe verschlüsseln oder Ihren Client authentifizieren mussten, eine HTTP-basierte, in IIS gehostete Anwendung verwenden – sei es nun eine ASP.NET-Anwendung oder eine Remoteanwendung. In der aktuellen Version unterstützen TcpChannel und HttpChannel die SSPI-Verschlüsselung und die integrierte Windows-Authentifizierung. IpcChannel unterstützt außerdem die Windows-Authentifizierung und die direkte Einstellung der Zugriffssteuerungsliste (Access Control List, ACL) für die Named Pipe. Da Remoteobjekte besser nicht über das Internet verwendet werden sollten, stehen jetzt einige Szenarien zur Verfügung, die HttpChannel erfordern. Wenn Sie Daten über das Internet austauschen müssen, empfiehlt es sich, ASP.NET zum Erstellen von XML-Webdiensten zu verwenden.

   Hinweis:
   Aus Gründen der Sicherheit wird dringend empfohlen, Remotingendpunkte durch sichere Channels verfügbar zu machen. Zeigen Sie unsichere Remoteendpunkte niemals im Internet an.

2. Interoperation

   Wenn eine Interoperation zwischen verschiedenen Betriebssystemen erforderlich ist, sollten Sie mit ASP.NET erstellte XML-Webdienste verwenden. ASP.NET-Dateien bieten erheblich mehr Flexibilität bei der Definition von Form und Stil der SOAP-Kommunikation als .NET-Remoting. Diese Flexibilität kann die Interoperation mit anderen Plattformen und Clients vereinfachen. NET-Remoting ist nicht für die Interoperation mit anderen Plattformen als .NET gedacht.

   .NET Framework-Remoting ist nicht für die Zusammenarbeit mit Webdiensten vorgesehen. Weitere Informationen zum Auswählen zwischen Webdiensten und Remoting finden Sie unter "Wählen zwischen Webdiensten, Remoting und Enterprise Services" in Leistung – Empfohlene Vorgehensweisen auf einen Blick und Normativer Leitfaden für das Auswählen von Webdiensten, Enterprise Services und .NET Remoting (möglicherweise in englischer Sprache).

3. Geschwindigkeit

   Wenn Geschwindigkeit ein treibender Faktor ist, stellen Enterprise Services die optimale Leistung für verteilte Anwendungen bereit. Der Leistungsunterschied zwischen .NET-Remoting und ASP.NET-Dateien ist sehr gering, nachdem eine Anwendung eine Echtzeitverarbeitung erfordert. Wenn Sie .NET-Remoting verwenden, bietet TcpChannel mit BinaryFormatter computerübergreifend die höchste Leistung. Auf demselben Computer muss IpcChannel mit BinaryFormatter verwendet werden.

4. Skalierbarkeit

   Wenn Sie die Anwendung in IIS hosten, erhalten Sie die Skalierbarkeit, die Sie benötigen. Bei einem selbst gehosteten .NET-Remoting muss eine eigene Skalierungsinfrastruktur erstellt werden. Wenn Sie die Verwendung von IIS mit .NET-Remoting in Erwägung ziehen, um eine bessere Skalierbarkeit zu erzielen, sollten Sie stattdessen über die Nutzung von Webdiensten nachdenken, die mit ASP.NET erstellt wurden.

5. Verwendung von Features der Common Language Runtime

   Sowohl Enterprise Services als auch .NET-Remoting nutzen .NET-Clients besser aus, sodass Sie die .NET-Features in der Anwendung verwenden können, die für einen mit ASP.NET erstellten XML-Webdienst nicht verfügbar sind. Dazu gehören:

   • Schnittstellen.

   • CallContext.

   • Eigenschaften.

   • Indexer.

   • C++.

   • Typtreue zwischen den Client- und Serveranwendungen.

   Wenn diese Features wichtig sind, wählen Sie, falls möglich, Enterprise Services und dann .NET-Remoting.

6. Objektorientierter Anwendungsentwurf.

   Sowohl Enterprise Services- als auch .NET-Remoteobjekte sind Objekte, die als solche behandelt werden können. Dadurch können Sie die folgenden objektorientierten Features, die für ASP.NET nicht verfügbar sind, in der Anwendung verwenden:

   • Objektverweise auf Remoteobjekte.

   • Mehrere Objektaktivierungsoptionen.

   • Objektorientierte Zustandsverwaltung.

   • Lebensdauerverwaltung verteilter Objekte.

   Wenn diese Features wichtig sind, wählen Sie, falls möglich, Enterprise Services und dann .NET-Remoting.

7. Benutzerdefinierte Übertragungsarten oder Übertragungsformate

   Wenn benutzerdefinierte Übertragungsarten (z. B. User Datagram Protocol (UDP)) oder benutzerdefinierte Übertragungsformate (z. B. CSV) unterstützt werden müssen, ist .NET-Remoting die einzige austauschbare Architektur, die diese Anforderungen erfüllen kann.

8. Kommunikation über Anwendungsdomänen hinweg

   Wenn eine Kommunikation zwischen Objekten in verschiedenen Anwendungsdomänen innerhalb eines Prozesses unterstützt werden muss, müssen Sie .NET-Remoting verwenden.

Die folgenden Abschnitte bieten eine kurze Zusammenfassung einiger Unterschiede, die zwischen ASP.NET erstellten XML-Webdiensten, dem System.Net-Namespace, Enterprise Services und .NET-Remoting bestehen.

XML-Webdienste

Mit ASP.NET erstellte XML-Webdienste funktionieren gut, wenn Sie ASP (Active Server Pages)-Anwendungen mit dem Webanwendungsmodell und der ASP.NET-HTTP-Laufzeit (einschließlich starker Unterstützung in Microsoft Visual Studio .NET) erstellen. Mit der Infrastruktur des XML-Webdiensts können Sie problemlos Komponenten erstellen, die von anderen Anwendungen genutzt werden können, oder Komponenten verwenden, die andere Benutzer mithilfe von Protokollen, Formaten und Datentypen erstellt haben, die sich für webbasierte Anwendungen hervorragend eignen. Eine exakte Typtreue zwischen Computern wird nicht unterstützt, und nur einige Argumenttypen können übergeben werden. Weitere Informationen finden Sie unter Mithilfe von ASP.NET und XML-Webdiensteclients erstellte XML-Webdienste.

System.Net-Namespace

Mit den Klassen im System.Net-Namespace können Sie eine ganze Kommunikationsstruktur von der Socketebene aus erstellen. Sie können mit den System.Net-Klassen außerdem Kommunikationsprotokolle und Serialisierungsformate implementieren, die Sie in die Remotearchitektur einbinden können. Weitere Informationen finden Sie unter Network Programming.

Enterprise Services

Enterprise Services basieren auf der .NET-Remoteinfrastruktur, um die zahlreichen Möglichkeiten und die Flexibilität des COM+-Modells für verteilte Objekte (einschließlich der Unterstützung für weit verteilte Transaktionen) bereitzustellen.

.NET-Remoting

.NET-Remoting stellt die Tools für zahlreiche umfassende Kommunikationsszenarien bereit, die XML-Webdienste einschließen. Durch die Verwendung von .NET-Remoting können Sie:

• Dienste in jedem Anwendungsdomänentyp veröffentlichen oder darauf zugreifen, und zwar unabhängig davon, ob es sich bei der Domäne um eine Konsolenanwendung, ein Windows Form, IIS, einen XML-Webdienst oder um einen Windows-Dienst handelt.

• Vollständige Systemtreue bei verwalteten Codetypen in binär formatierter Kommunikation, einschließlich Unterstützung für generische Typen, beibehalten.

  Hinweis:
  XML-Webdienste verwenden SOAP-Formatierung, die nicht alle Typdetails beibehält.

• Objekte als Verweis übergeben und zu einem bestimmten Objekt in einer bestimmten Anwendungsdomäne zurückkehren.

• Aktivierungseigenschaften und Objektlebensdauer direkt steuern.

• Channels oder Protokolle von Drittanbietern zur Erweiterung der Kommunikation implementieren und verwenden, um spezifische Anforderungen zu erfüllen.

• Direkt am Kommunikationsprozess teilnehmen, um die benötigte Funktionalität zu erstellen.

Siehe auch

Weitere Ressourcen

.NET-Remoting
.Übersicht über .NET Framework-Remoting
Remotingbeispiele
Remoting für Fortgeschrittene
Windows Communication Foundation

Copyright © 2007 by Microsoft Corporation. Alle Rechte vorbehalten.