ASP.NET Web Services oder .NET Remoting - So treffen Sie die richtige Entscheidung

Veröffentlicht: 10. Nov 2002 | Aktualisiert: 21. Jun 2004
Von Priya Dhawan und Tim Ewald

Dieser Artikel erklärt, wie mithilfe der Infrastruktur von Microsoft .NET Remoting und der ASP.NET Web Services von Microsoft eine prozessübergreifende Kommunikation hergestellt werden kann. Außerdem zeigt er, wie beide Technologien funktionieren und anhand welcher Kriterien der Anwender für sich die richtige Anwendung auswählt.

Auf dieser Seite

Übersicht Übersicht
Serialisierung und Metadaten Serialisierung und Metadaten
Verteilter Anwendungsentwurf: ASP.NET Web Services kontra .NET Remoting Verteilter Anwendungsentwurf: ASP.NET Web Services kontra .NET Remoting
Auswählen einer Architektur Auswählen einer Architektur
Zusammenfassung Zusammenfassung

Übersicht

In den letzten Jahren wurden Anwendungen zunehmend in Form einer Gruppe von Komponenten erstellt, die über ein Netzwerk verteilt wurden und zusammen ein komplettes Programm bildeten. Normalerweise erfordert eine verteilte Anwendungslogik eine Objekttechnologie für Komponenten, z.B. DCOM (Distributed Component Object Model) von Microsoft, CORBA (Common Object Request Broker Architecture) oder RMI (Remote Method Invocation) von Sun. Diese Technologien bieten eine verlässliche und skalierbare Architektur, die den wachsenden Bedürfnissen von Anwendungen gerecht wird.

Die komponentenbasierten Technologien funktionieren zwar einwandfrei in einer Intranetumgebung, aber bei einer Verwendung im Internet treten zwei signifikante Probleme auf. Erstens: die Technologien sind nicht kompatibel. Zwar arbeiten beide Technologien mit Objekten, allerdings liegen die Unterschiede im Detail z.B. in Bezug auf die Verwaltung von Lebenszyklen oder die Unterstützung von Konstruktoren bzw. der Vererbung.

Zweitens: Da der Schwerpunkt auf einer RPC-artigen Kommunikation (Remote Procedure Call) liegt, ergeben sich eng miteinander verbundene Systeme für die expliziten Aufrufe von Objektmethoden.
Im Gegensatz dazu sind browserbasierte Webanwendungen nur lose miteinander verbunden und bieten eine bemerkenswerte Interoperabilität. Sie kommunizieren über HTTP, um Daten vom Typ MIME in unterschiedlichen Formaten auszutauschen. Bei Web Services wird dieses Webprogrammiermodell adaptiert, um es dann mit den unterschiedlichsten Anwendungen zusammen einzusetzen. Mittels HTTP werden SOAP-Nachrichten und andere Internetprotokolle ausgetauscht. Da Web Services auf Branchenstandards wie HTTP, XML, SOAP und WSDL basieren, um Anwendungsfunktionen im Internet bereitzustellen, sind sie sowohl von der Programmiersprache als auch von Plattform und Gerät unabhängig.

Die Infrastruktur der ASP.NET Web Services bietet eine einfache API für Web Services, bei denen SOAP-Nachrichten und Methodenaufrufe einander zugeordnet werden. Die Realisierung erfolgt durch die Bereitstellung eines einfachen Programmiermodells, bei dem der SOAP-Nachrichtenaustausch mit einzelnen Methodenaufrufen verknüpft wird. Dabei benötigen die Clients der ASP.NET Web Services keinerlei Kenntnisse über die Plattform, das Objektmodell oder die verwendete Programmiersprache.

Im Gegenzug dazu benötigen auch die Dienste selbst keinerlei Kenntnisse über die Clients, von denen sie die Nachrichten erhalten. Es ist lediglich eine Übereinkunft über das Format der erstellten und verwendeten SOAP-Nachrichten der beiden Parteien notwendig. Das Format ergibt sich aus der Vertragsdefinition des Web Services, die mithilfe von WSDL und XML-Schema (XSD) erstellt wurde.

