Categories: Software

Remoting oder Web Services?

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.

Page: 1 2 3

ZDNet.de Redaktion

Recent Posts

Microsoft nennt weitere Details zu kostenpflichtigen Patches für Windows 10

Erstmals liegen Preise für Verbraucher vor. Sie zahlen weniger als Geschäftskunden. Dafür beschränkt Microsoft den…

4 Stunden ago

Microsoft verschiebt erneut Copilot Recall

Die Entwickler arbeiten noch an weiteren „Verfeinerungen“. Windows Insider erhalten nun wohl eine erste Vorschau…

22 Stunden ago

GenKI im Job: Mitarbeitende schaffen Tatsachen

Laut Bitkom-Umfrage werden in jedem dritten Unternehmen in Deutschland private KI-Zugänge genutzt. Tendenz steigend.

1 Tag ago

97 Prozent der Großunternehmen melden Cyber-Vorfälle

2023 erlitten neun von zehn Unternehmen in der DACH-Region Umsatzverluste und Kurseinbrüche in Folge von…

1 Tag ago

„Pacific Rim“-Report: riesiges, gegnerisches Angriffs-Ökosystem

Der Report „Pacific Rim“ von Sophos beschreibt Katz-und-Maus-Spiel aus Angriffs- und Verteidigungsoperationen mit staatlich unterstützten…

1 Tag ago

DeepL setzt erstmals auf NVIDIA DGX SuperPOD mit DGX GB200-Systemen

NVIDIA DGX SuperPOD soll voraussichtlich Mitte 2025 in Betrieb genommen und für Forschungsberechnungen genutzt werden.

1 Tag ago