Freigeben über

Auswahl 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, aufbauen. Bei diesen beiden handelt es sich um öffentliche Standards, die umgehend mit bestehenden Webinfrastrukturen zum Einsatz kommen können, ohne dass zusätzliche Überlegungen zu Proxy oder Firewall angestellt werden müssen.

Es ist jedoch nicht zu empfehlen, sämtliche Anwendungen mit einer Form von XML-Webdienst zu erstellen, und sei es nur aufgrund der mit der Verwendung der SOAP-Serialisierung über eine HTTP-Verbindung verbundenen Leistungsprobleme. Dieser Abschnitt enthält Informationen, die Ihnen die Wahl der gewünschten Form für die Kommunikation zwischen Objekten der Anwendung erleichtern sollen.

ASP.NET oder Remoting?

Sowohl bei ASP.NET als auch bei .NET Remoting handelt es sich um Möglichkeiten der prozessübergreifenden Kommunikationsimplementierung. ASP.NET stellt eine Infrastruktur bereit, deren Host die Internet-Informationsdienste (IIS) sind, die Haupttypen gut verarbeitet und Entwicklern von Webanwendungen vertraut ist. .NET Remoting ist ein generisches und erweiterbares prozessübergreifendes Kommunikationssystem, mit dem Sie in IIS gehostete XML-Webdienste (mit dem vollen Umfang der Sicherheit, Skalierbarkeit sowie dem Sitzungs- und Anwendungsstatus von ASP.NET und IIS) oder Anwendungen erstellen können, die beliebige andere Kommunikationsprotokolle oder Serialisierungsformate nutzen können.

Der benötigte Kommunikationstyp und das Ihnen vertraute Programmiermodell sind die entscheidenden Kriterien, die den Ausschlag für das eine oder andere Programmiermodell geben. Sie müssen den Typ der prozessübergreifenden Kommunikation sowie das Programmiermodell auswählen, mit deren Hilfe Ihre Entscheidungen auf die einfachste Weise implementiert werden können. Im Folgenden werden einige Kriterien (in der Reihenfolge ihrer Priorität) für die Auswahl des benötigten Typs der prozessübergreifenden Kommunikation sowie ein Vergleich zwischen mit ASP.NET erstellten XML-Webdiensten und mit .NET Remoting erstellten XML-Webdiensten aufgeführt:

  1. Sicherheitsanforderungen.

    Wenn Sie Ihre Aufrufe verschlüsseln oder Ihren Client authentifizieren müssen, müssen Sie eine in IIS gehostete HTTP-Anwendung verwenden. Dabei spielt es keine Rolle, ob es sich um eine ASP.NET-Anwendung oder eine Remoteanwendung handelt. Dies liegt daran, dass ASP.NET und .NET Remoting die von IIS bereitgestellten Sicherheitsdienste verwenden. .NET Remoting stellt nur dann Sicherheitsdienste bereit, wenn IIS (und nicht etwa ein Windows-Dienst) als Host fungiert. Obwohl .NET Remoting in beliebigen Anwendungsdomänen verwendet werden kann (im Gegensatz zu mit ASP.NET erstellten XML-Webdiensten, die in IIS gehostet werden müssen), müssen Sie die Sicherheitsfeatures bereitstellen, die für eine Verwendung von .NET Remoting außerhalb von IIS erforderlich sind. Bei Verwendung einer HTTP-Verbindung muss das SOAP-Codierungsformat nicht verwendet werden. Zur Erhöhung der Geschwindigkeit können Sie die binäre Codierung verwenden.

  2. Geschwindigkeit.

    .NET Remoting weist einen potenziellen Leistungsvorteil gegenüber mit ASP.NET erstellten XML-Webdiensten auf, da Sie die Möglichkeit haben, die binäre Codierung und den Standard-TcpChannel zu verwenden, und so eine optimale Leistung bei der prozessübergreifenden Kommunikation gewährleistet ist. Sie können selbst dann eine binäre Codierung angeben, wenn der Standard-TcpChannel nicht verwendet wird. In diesem Fall führen Sie das binäre Formatierungsprogramm mit der HttpChannel-Klasse aus, die die POST-Kommunikation mit IIS (oder einer beliebigen Listeneranwendung für HttpChannel-Remoting) verwendet. Allein die Verwendung der binären Formatierung erhöht die Aufrufleistung beim Remoting erheblich, selbst wenn Sie den HttpChannel verwenden. Wenn keine Sicherheitsprobleme bestehen (z. B. bei einer kleinen, vollständig innerhalb einer Firewall ausgeführten Anwendung), wird über den standardmäßigen TcpChannel mit einem binären Formatierungsprogramm die optimale Leistung erzielt. Für mit ASP.NET erstellte XML-Webdienste wird immer die SOAP-Codierung verwendet, wobei die Leistung i. A. geringer als bei einer binären Codierung ist. Wenn jedoch keine .NET Remotingfeatures erforderlich sind, das HTTP-Protokoll und SOAP-Meldungen hingegegen benötigt werden, führen mit ASP.NET erstellte XML-Webdienste zu einer besseren Leistung.

  3. Interoperabilität.

    Wenn die Zusammenarbeit verschiedener Betriebssysteme erforderlich ist, wird i. d. R. das SOAP-Formatierungsprotokoll verwendet, unabhängig davon, ob Sie mit .NET Remoting oder mit ASP.NET arbeiten. Mit ASP.NET erstellte XML-Webdienste ermöglichen eine wesentlich höhere Flexibilität beim Definieren von Form und Stil der SOAP-Kommunikation als .NET Remoting. Dies kann die Zusammenarbeit verschiedener Plattformen und Clients erleichtern. .NET Remoting wurde für die Kommunikation mit .NET-Clients optimiert. Darüber hinaus ist jedoch auch die Zusammenarbeit verschiedener Betriebssysteme mit Hilfe einer Remotinganwendung möglich.

  4. Skalierbarkeit.

    Das Hosten der Anwendung in IIS gewährleistet die benötigte Skalierbarkeit, egal, ob Sie .NET Remoting oder ASP.NET verwenden.

  5. Verwendung von Features der Common Language Runtime

    Da .NET-Clients von .NET Remoting besser genutz werden können, können Sie in einer Remoteanwendung .NET-Features verwenden, die bei einem mit ASP.NET erstellten XML-Webdienst nicht verfügbar sind. Hierzu gehören u. a. folgende Features:

    • Schnittstellen
    • CallContext
    • Eigenschaften
    • Indexer
    • Managed Extensions for C++
    • Typintegrität zwischen Client- und Serveranwendungen
    • Delegaten

  6. Objektorientierter Anwendungsentwurf

    Mit ASP.NET erstellte XML-Webdienste stellen kein objektorientiertes Entwurfsparadigma dar. Im Wesentlichen handelt es sich bei ihnen um statusfreie Webressourcen, vergleichbar mit Webseiten, obwohl IIS und die ASP.NET-Infrastruktur einige Statusdienste bereitstellen. .NET Remoting-Objekte sind Objekte und können als solche behandelt werden. Deshalb können die folgenden objektorientierten .NET-Features verwendet werden, die bei ASP.NET nicht verfügbar sind:

    • Objektverweise auf Remoteobjekte
    • Verschiedene Optionen zur Objektaktivierung
    • Objektorientierte Statusverwaltung
    • Verwaltung der Lebensdauer verteilter Objekte

Im Folgenden erhalten Sie eine kurze Übersicht über einige Unterschiede zwischen XML-Webdiensten, die mit ASP.NET, mit dem System.Net-Namespace und mit .NET Remoting erstellt wurden.

XML-Webdienste

Wenn Sie ASP-Anwendungen mit dem Webanwendungsmodell erstellen und die Leistungsfähigkeit der ASP.NET HTTP-Runtime einschließlich der umfangreichen Unterstützung in Microsoft Visual Studio .NET nutzen möchten, dann sind mit ASP.NET erstellte XML-Webdienste genau das Richtige für Sie. Dank der XML-Webdienstinfrastruktur können Sie problemlos Komponenten für die Verwendung in anderen Anwendungen erstellen oder Komponenten verwenden, die von Dritten mit Hilfe 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 Mit Hilfe von ASP.NET und XML-Webdienstclients erstellte XML-Webdienste.

System.Net-Namespace

Mit Hilfe der Klassen im System.Net-Namespace können Sie ganze Kommunikationsstrukturen von Grund auf errichten. 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 Zugreifen auf das Internet.

.NET Remoting

.NET Remoting stellt die Tools für beliebig viele umfangreiche Kommunikationsszenarien 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, Internet-Informationsdienste (IIS), einen XML-Webdienst oder einen Windows-Dienst handelt.

  • Eine vollständig verwaltete Integrität des Codetypsystems in Kommunikationsstrukturen mit binären Formatierungsprogrammen beibehalten.

    Hinweis   XML-Webdienste verwenden SOAP-Formatierung, bei der nicht alle Typinformationen 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 auszubauen.

  • Direkt am Kommunikationsprozess teilnehmen und so die benötigte Funktionalität erreichen.

Siehe auch

Zugriff auf Objekte in anderen Anwendungsdomänen mit .NET-Remoting | Übersicht über .NET Remoting | Remotingbeispiele | Erweitertes Remoting

  • Last updated on