.NET Remoting stellt eine Infrastruktur für verteilte Objekte zur Verfügung. Diese legt für Remoteprozesse die volle Objektsemantik über eine flexible und erweiterbare Methode offen. Verglichen mit den Web Services von ASP.NET, die ein sehr einfaches Programmiermodell bereitstellen, das auf der Übergabe von Nachrichten basiert, ermöglicht .NET Remoting wesentlich komplexere Funktionen einschließlich der Übergabe von Objekten nach Wert oder Verweis sowie der Möglichkeit von Rückrufen, einer Mehrfachobjektaktivierung und der Verwendung von Richtlinien für die Lebenzyklusverwaltung.

Damit ein Client .NET Remoting verwenden kann, müssen ihm all diese Details bekannt sein - d.h., die Erstellung muss mit .NET erfolgen. (Oder mit einem anderen Framework, das .NET Remoting unterstützt; derzeit lediglich Ja.NET für Java von Intrinsyc.). Der .NET-Remoting-Code unterstützt auch SOAP-Nachrichten. Dies wirkt sich jedoch nicht auf die Clientanforderungen aus. Wenn ein .NET-Remoting-Endpunkt .NET-spezifische Objektsemantiken z.B. über SOAP bereitstellt, muss der Client diese auch verarbeiten können.

Die Tatsache, dass .NET Framework zwei unterschiedliche verteilte Programmiermodelle unterstützt - Web Services und verteilte Objekte - warf für Entwickler viele Fragen auf. Zum Beispiel: Wann sollte ein System ASP.NET Web Services und wann besser .NET Remoting einsetzen? Um diese Frage beantworten zu können, muss die Funktionsweise beider Technologien bekannt sein.

Serialisierung und Metadaten

Bei der verteilten Kommunikationsmethode passieren im Wesentlichen zwei Dinge: die Instanzen von Programmdatentypen werden in Nachrichten übertragen, die über ein Netzwerk versendet werden können, und darüber hinaus wird eine Nachrichtenbeschreibung bereitgestellt. Ersteres wird durch einer Art Serialisierungsmodul oder einen Marshaller erreicht und Letzteres über Metadaten. So wurde beispielsweise für die meisten DCOM-Schnittstellen der Typenbibliothekenmarshaller als Serialisierungsmodul eingesetzt, wobei die Metadaten von den Typenbibliotheken bereitgestellt wurden. Der wesentliche Unterschied zwischen ASP.NET Web Services und .NET Remoting besteht in der Art, wie sie Daten in Nachrichten serialisieren und welches Format sie für die Metadaten auswählen.

ASP.NET Web Services, "XmlSerializer" und XSD
ASP.NET Web Service verwenden die System.Xml.Serialization.XmlSerializer-Klasse, um Daten in und aus SOAP-Nachrichten zur Laufzeit zu übertragen. Bei Metadaten werden WSDL- und XSD-Definitionen generiert, die den Inhalt der Nachrichten beschreiben. Dadurch, dass ASP.NET Web Services auf reinem WSDL und XSD basieren, werden sie übertragbar; die Datenstrukturen werden von anderen Web Service-Toolkits auf unterschiedlichen Plattformen mit unterschiedlichen Programmiermodells verstanden.

In einigen Fällen bedeutet dies eine Einschränkung der Typen, die Sie über einen Web Service bereitstellen können - XmlSerializer marshallt nur Daten, die in XSD ausgedrückt werden können. XmlSerializer marshallt insbesondere keine Objektgraphen und bietet nur eine begrenzte Unterstützung für Containertypen.
In Bezug auf den Einsatz klassischer verteilter Objekte mögen diese Einschränkungen zwar signifikant sein, sie helfen jedoch dabei, eine Interoperabilität mit anderen Web Service-Frameworks sicherzustellen - ein grundlegendes Ziel lose gekoppelter Web Service-Modelle.

Die Unterstützung der Interoperabilität wird durch mehrere benutzerdefinierte Attribute realisiert, mittels derer Sie Ihre Datentypen benennen können, um zu steuern, wie diese von XmlSerializer gemarshallt werden. Dadurch haben Sie die Möglichkeit, die Form des XML-Codes zu beeinflussen, der bei der Serialisierung eines Objekts erstellt wird. Darüber hinaus kann ein ASP.NET-basierter Web Service so eingerichtet werden, dass dessen Nachrichten in Form eines literalen XSD (XML-Schema) oder der SOAP-Codierungsregeln (d.h. SOAP-Abschnitt 5) beschrieben werden.

