Remoting oder Web Services?

Microsoft preist Web Services als das Nonplusultra, aber die .NET-Plattform bietet Optionen, die noch über Web Services hinausgehen. Der folgende Artikel beschreibt, wann und wo Remoting der Vorzug gegenüber Web Services zu geben ist.

Viele Entwickler halten Web Services für die Standard-Lösung bei allen Aufgaben. Zwar funktionieren Web Services tatsächlich in vielen Situationen, aber es gibt auch Alternativen, die je nach Projekt noch angemessener sein können. Remoting ist ein gutes Beispiel, allerdings kann es schwierig zu entscheiden sein, wann man Remoting gegenüber Web Services den Vorzug geben sollte. Hier werden beide Technologien genauer unter die Lupe genommen, und es werden Entscheidungshilfen für den Einsatz dieser oder jener Technik angeboten.

Remoting

Das .NET-Framework enthält Remoting in der CLR (Common Language Runtime). Es stellt Klassen zur Verfügung, mit denen verteilte Anwendungen sowie Netzwerkdienste erstellt werden können, die Nachrichten über so genannte Channels versenden.

Remoting ermöglicht die Nutzung eines von zwei Channels (HTTP oder TCP) und ersetzt das DCOM (Distributed Component Object Model). Man kann Remoting in jeder Art von .NET-Anwendung benutzen, einschließlich Konsole, Windows Form, Windows Services und so weiter.

Es ist eine Reihe von Serialisierungsformaten für die Verwendung mit Remoting verfügbar. Standardmäßig verwendet der HTTP-Channel SOAP (Simple Object Access Protocol) und TCP das Binärformat. Dies sind allerdings nur die Standardeinstellungen, Channels können faktisch jedes beliebige Serialisierungsformat verwenden.

Für die Implementierung einer Remoting-Anwendung stehen mehrere Möglichkeiten bereit, darunter die folgenden:

  • SingleCall: Jeder Client-Request wird von einem neuen Objekt bearbeitet, dass nach Beendung der Verarbeitung zerstört wird.
  • Singleton: Alle eingehenden Client-Requests werden von einem einzigen Serverobjekt bearbeitet.
  • Client-aktiviertes Objekt: Dies ist das bekannte zustandsorientierte DCOM-Modell, bei dem der Client eine Referenz auf das Remoteobjekt erhält, diese Referenz beibehält und damit das Remoteobjekt bestehen lässt, bis er mit der Verarbeitung fertig ist.

Der wichtigste Aspekt bei Remoting ist, dass jeder Endpunkt im Prozess das .NET-Framework nutzen muss. Dadurch können Objekttypen zwischen den Endpunkten einfach ausgetauscht werden, da sie alle dieselbe Umgebung verwenden. Jedem Objekt wird eine so genannte lease time zugewiesen. Nachdem diese abgelaufen ist, wird das Objekt von der .NET Runtime-Remoting-Infrastruktur getrennt. Die Übergabe einer Objektreferenz führt zum Zugriff auf dasselbe Objekt mit Hilfe der Referenz – daher die Notwendigkeit von .NET an jedem Endpunkt.

Ein Remoteobjekt wird in einer Klasse implementiert, die von der Klasse System.MarshalByRefObject abgeleitet wird. Ein Client ruft Methoden über ein Proxy-Objekt auf, welches die erforderlichen Methoden des Remoteobjekts aufruft. Jede im Remoteobjekt definierte öffentliche Methode steht dem Client zur Verfügung. Daher kann man Remoting auch als Peer-to-Peer-Verfahren bezeichnen. Nun noch ein schneller Blick auf Web Services, ehe diese Technologie dem Remoting gegenübergestellt wird.

Themenseiten: Plattform, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Remoting oder Web Services?

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *