Ein jeder, der sich noch vage an Dinge wie Corba erinnern kann weiß, welch nette Idee hinter verteilten Objekten steckt: Ein Objekt wird als verteilt gekennzeichnet und wenn es mit einem geeigneten Parameter erzeugt wird, entsteht es auf einem anderen Rechner. Für die Anwendung sieht es aber wie ein lokales Objekt aus, auf das ganz normal zugegriffen werden kann. Hört sich toll an, führt in der Praxis jedoch zu allerlei Problemen, da die Zugriffe von den Launen des Netzwerks abhängig sind. Unter .NET wurde das Rad nochmal unter der Bezeichnung remoting neu erfunden.
Der Zugriff auf ein entferntes Objekt ist einfach, ein paar Zeilen genügen:
string url = string.Format("tcp://{0}:40506/LPT_IO_Server",
this.address);
this.remoteObj = (BaseRemoteObject)
Activator.GetObject( typeof(BaseRemoteObject), url);
Aber jetzt kommt das dicke Ende: Wenn der Server unten ist, bleibt die Anwendung beim Zugriff auf eines der Felder einfach hängen. Es gibt keine Möglichkeit, einen connection timeout einzustellen. Es dauert dann etwa 45 Sekunden, bevor eine SocketException anzeigt, daß da was schiefging. Nicht gut für eine Anwendung mit Benutzerinteraktion. Man kann sich allerdings "dreckig" behelfen, indem man den Zugriff in einen eigenen Thread packt:
Exception setException = null;
System.Threading.Thread setThread = new System.Threading.Thread( delegate()
{
try
{
this.remoteObj.setValue(value);
}
catch (Exception ex)
{
setException = ex;
}
});
setThread.Start();
if (setThread.Join((int)5000))
{
if (setException == null)
{
// everything seems to be A-OK
return true;
}
}
return false;
Das sieht nicht nur scheußlich aus sondern ist es auch. Aber so funktioniert es wenigstens. Jetzt bekommt man zwar auch eine Exception, aber asynchron. Ich finde es verwunderlich, daß M$ hier auf ein besseres Interface verzichtet hat. Hat man sich aber soweit vorgewühlt, ist die remoting Lösung eine sehr praktische Sache. Keine Socketprogrammierung, kein Marshaling, einfach nur die Objekte deklariert und es kann losgehen.
Meine Anwendung sieht folgendermaßen aus: Auf bis zu 8 entfernten Rechnern laufen Windows Services, die die Datenkanäle des LPT Ports schalten können. Das Interface besteht aus einer einzigen Funktion: setValue(byte). Auf einem zentralen Rechner kann man in einem Fenster alle entfernten Ports einzeln oder gleichzeitig schalten. Aus Remoting-Sicht ist dieser Rechner also der Client, der zu den entfernten Servern eine Verbindung aufbaut. Es ist wirklich phänomenal, wie schnell man zu einem Ergebnis kommt: Hätte ich o.g. Probleme nicht gehabt, wäre ich nach 5 Stunden (einschließlich der Setups) fertig gewesen.
Eine äußerst unterhaltsame Geschichte eines Londoner Mathematikdoktoranden, der eine großartige Erfindung macht: Er baut eine Maschine, mit der er die Vergangenheit fotografieren kann. Aufgrund der äußerst begrenzten Platzverhältnisse muß er die Konstruktion im Schlafzimmer aufbauen. Sein erster Versuch liefert den Beweis, daß seine Freundin doch nicht so treu ist, wie er gedacht hatte.. Bis auf ein paar Bugs die nahelegen, daß der Übersetzer keine besondere technische Affinitäten hat ("er klickte die Maus an..") ist es sehr flott zu lesen.