Literale XSDs sind der Standard, der auch weiterhin verwendet wird. Die Unterstützung der SOAP-Codierung ist aus Gründen der Interoperabilität mit vorhandenen Toolkits ebenfalls gewährleistet. Dies ist insbesondere dann von Vorteil, wenn Sie mit einem Web Service oder einem Client kommunizieren müssen, der ein vordefiniertes Nachrichtenformat verwendet.

.NET Remoting, "IFormatter" und CLR (Common Language Runtime)
.NET Remoting basiert auf Plug-In-Implementierungen der IFormatter-Schnittstelle, die vom System.Runtime.Serialization-Modul zum Marshallen von Daten in und aus Nachrichten eingesetzt wird. Es gibt zwei Standard-Formatierungsprogramme System.Runtime.Serialization.Formatters.Binary.BinaryFormatter und System.Runtime.Serialization.Formatters.Soap.SoapFormatter. Wie der Name bereits sagt, marshallen diese Typen entweder in ein binäres oder ein SOAP-Format.

Was die Metadaten angeht, basiert .NET Remoting auf den CLR-Assemblys, die alle relevanten Informationen zu den Datentypen enthalten, die sie implementieren, und per Reflektion offen gelegt werden. Dadurch ist es den Metadaten möglich, die Genauigkeit des Laufzeittypsystems zu gewährleisten. Deshalb schließt der .NET-Remoting-Code beim Marshallen von Daten alle öffentlichen und privaten Member einer Klasse ein, verarbeitet Objektgraphen korrekt und unterstützt die Containertypen (z.B. System.Collections.Hashtable).

Allerdings begrenzt die Abhängigkeit von den Metadaten auch die Reichweite eines .NET-Remoting-Systems - denn um mit einem .NET-Remoting-Endpunkt zu kommunizieren, muss ein Client die .NET-Konstrukte verarbeiten können. Zusätzlich zu den Plug-in-Formatierungsprogrammen unterstützt die .NET-Remoting-Ebene Plug-In-Kanäle, die die Details in Bezug auf das Senden der Nachrichten abstrahieren. Es gibt zwei Standardkanäle, einen für reines TCP und einen anderen für HTTP. Die Nachrichten können unabhängig vom Format über beide Kanäle gesendet werden.

Remoting und Web Services
Das Vorhandensein eines SOAP-Formatierungsprogramms und eines HTTP-Kanals wirft die Frage auf, ob mittels .NET Remoting Web Services erstellt werden können. Die Antwort darauf lautet ja und nein. Der standardmäßige Technologiestapel eines Web Services basiert nicht nur auf SOAP-artigen Nachrichten, sondern auch auf den WSDL- und XSD-basierten Beschreibungen derselben. Der .NET-Remoting-Code kann tatsächlich WSDL-Definitionen erzeugen, die die Nachrichten beschreiben, die von einem Endpunkt erstellt und verarbeitet werden. Allerdings ist dies nicht so einfach, wie es sich zuerst anhört.

Zum einen beschreiben die WSDL-Dateien die Nachrichten in Form von SOAP-Codierungsregeln und nicht in Form von XSDs. Das ist heutzutage zwar kein Problem, kann sich aber zu einem entwickeln, wenn sich mehr und mehr Tools nur noch auf Schemata konzentrieren.

Zum anderen enthalten die erzeugten WSDL-Dateien .NET-Remoting-spezifische Erweiterungen. Nachfolgend ein Beispiel einer einfachen Klasse, die .NET Remoting zur Bereitstellung des Verhaltens verwendet:

public class Methods : MarshalByRefObject
{
    // Die Now-Methode gibt das aktuelle Datum und die aktuelle Zeit zurück
    public string Now()
    {
        return System.DateTime.Now.ToString();
    }
}

Wenn Sie aus dieser Klasse eine WSDL-Datei erstellen, enthalten die Bindungsinformationen wie unten gezeigt .NET-Remoting-spezifische Daten.

