Auswählen von Kommunikationsoptionen in .NET
.NET Framework bietet verschiedene Möglichkeiten für die Kommunikation mit Objekten in unterschiedlichen Anwendungsdomänen. Jede dieser Möglichkeiten ist auf ein bestimmtes Fachwissen und eine bestimmte Flexibilität zugeschnitten. Mit der immer größeren Ausbreitung des Internets sind z. B. XML-Webdienste mittlerweile zu einem bevorzugten Kommunikationsverfahren geworden, da XML-Webdienste auf der allgemein üblichen Infrastruktur des HTTP-Protokolls und der SOAP-Formatierung, die wiederum XML verwendet, basieren. Dies sind öffentliche Standards, die umgehend mit bestehenden Webinfrastrukturen verwendet werden können, ohne dass zusätzliche Überlegungen zu Proxys oder Firewalls angestellt werden müssen.
Da viele Anwendungen Funktionen benötigen, die mithilfe von ASP.NET erstellte Webdienste nicht unterstützen, können manche Anwendungen ASP.NET-Webdienste nicht verwenden. Die Informationen im folgenden Abschnitt helfen Ihnen bei der Entscheidung, welche Unterstützung verteilter Anwendungen Sie für Ihre Anwendung wünschen.
ASP.NET, Enterprise Services oder .NET Remoting?
Sowohl bei ASP.NET als auch bei Enterprise Services und .NET Remoting handelt es sich prozessübergreifenden Kommunikationsimplementierungen (Interprocess Communication, IPC). ASP.NET stellt eine Infrastruktur bereit, die von Internetinformationsdienste (Internet Information Services, IIS) gehostet wird, die Haupttypen gut verarbeitet, einige erweiterte Webdienstprotokolle (bei Verwendung mit Webdiensterweiterungen (Web Service Extensions, WSE)) unterstützt und Entwicklern von Webanwendungen vertraut ist. Enterprise Services ist eine verwaltete Implementierung von COM+ und bietet die Flexibilität und Funktionsvielfalt der COM+-Architektur. .NET Remoting ist ein generisches und erweiterbares IPC-System, dass sich selbst hosten kann oder dass in IIS gehostet werden kann, um verteilte, objektorientierte Anwendungen zu entwickeln und bereitzustellen. Die austauschbare Architektur von .NET Remoting ermöglicht benutzerdefinierte Protokolle und Sendeformate.
Bei der Entscheidung zwischen den Programmiermodellen sollten Sie die folgenden Hauptkriterien berücksichtigen: Geschäftsanforderungen, Integrationsanforderungen und das Ihnen vertraute Programmiermodell. Außerdem können die folgenden Kriterien (nach Priorität aufgeführt) dabei helfen, die für Sie erforderliche Technologie verteilter Anwendungen auszuwählen.
Sicherheitsanforderungen
Unter den drei Programmiermodellen bietet Enterprise Services die meisten Sicherheitsfunktionen und wird die meisten Szenarios erfüllen. ASP.NET bietet eine Authentifizierung über IIS und eine Verschlüsselung über SSL. Es eignet sich für die Sicherheit von Internetanwendungen. Die Sicherheit von .NET Remoting hat sich mit der neusten Version von .NET Framework verbessert. In früheren Versionen von .NET Remoting mussten Sie zum Verschlüsseln der Aufrufe oder zum Authentifizieren des Clients eine in IIS gehostete HTTP-Anwendung verwenden. Dabei spielte es keine Rolle, ob es sich um eine ASP.NET-Anwendung oder eine Remotinganwendung handelte. In der aktuellen Version unterstützen TcpChannel und HttpChannel eine SSPI-Verschlüsselung sowie die integrierte Windows-Authentifizierung. IpcChannel unterstützt außerdem die Windows-Authentifizierung sowie das direkte Festelegen der Zugriffssteuerungsliste (Access Control List, ACL) der Named Pipe. Es gibt nur wenige Szenarios, die HttpChannel erfordern, weil die Verwendung von Remoteobjekten im Internet nicht empfehlenswert ist. Wenn Sie über das Internet kommunizieren müssen, sollten Sie ASP.NET für die Erstellung von XML-Webdiensten verwenden.
Hinweis
Aus Sicherheitsgründen wird dringend empfohlen, Remotingendpunkte durch sichere Kanäle verfügbar zu machen. Machen Sie nie unsichere Remotingendpunkte für das Internet verfügbar.
Interoperabilität
Wenn verschiedene Betriebssysteme interagieren müssen, sollten Sie XML-Webdienste verwenden, die über ASP.NET erstellt wurden. ASP.NET-Dateien bieten Ihnen erheblich mehr Flexibilität bei der Definition der Form einer SOAP-Kommunikation als .NET Remoting. Diese Flexibilität kann die Interoperabilität verschiedener Plattformen und Clients erleichtern. .NET Remoting ist für eine Interoperabilität mit anderen Plattformen als .NET nicht geeignet.
.NET Framework Remoting ist für eine Interoperabilität mit Webdiensten nicht geeignet. Weitere Informationen zum Auswählen zwischen Webdiensten und Remoting finden Sie im Abschnitt zum Auswählen zwischen Webdiensten, Remoting und Enterprise Services in der Übersicht über die empfohlenen Vorgehensweisen zur Leistung sowie im Abschnitt zu den Vorgaben bei der Auswahl zwischen Webdiensten, Enterprise Services und .NET Remoting im Artikel zum Verbessern der Leistung und Skalierbarkeit von .NET-Anwendungen (beide Artikel liegen möglicherweise in englischer Sprache vor).
Geschwindigkeit
Wenn Geschwindigkeit ausschlaggebend ist, bietet Enterprise Services die beste Leistung für verteilte Anwendungen. Die .NET Remoting- und ASP.NET-Dateien unterscheiden sich kaum in der Leistung, nachdem eine Anwendung eine realistische Verarbeitung anfordert. Wenn Sie .NET Remoting verwenden, bietet TcpChannel mit BinaryFormatter die beste Leistung für alle Computer. Auf demselben Computer sollte IpcChannel mit BinaryFormatter verwendet werden.
Skalierbarkeit
Die gewünschte Skalierbarkeit erzielen Sie, wenn Sie Ihre Anwendungen in IIS hosten. Für ein sich selbst hostendes .NET Remoting müssten Sie Ihre eigene Skalierungsinfrastruktur erstellen. Wenn Sie IIS mit .NET Remoting verwenden möchten, um Skalierbarkeit zu erzielen, sollten Sie stattdessen Webdienste in Betracht ziehen, die mithilfe von ASP.NET erstellt wurden.
Verwenden von Features der Common Language Runtime
Sowohl Enterprise Services als auch .NET Remoting nutzen die Vorteile von .NET-Clients. So können Sie die .NET-Features, die für einen XML-Webdienst nicht verfügbar sind, der mithilfe von ASP.NET erstellt wurde, in der Anwendung nutzen. Dazu gehören u. a. die folgenden:
Schnittstellen
CallContext
Eigenschaften
Indexer
C++
Typintegrität zwischen Client- und Serveranwendungen
Wenn diese Features erforderlich sind, wählen Sie nach Möglichkeit Enterprise Services und dann .NET Remoting aus.
Objektorientierter Anwendungsentwurf
Sowohl Enterprise Services- als auch .NET Remoting-Objekte können als solches verwendet werden. Deshalb können die folgenden objektorientierten Features, die bei ASP.NET nicht zu Verfügung stehen, in Ihrer Anwendung verwendet werden.
Objektverweise auf Remoteobjekte
Verschiedene Optionen zur Objektaktivierung
Objektorientierte Zustandsverwaltung
Verwaltung der Lebensdauer verteilter Objekte
Wenn diese Features erforderlich sind, wählen Sie nach Möglichkeit Enterprise Services und dann .NET Remoting aus.
Benutzerdefinierte Transport- oder Sendeformate. Wenn Sie benutzerdefinierte Transportformate (z. B. UDP (User Datagram Protocol)) oder benutzerdefinierte Sendeformate (z. B. CSV) unterstützen müssen, ist .NET Remoting die einzige austauschbare Architektur, die diesen Anforderungen gerecht wird.
Anwendungsdomänenübergreifende Kommunikation. Wenn Sie eine Kommunikation zwischen Objekten in verschiedenen Anwendungsdomänen mit demselben Prozess unterstützen müssen, müssen Sie .NET Remoting verwenden.
Im Folgenden erhalten Sie eine kurze Zusammenfassung einiger Unterschiede zwischen XML-Webdiensten, die mit ASP.NET, mit dem System.Net-Namespace, mit Enterprise Services und mit .NET Remoting erstellt wurden.
XML-Webdienste
XML-Webdienste, die mit ASP.NET erstellt wurden, funktionieren einwandfrei, wenn Sie ASP-Anwendungen (Active Server Pages) mit dem Webanwendungsmodell und der HTTP-Laufzeit von ASP.NET einschließlich einer umfangreichen Unterstützung in Microsoft Visual Studio verwenden. Dank der XML-Webdienstinfrastruktur können Sie problemlos Komponenten für die Verwendung in anderen Anwendungen erstellen oder Komponenten verwenden, die von Dritten mithilfe von Protokollen, Formaten und Datentypen erstellt wurden, die sich bestens für webbasierte Anwendungen eignen. Exakte Typintegrität zwischen Computern wird nicht unterstützt, und es können nur einige Argumenttypen übergeben werden. Weitere Informationen finden Sie unter Mithilfe von ASP.NET und XML-Webdienstclients erstellte XML-Webdienste.
System.Net-Namespace
Mithilfe der Klassen im System.Net-Namespace können Sie ganze Kommunikationsstrukturen auf der Socketebene erstellen. Sie können mit den System.Net-Klassen auch Kommunikationsprotokolle und Serialisierungsformate implementieren, die sich in die Remotingarchitektur einbinden lassen. Weitere Informationen finden Sie unter Netzwerkprogrammierung.
Enterprise Services
Enterprise Services basiert auf der .NET Remoting-Infrastruktur und bietet die Funktionsvielfalt und Flexibilität des COM+-Modells verteilter Objekte einschließlich der Unterstützung für weit verteilte Transaktionen.
.NET Remoting
.NET Remoting stellt die Tools für beliebig viele umfangreiche Kommunikationsszenarios bereit, die u. a. auch XML-Webdienste umfassen. Mit .NET Remoting können Sie folgende Aufgaben durchführen:
Dienste in jeder Art von Anwendungsdomäne veröffentlichen oder verwenden, unabhängig davon, ob es sich bei der Domäne um eine Konsolenanwendung, ein Windows Form, IIS, einen XML-Webdienst oder einen Windows-Dienst handelt.
Eine vollständig verwaltete Integrität des Codetypsystems in Kommunikationsstrukturen mit binärer Formatierung beibehalten einschließlich der Unterstützung für generische Typen.
Hinweis
XML-Webdienste verwenden die SOAP-Formatierung, bei der nicht alle Typdetails erhalten bleiben.
Objekte als Verweis übergeben und an ein bestimmtes Objekt in einer bestimmten Anwendungsdomäne zurückgeben.
Aktivierungsmerkmale und Lebensdauer von Objekten direkt steuern.
Channels und Protokolle von Drittanbietern implementieren und verwenden, um die Kommunikation entsprechend den Anforderungen zu erweitern.
Direkt am Kommunikationsprozess teilnehmen, um so die benötigte Funktionalität erreichen.
Siehe auch
Weitere Ressourcen
Remoteobjekte
Übersicht über .NET Framework Remoting
Remotingbeispiele
Erweitertes Remoting