Da die Grundlagen zur Kommunikation mit dem ComClient geschaffen und die Mechanismen dazu in dem gleichnamigen Objekt implementiert wurden. kann jetzt die exemplarische Realisierung einer verteilten Anwendung, unter der Verwendung der Distributed Objects-Technologie[37], erfolgen.
Der Einsatz eines Objektservers, der unabhängig im lokalen Netzwerk ein Objekt und die Rechenleistung seines Systems anbietet, ist, wie in den Grundlagen unter der Thematik der verteilten Anwendungen beschrieben, das höhere Ziel unserer Zeit. Daher wird der Prototyp um diese Eigenschaft erweitert.
Der ORBServer[38] bietet das zuvor beschrieben ComClient-Objekt an. Somit ist jede Applikation, die DO-Technologie nutzt, in der Lage über den gleichnamigen Protokoll-wandler mit dem EIB-System zu kommunizieren. Eine Einschränkung bildet die Anzahl der zu einem Zeitpunkt mit dem ComClient in Verbindung stehenden Anwendung, da der Protokollwandler nur acht gleichzeitige Logins unterstützt.
So ist es denkbar, in einer späteren Anwendung mit der DO-Technologie, ein Objekt Request Broker zu implementieren, der sich an der CORBA-Spezifikation orientiert. Eine zentrale Entwicklung von Diensten und deren dezentrale Nutzung in einem Unternehmen, ist somit das nächst höhere Ziele in der evolutionären Entwicklung von Software.
Im folgenden will ich beispielhaft die Nutzung der DO-Technologie anhand dieses Prototypens erklären.
Abb. 63: Modell der DO-Technologienutzung
Der ORBServer bietet das ComClient-Objekt im Netzwerk an und wartet auf Anfragen von Client-Anwendungen, die diese Objekt benutzen wollen. Das ComClient-Objekt ist die zentrale Schnittstelle, die ,wie in der Abbildung oben zu sehen ist, verschiedene Dienste zur Kommunikation mit dem Protokollwandler unter Integration des OSNetwork-Objekts anbietet. Das OSNetwork-Objekt ist für die Socket-Kommunikation verantwortlich. Die Erweiterung des ComClient-Objekts, unter Integration zusätzlicher Objekte, würde somit eine beliebige Erweiterung des ORBServers ermöglichen.
Die Applikation, die den ORBServer darstellt, wird als Prozeß gestartet und kann nach einer kurzen Konfigurationssequenz das ComClient-Objekt anderen Anwendungen zur Verfügung stellen.
Abb. 64: Start und Konfigurationssequenz des ORBServers.
Als erstes wird ein NSAutoreleasePool Objekt (pool) geschaffen, das den Speicherbereich und die Verwaltungsmechanismen, für die im Laufe des ORBServer-Betriebes benutzten Objekte, schafft und für den Lebenszyklus der Objekte verantwortlich ist. Es gliedert sich automatisch in die Run-Loop der Runtime-Maschine ein.
Der darauf folgende Zeiger auf ein ComClient-Objekt, soll dann auf das später angebotene ComClient-Objekt verweisen.
Das NSConnection Objekt "defaultConn" ist für das Anbieten des ComClient-Objekt im Netwerk verantwortlich. Es setzt das zuvor gebildete Objekt "comclient" als zu offerierendes RootObjekt ein und registriert sich mit dem Namen @"ComClientServer" im Netzwerk. Über diesen Namen kann dann später eine Client-Anwendung mit dem ORBServer in Verbindung treten. Schlägt die Verbindung fehl, so wird der ORBServer mit einer Fehlermeldung beendet, wenn nicht, erfolgt eine Startmeldung und die Runtime-Maschine wird mit "[[NSRunLoop currentRunLoop] run];" gestartet. Nach Beenden des ORBServers erfolgt eine Freigabe des AutoreleasePools und der Programmausstieg.
Mit dieser einfachen Sequenz ist es möglich Objekte netzwerkweit anzubieten. Die gesamte Netzwerkkommunikation wird abstrahiert und ermöglicht die Verlagerung der Aktivitäten der Entwickler auf andere Programmteile.
Die Anbindung einer Client-Anwendung sieht dann wie folgt aus:
Abb. 65: Client-Seitige Anbindung an den ORBServer.
Auf der Client-Seite ist ein Dreizeiler, der es dann der Client-Anwendung ermöglicht, das vom ORBServer angebotene ComClient-Objekt anzufordern und zu nutzen. Als erstes wird wieder ein Objekt vom Type NSConnection geschaffen, das bei seiner Initialisierung sofort im lokalen Netzwerk nach dem ORBServer, der sich mit dem Namen "ComClientServer" registriert hat, sucht. Als weitere Option ist es möglich einen speziellen Rechner-Name anzugegeben, was in unserem Fall aber nicht von Bedeutung ist. Somit ist nach der Initialisierung der Kontakt zwischen Client und Server hergestellt[39]. Jetzt erfolgt die Zuweisung einer Referenz auf ein stellvertretendes Objekt, für das entfernte ComClient-Objekt, und die Vereinbarung eines Protokolls, über das die Client-Anwendung mit dem Server-Objekt kommunizieren kann. Die Protokollangabe ist lediglich als eine Vereinbarung anzusehen, die die vom ComClient-Objekt zur Verfügung gestellten Methoden beinhaltet.
Nach dieser Sequenz ist die Client-Anwendung möglich, mit Hilfe des ComClient-Objekts und des Protokollwandlers, eine Verbindung zum EIB-System herzustellen.
Siehe auch Kapitel 2.6.7 "Distributed Objects"
[38] In Anlehnung an die CORBA-Spezifikation, Objekt Request Broker (ORB) Server genannt. Wobei die Betonung auf "Anlehnung" liegt, da in Bezug auf Funktionalität und Umfang nicht von CORBA gesprochen werden kann.
[39] Für eine bildhafte Darstellung diese Vorgangs siehe Kapitel 2.6.7 "Distributed Objects".