<binding name='MethodsBinding' type='ns0:MethodsPortType'>
<soap:binding style='rpc'
              transport='http://schemas.xmlsoap.org/soap/http'/>
  <suds:class type='ns0:Methods' rootType='MarshalByRefObject'>
  </suds:class>
  <operation name='Now'>
    <soap:operation soapAction=
 'http://schemas.microsoft.com/clr/nsassem/RemSoap.Methods/methods#Now'/>
    <suds:method attributes='public'/>
    <input name='NowRequest'>... </input>
    <output name='NowResponse'>... </output>
  </operation>
</binding>


Diese zusätzlichen Elemente sind zulässig, da die WSDL-Spezifikation eine Erweiterung unterstützt. Ein gut programmiertes Web Service-Toolkit, das sie nicht verarbeiten kann, wird diese einfach ignorieren. Allerdings gibt es auch einige Dinge, die nicht ignoriert werden können. Beispielsweise im Falle eines .NET-Remoting-Endpunkts, der ein Microsoft ADO.NET-System.Data.DataSet zurückgibt.

public class Methods : MarshalByRefObject 
{
   public System.Data.DataSet GetEmptyDataSet()
    {
        return new System.Data.DataSet();
    }
}

Hier die erstellte WSDL-Definition für die Ausgabenachricht der Methode:

<message name='Methods.GetEmptyDataSetOutput'>
  <part name='return' type='ns3:DataSet'/>
</message>


Normalerweise bezieht sich eine WSDL-Nachricht auf Typen, die in einem speziellen Namespace mittels eines XML-Schemas definiert wurden. In diesem Fall ist das Namespace-Präfix "ns3", das für den DataSet-Typ angewendet wurde, nicht in XSD definiert. Stattdessen wird es implizit zur Laufzeit definiert. Das Präfix "ns3" aus diesem Beispiel ist an einen XML-Namespace gebunden, der durch folgenden URI identifiziert wird:

http://schemas.microsoft.com/clr/nsassem/System.Data/System.Data%2C%20Version%3D1.0
.3300.0%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Db77a5c561934e089

Soll diese WSDL-Definition verwendet werden, muss die besondere Bedeutung dieses URI bekannt sein - hierbei handelt es sich um einen vierteiligen Strong Name einer besonderen Laufzeitassembly, die in .NET Framework enthalten ist. Diese Art der WSDL eignet sich besonders für Clients, die über .NET Remoting implementiert wurden, da sie eine Proxyassembly erstellen können, die die korrekten Informationen zum Marshallen enthält. Für andere Web Service-Toolkits jedoch - einschließlich ASP.NET - die diesen URI nicht verarbeiten können und stattdessen ein Schema für die Definition des DataSet-Typs erwarten, ist diese WSDL nutzlos.

Somit sind wir wieder bei der Frage, ob mit .NET Remoting Web Services erstellt werden können. Streng genommen ist dies möglich. Allerdings stellt sich hier wiederum die Frage, ob jemand, der das .NET-Remoting-Verfahren nicht einsetzt, diese Web Services auch verwenden kann. Möglicherweise, sofern der Anwender den Endpunkt auf reine Datentypen und Semantiken beschränkt.

Insbesondere, wenn Sie eine Interoperabilität mit anderen Web Service-Toolkits erreichen möchten, müssen Sie die Parameter auf die implementierten einfachen Typen sowie auf Ihre eigenen Datentypen beschränken. Verwenden Sie keine .NET Framework-Typen wie DataSet, und vermeiden Sie clientaktivierte Objekte und Ereignisse. Wenn Ihnen also die Reichweite besonders wichtig ist, beschränken Sie sich auf die Funktionen, die der Web Service von ASP.NET unterstützt.
Oder besser noch, arbeiten Sie gleich mit ASP.NET Web Services.

Verteilter Anwendungsentwurf: ASP.NET Web Services kontra .NET Remoting

ASP.NET Web Service favorisieren das Typsystem des XML-Schemas und bieten ein einfaches Programmiermodell mit großer Plattformreichweite. .NET Remoting favorisiert das Laufzeittypsystem und bietet ein komplexeres Programmiermodell mit eingeschränkter Reichweite. Anhand dieses grundlegenden Unterschieds wird letztendlich entschieden, welche Technologie zum Einsatz kommt. Allerdings gibt es noch viele andere Entwurfsfaktoren wie Transportprotokolle, Hostprozesse, Sicherheit, Leistung, Statusverwaltung und die Unterstützung von Transaktionen, die berücksichtigt werden sollten.

