Remoting oder Web Services?

Wenn man eine Anwendung entwirft, ist die Performance immer ein entscheidender Faktor. Falls man in einer kontrollierten Umgebung wie einem LAN oder WAN arbeitet, ist Remoting dank der Unterstützung von TCP eine gute Wahl, da dieses Protokoll wesentlich schneller ist als HTTP. Damit entfällt auch ein Wrapper wie SOAP, wo Daten für die Übertragung verpackt und am anderen Ende wieder entpackt werden müssen. Demgegenüber verwendet Remoting an jedem Ende .NET, so dass man die verfügbaren Datentypen problemlos benutzen kann.

Außerdem kann man zwar auch zustandsorientierte Web Services erstellen, aber diese Funktion ist mit Remoting wesentlich einfacher umzusetzen. Dies hängt von den Anforderungen der Anwendung ab. Wenn man weiß, dass jeder Punkt oder jede Schicht der Anwendung .NET benutzt, dann spricht alles für Remoting. Andererseits könnte sich eine Anwendungsschicht in der Zukunft ändern, so dass Web Services in einem solchen Fall für mehr Flexibilität sorgen würden. Web Services sind standardkonform, daher sollte das Zusammenspiel mit anderen Systemen problemlos funktionieren. Web Services können allerdings zu Problemen führen, wenn man mit Funknetzen arbeitet.

Die letzte Entscheidung bleibt dem Anwendungsarchitekten vorbehalten. Einige Aspekte können allerdings die Entscheidung leichter machen. Wenn zum Beispiel nicht alle Schichten der Anwendung .NET verwenden, ist Remoting keine Option. Remoting erfordert eine enge Kopplung der Anwendungs-Clients. Daher ist dessen Peer-to-Peer-Verfahren womöglich für eine bestimmte Anwendung nicht geeignet oder erwünscht. Eine entsprechende Architektur vorausgesetzt, ist Remoting wesentlich schneller. Web Services sind dafür flexibler, was für ihren Einsatz spricht, falls mit künftigen Änderungen der Anwendung zu rechnen ist. Sie bieten für künftige Weiterentwicklungen mehr Ansatzpunkte, was nützlich ist, falls man in Zukunft Authentifizierung ergänzen muss oder WSE-Funktionen nutzen will (Web Services Enhancements).