RemObjects vs. RealThinClient

[taveuni]

Imho kann man RealThinClient nicht mit Remobjects vergleichen.
Wir setzen RealThinClient für eine eigene "Remotedesktop" Lösung ein -
was einigermassen funktioniert.

Remobjects aber ist ein Framework ohne welches wir uns nicht mehr vorstellen könnten
Multi-Tier Applikationen zu erstellen. Und dies auch mehr und mehr zwischen verschiedenen
Platformen und/oder Programmiersprachen.

Es nimmt dir die gesamte Kommunikation sowie das Protokoll ab. Du definierst Methoden und
Strukturen welche auf dem Client oder Server aufgerufen und übergeben werden. Auf der anderen
Seite genau gleich.

Die Performance ist ausschliesslich abhängig von der Umgebung. Für die einzelnen Channels können
sogar die darunterliegenden (Socket-)Frameworks gewählt werden (Indy, ICS, Synapse usw.).
Lade Dir einfach die Trial herunter und spiel damit herum.

[mjustin]

Zitat von taveuni:

Remobjects aber ist ein Framework ohne welches wir uns nicht mehr vorstellen könnten
Multi-Tier Applikationen zu erstellen. Und dies auch mehr und mehr zwischen verschiedenen
Platformen und/oder Programmiersprachen.

Es nimmt dir die gesamte Kommunikation sowie das Protokoll ab. Du definierst Methoden und
Strukturen welche auf dem Client oder Server aufgerufen und übergeben werden.

Auf Roberto Schneiders Blogseite ("DataSnap analysis based on Speed & Stability tests") wurde heute in einem Kommentar dargestellt, dass dieses Framework keine REST Unterstützung bietet (nach Angaben des RemObjects Support). Daher wurde es im Vergleich zwischen DataSnap, WCF, mORMot, Grizzly/Jersey und Node.js auch nicht berücksichtigt. Tests zeigten laut Roberto Schneiders, dass es eher noch schlechtere Performance zeigte als DataSnap (was aber eventuell mit Optimierungs'kniffen') verbessert werden kann).

REST ist wegen seiner leichtgewichtigen Architektur beliebt, die auch die Erstellung von Clients vereinfacht (man braucht nur eine HTTP Bibliothek).

RemObjects und DataSnap sind funktional mächtiger, aber auch "etwas" schwergewichtig. Dass bei DataSnap für jeden Request standardmäßig eine neue Session erzeugt wird (es sei denn, der Client sendet eine Session-ID im Request mit), ist ein Nachteil gegenüber Frameworks die neben sessionorientierter Arebitsweise auch eine rein requestbasierte Verarbeitung anbieten. Es wurde schon vorgeschlagen, die Kommunikationsschicht von DataSnap komplett neu zu bauen, und dann auf eine leistungsfähigere Architektur wie I/O Completion Ports (lockfrei) umzustellen. Das könnte die Anzahl Clients eines DataSnap-Servers um einen Faktor zehn bis tausend hochschrauben.