Transportprotokolle und Hostprozesse
Auch wenn die SOAP-Spezifikation HTTP nicht als Transportprotokoll vorschreibt, kann der Client nur auf Web Services zugreifen, die über ASP.NET Web Services implementiert wurden, wenn er HTTP verwendet, da dies das einzige Transportprotokoll ist, das ASP.NET unterstützt. Die Dienste werden über IIS (Internet Information Server) aufgerufen und vom ASP.NET-Workerprozess aspnet_wp.exe ausgeführt.

Mit .NET Remoting haben Sie die Möglichkeit, Remoteobjekte in beliebigen Anwendungen einschließlich Windows Forms, eines verwalteten Dienstes, einer Konsolenanwendung oder eines ASP.NET-Workerprozesses zu verwalten. Wie bereits erwähnt, stellt .NET Remoting zwei Übertragungskanäle zur Verfügung: TCP und HTTP. Beide Kanäle ermöglichen über Sockets eine Kommunikation zwischen Sende- und Empfangsprozessen.

Darüber hinaus ist es auch möglich, den HTTP-Kanal in den IIS und den ASP.NET-Workerprozess zu integrieren. Dies ist aus vielerlei Gründen wichtig. Erstens ist dies die einzige Möglichkeit, einen .NET-Remoting-Endpunkt automatisch zu starten, wenn eine Clientanfrage eingeht. Das .NET-Remoting-Verfahren enthält keinen DCOM-artigen SCM (Service Control Manager), um Remoteserver zu starten. Wenn Sie Remoteobjekte aus Prozessen bereitstellen, müssen Sie sicherstellen, dass diese Prozesse auch ausgeführt werden.

Darüber hinaus müssen Sie dafür sorgen, dass sie threadsicher sind, d.h., dass Thread A ein Objekt nicht aktivieren kann, nachdem Thread B gestartet wurde, um den Prozess herunterzufahren. Wenn Sie Remoteobjekte über ASP.NET bereitstellen, können Sie sich die Tatsache zu Nutze machen, dass der Workerprozess Aspnet_wp.exe sowohl automatisch startet als auch threadsicher ist. Zweitens ist, wie im nachfolgenden Abschnitt beschrieben, die Integration in den IIS die einzige Möglichkeit, einen prozessübergreifenden .NET-Remoting-Aufruf zu sichern.

Sowohl die ASP.NET Web Services als auch die .NET-Remoting-Infrastrukturen sind erweiterbar. Sie können ein- und ausgehende Nachrichten filtern und das Typenmarshalling sowie die Metadatenerstellung kontrollieren. Mit .NET Remoting können Sie auch eigene Formatierungsprogramme und Kanäle implementieren.

Sicherheit
Da ASP.NET Web Services auf HTTP basieren, lassen sie sich problemlos in die standardmäßige Internetsicherheitsinfrastruktur integrieren. ASP.NET nutzt die über den IIS verfügbaren Sicherheitsfunktionen, um eine Unterstützung für standardmäßige Authentifizierungsschemata einschließlich Basic, Digest und digitale Zertifikate sowie Microsoft .NET Passport zu ermöglichen. (Für Clients einer vertrauenswürdigen Domäne können Sie auch die integrierte Authentifizierung von Windows verwenden). Ein Vorteil der verfügbaren HTTP-Authentifizierungschemata ist, dass in einem Web Service keine Codeänderung erforderlich ist.

IIS führt die Authentifizierung durch, ehe die ASP.NET Web Service aufgerufen werden. ASP.NET unterstützt zudem eine .NET Passport-basierte Authentifizierung sowie andere gängige Authentifizierungsschemata. ASP.NET unterstützt darüber hinaus eine Zugriffskontrolle auf der Grundlage von Ziel-URLs sowie durch die Integration in die .NET-CAS-Infrastruktur (CAS = Code Access Security). Mit SSL kann eine private Kommunikation über das Netz sichergestellt werden.

Auch wenn diese standardmäßigen Techniken auf Transportebene zum Sichern von Web Services recht effektiv sind, sind sie nicht immer ausreichend. Bei komplexen Szenarios mit mehreren Web Services in verschiedenen vertrauenswürdigen Domänen sind benutzerdefinierte Ad-hoc-Lösungen gefordert. Sowohl Microsoft als auch andere Unternehmen arbeiten an einer Reihe von Sicherheitsspezifikationen, die auf der Erweiterbarkeit von SOAP-Nachrichten basieren, um Sicherheitsfunktionen auf Nachrichtenebene zu gewährleisten.

Eine dieser Funktionen ist die XML-Web Service-Sicherheitssprache (WS-SecurityHier verlassen Sie die Website von Microsoft Deutschland [in Englisch]), die eine Grundlage für die Übertragung von Anmeldeinformationen auf Nachrichtenebene, für die Nachrichtenintegrität und für die Vertrauenswürdigkeit von Nachrichten definiert.
Wie bereits im vorherigen Abschnitt erwähnt, sichert das .NET-Remoting-Verfahren keine prozessübergreifenden Aufrufe im üblichen Sinne. Ein .NET-Remoting-Endpunkt der auf dem IIS mit ASP.NET verwaltet wird, kann sich alle für ASP.NET Web Services verfügbaren Sicherheitsfunktionen einschließlich der Unterstützung für sichere Kommunikationen über die Leitung per SSL zu Nutze machen. Wenn Sie den TCP-Kanal oder den HTTP-Kanal verwenden, der in einem anderen Prozess als aspnet_wp.exe verwaltet wird, müssen Sie die Authentifizierung, Autorisierung und den Datenschutz selbst implementieren.

Ein weiterer Sicherheitsaspekt ist die Möglichkeit, Code einer nicht vollständig vertrauenswürdigen Domäne auszuführen, ohne die Standardsicherheitsrichtlinie ändern zu müssen. Clientproxys von ASP.NET Web Services unterstützen solche Umgebungen, .NET-Remoting-Proxys nicht. Um einen .NET-Remoting-Proxy aus einer nicht vollständig vertrauenswürdigen Umgebung zu nutzen, benötigen Sie eine spezielle Serialisierungserlaubnis, die standardmäßig nicht für Code aus dem Internet oder Intranet gilt.

Um einen .NET-Remoting-Client in einer nicht vollständig vertrauenswürdigen Umgebung zu nutzen, müssen Sie die Standardsicherheitsrichtlinie für den Code ändern, der aus solchen Zonen geladen wird. Wenn Sie sich mit Clientsystemen verbinden, die in einer geschützten Umgebung (Sandbox) ausgeführt werden, z.B. einer downgeloadeten Windows-Forms-Anwendung, sind die ASP.NET Web Service die bessere Wahl, da eine Änderung der Sicherheitsrichtlinien hier nicht erforderlich ist.

Statusverwaltung
Das Modell der ASP.NET Web Services geht standardmäßig von einer statusfreien Dienstarchitektur aus und bringt nicht automatisch mehrere Aufrufe eines Benutzers miteinander in Beziehung. Darüber hinaus wird jedes Mal, wenn ein Client einen ASP.NET Web Service aufruft, ein neues Objekt erstellt, um diesen Aufruf zu bedienen. Nach Abschluss der Methode wird das Objekt wieder zerstört. Um den Status zwischen den Anforderungen aufrecht zu erhalten, können Sie entweder die von ASP.NET-Seiten verwendete Technologie verwenden, d.h. die Sitzungs- und Anwendungseigenschaftensammlung, oder Sie implementieren eine eigene benutzerdefinierte Lösung.

.NET Remoting unterstützt viele Statusverwaltungsoptionen und bringt je nach eingesetztem Objektzeitschema mehrere Aufrufe von ein und demselben Benutzer miteinander in Einklang. SingleCall-Objekte sind statusfrei (wie die Objekte, mit denen ASP.NET Web Services aufgerufen werden), Singleton-Objekte verwenden für alle Clients denselben Status und clientaktivierte Objekte wahren den Status auf einer "pro-Client"-Basis (mit allen damit verbundenen Skalierbarkeits- und Zuverlässigkeitsaspekten).

Leistung
Im Hinblick auf die Leistung erzielen Sie mit dem .NET-Remoting-Verfahren die schnellste Kommunikation, wenn Sie den TCP-Kanal und das binäre Formatierungsprogramm verwenden. Bei fast allen Tests, die wir durchführten, um die relative Leistung von ASP.NET Web Services und .NET Remoting miteinander zu vergleichen, übertraf der ASP.NET Web Service die Leistung von .NET-Remoting-Endpunkten, die das SOAP-Formatierungsprogramm entweder mit dem HTTP oder dem TCP-Kanal verwendeten. Noch interessanter ist die Tatsache, dass ASP.NET- und .NET-Remoting-Endpunkte, die das binäre Formatierungsprogramm und den HTTP-Kanal verwendeten, dieselbe Leistung erzielten. (Weitere Informationen finden Sie unter Performance Comparison: .NET Remoting vs. ASP.NET Web Services [in Englisch].)

Enterprise Services
Ein ASP.NET Web Service oder ein Objekt, welches über .NET Remoting bereitgestellt wird, kann mittels lokaler Transaktionen die Arbeit einer einzelnen Datenbank koordinieren. Bei der Koordination mehrerer Ressourcen kann eine deklarative Transaktion (eine DTC-verteilte Transaktion, die vom COM+-Verfahren verwaltet wird) von .NET Enterprise Services (auch bekannt als COM+) eingesetzt werden. Dabei ist jedoch wichtig zu wissen, dass weder die ASP.NET Web Services noch das .NET-Remoting-Verfahren das Verbreiten einer deklarativen Transaktion unterstützten. Somit ist es für keinen Endpunkt möglich, eine deklarative Transaktion mittels eines prozessübergreifenden Aufrufs zu erben.

Das ist jedoch nicht unbedingt von Nachteil. Im Allgemeinen ist eine deklarative Transaktion auch dann noch teurer, wenn Sie sie prozessübergreifend verwenden. Wenn Sie diese Funktion wirklich benötigen, sollten Sie eine Klasse, die sich von System.EnterpriseServices.ServicedComponent ableitet, in einer .NET Enterprise Services-Serveranwendung bereitstellen (siehe auch COM+ Integration: How .NET Enterprise Services Can Help You Build Distributed Applications [in Englisch]). Prozessübergreifende Aufrufe der Objekte werden mit DCOM verarbeitet, um eine korrekte Verbreitung des Transaktionskontexts zu gewährleisten. Eine andere Möglichkeit besteht darin, ältere APIs zu verwenden, um verteilte Transaktionen manuell zu verbreiten.

An dieser Stelle sei erwähnt, dass sich das klassische verteilte Transaktionsmodell nicht für lose gekoppelte Web Services eignet. Ein Modell, das auf kompensierenden Transaktionen basiert, d.h. Transaktionen, die die übertragene Arbeit für andere Transaktionen rückgängig machen, macht mehr Sinn, da weniger strenge Isolationsbeschränkungen bestehen. Viele Web Service-Anbieter einschließlich Microsoft stimmen darin überein, dass ein flexibleres Transaktionsmodell auf dem Gebiet der Web Services benötigt wird. Derzeit finden viele Entwicklungen in diesem Bereich statt. Bis ein allgemeiner Ansatz für Web Service-Transaktionen definiert ist, können Sie bei Bedarf mittels lokaler oder deklarativer Transaktionen eigene Kompensationsschemata implementieren.

Auswählen einer Architektur

Wenn Sie eine verteilte Anwendung entwerfen, die mit .NET ausgeführt werden soll, lesen Sie diesen Artikel sorgfältig durch, damit Sie anschließend die richtigen Schlüsse für die Architektur Ihres Systems ziehen können. Dies ist im Allgemeinen leichter als Sie zunächst vielleicht glauben. Abgesehen von den immer wieder auftretenden Sonderfällen, die natürlich gesondert zu handhaben sind, gibt es einige allgemeine Aussagen, die Ihnen die Arbeit erleichtern.

Erstens: Verwenden Sie standardmäßig die ASP.NET Web Services. Diese sind einfacher zu implementieren und zu verwenden, bieten die größtmögliche Reichweite in Bezug auf Clientplattformen, und der Clientproxycode von ASP.NET Web Services kann über einen Code aufgerufen werden, der in einer Sandbox entsprechend der standardmäßigen Sicherheitsrichtlinie ausgeführt wird.

Wenn Sie ein eher traditionelles verteiltes Objektmodell mit allen CLR-Eigenschaften wünschen, keine Interoperabilität mit anderen Plattformen benötigen und sowohl die Konfiguration der Clients als auch der Server regeln, dann sollten Sie sich für .NET Remoting entscheiden. Wenn Sie mit .NET Remoting arbeiten, sollten Sie einen in IIS und ASP.NET integrierten HTTP-Kanal vorziehen. Andernfalls müssen Sie eine eigene Verwaltung für den Prozesslebenszyklus und die Sicherheitsinfrastruktur entwickeln. Vorausgesetzt, .NET Remoting benötigt einen .NET-Client, dann sollten Sie ein binäres Formatierungsprogramm anstelle eines SOAP-Formatierungsprogramms verwenden, da die Interoperabilität keine Rolle spielt und sich die Leistung deutlich erhöht.

Arbeiten Sie mit Enterprise Services (COM+), wenn Sie deklarative Transaktionen benötigen. Wenn Sie ServicedComponents implementieren, sollten Sie diese aus Gründen der Leistungsfähigkeit in Bibliotheksanwendungen bereitstellen. Möchten Sie diese jedoch auf Remotecomputern ausführen, stellen Sie sie in Serveranwendungen bereit. (Ziehen Sie ggf. auch COM+-Serveranwendungen in Betracht, wenn Sie Code mit einem anderen Prozesssicherheitstoken ausführen müssen als dem, der von aspnet_wp.exe verwendet wird, auch wenn dies auf demselben Computer geschieht.)
Nachfolgend drei allgemeine Architekturen, die auf den o.g. Ideen basieren:

Bild01

Abbildung 1: Eine einfache 3-tier-Architektur

Abbildung 1 zeigt eine einfache 3-tier-Architektur, bei der die Webserverfarm verschiedene Clients unterstützt. Der gesamte serverseitige Code wird im ASP.NET-Workerprozess aspnet_wp.exe ausgeführt. Die drei verschiedenen Clients greifen über HTTP auf die Serverfarm zu. Browserbasierte Clients rufen ASP.NET-Webseiten auf; Rich Clients (z.B. Windows Forms-Anwendungen, Microsoft® Visual Basic®6-Anwendungen) und andere Web Services verwenden ASP.NET Web Services und .NET-Rich Clients (z.B. Windows Forms-Anwendungen), und Web Services verwenden bei Bedarf ASP.NET Web Services oder .NET Remoting mit dem HTTP-Kanal und einem binären Formatierungsprogramm (sofern nicht in der Sandbox enthalten).

Bild02

Abbildung 2: n-tier-Architektur mit ASP.NET

Einige sehr große Anwendungen verwenden einen zweiten Computersatz, um Arbeit aus der äußeren Ebene der Webserver umzuschichten. Ein Beispiel einer solchen Architektur sehen Sie in Abbildung 2. Beachten Sie, dass in diesem Fall die zweite Ebene Funktionen ebenfalls über ASP.NET zur Verfügung stellt.

Bild03

Abbildung 3: n-tier-Architektur mit Enterprise Services (COM+)

Abbildung 3 zeigt eine alternative Version dieser Architektur, bei der die zweite Ebene Funktionen über in COM+ bereitgestellte ServicedComponents bereitstellt.

Dies sind natürlich nicht alle Architekturen, die von .NET Framework unterstützt werden. Sie bilden jedoch eine gute Ausgangslage für eigene Systeme.

Zusammenfassung

Sowohl die .NET-Remoting-Infrastruktur als auch die ASP.NET Web Services ermöglichen eine prozessübergreifende Kommunikation, wobei beide jeweils andere Vorteile bereithalten. ASP.NET Web Services bieten ein einfaches Programmiermodell mit großer Reichweite an.

.NET Remoting dagegen stellt ein komplexeres Programmiermodell mit deutlich eingeschränkter Reichweite bereit. Um sich für die richtige Technologie zu entscheiden, ist es wichtig zu wissen, wie diese funktionieren. In beiden Fällen sollten Sie auf IIS und ASP.NET zurückgreifen, um Prozesslebenszyklen zu verwalten und allgemeine Sicherheitsstandards zu gewährleisten.


Anzeigen: