Der Prototyp soll in der Erprobungsphase den Abstieg vom HTTP- bis hin zum EIB-Protokoll, das Schalten eines Verbrauchers und das Auslesen des ComClient-Buffers, der den Busverkehr des EIB protokolliert, in der relationalen Datenbank Openbase ermöglichen. Dabei ist eine Routerkopplung, wie im 1.Entwurf des Systems vorgeschlagen, nicht von Bedeutung, da diese keine Änderung der Funktionsweise des Prototypens erfordert, wie bei der Betrachtung des ComClient zu sehen ist. Der ComClient bietet die Möglichkeit der Angabe eines Gateways, das benutzt wird, um mit anderen Netzwerken über einen Router in Kontakt zu treten. Somit ist die LAN/WAN-Kommunikation nach Einrichtung einer Routerstrecke hergestellt.
Nach der Realisierung dieses Kommunikationsweges soll dann die Möglichkeit einer verteilten Anwendung mit Anlehnung an die CORBA-Spezifizierung aufgezeigt werden.
Somit wurde ein Testaufbau nach dem 2. Entwurf, der unter 3.1 im Systementwurf vorgestellt wurde, realisiert. Das Gebäudeautomationssystem entspricht der unter 3.2 vorgestellten Schaltung.
Die Software, die zur Lösung diese Problems erstellt werden muß, basiert auf den WebObjekts-Technologien, die von der Firma Apple vertrieben werden. Diese bieten die Möglichkeit die gesamten Kommunikationswege, mit Hilfe der in den Technologien enthaltenen Frameworks und Bibliotheken, zu realisieren.
Die Software setzt sich aus den folgenden Modulen zusammen:
* Kommunikationsschnittstelle: Das Kommunikationsinterface wird mit WebObjetcs, das einen "low cost"-Zugriff (hiermit ist die Kommunikation über die CGI-Schnittstelle gemeint) auf die anderen Module ermöglicht, formuliert.
* Datenbankzugriff: Der Datenbankzugriff erfolgt über Enterprise Objekts Frameword (EOF), das über ein objekt-relationales Model den Zugriff auf die relationale Datenbank Openbase 5 ermöglicht. EOF bietet eine netzwerkweite und adaptive Zugriffsmöglichkeit auf ein weites Spektrum von relationalen Datenbanken und eine komfortable Schnittstelle für die WebObjects Integration.
* Netwerkkommunikation: Durch die Möglichkeit binäre WebObjects-Applikationen zu erstellen, kann unter Einbindung der BSD-Socket-Interface-Bibliothek ein TCP/IP-Netzwerkkommunikationsmodul erstellt werden.
* Objekt-Server Modul: Die im zweiten Schritt geforderte Realisierung einer exemplarisch verteilten Anwendung unter Berücksichtigung der CORBA-Spezifikation, kann mit der Distributed Objects (DO) Technologie[23] realisiert werden. Die CORBA-Spezifikation mit ihrem Angebot an Diensten und ihrer Sprachunabhängigkeit ist mit DO zwar nicht realisiert, jedoch werden, wie bei der RMI-Kommunikation von Java, die Grundmechanismen für die CORBA-Implementierung bereitgestellt. Da eine CORBA-Maschine den finanziellen Rahmen überschreiten würde und die Begründung für einen weiteren Einsatz erschwert, hat man sich für den Einsatz der DO-Technologie entschieden, um die Möglichkeit eines weiteren Ausbaus mit der Annäherung an die CORBA-Spezifikation zu haben. In einer späten Phase der Diplomarbeit wurde zusätzlich bekannt, daß die Firma Apple bestrebt ist, eine Anbindung an bestehende CORBA-Maschinen für die DO-Technogie zu entwickeln. In diesem Zusammenhang wird jedoch auf die Fertigstellung des neuen Betriebssystems[24] gewartet.
Nach diesen Ausführungen können für die softwareseitige Lösung die folgenden Modulszenarien vorgestellt werden.
Aufbau der Kommunikation mit den zu realisierenden Softwaremodulen:
Abb. 38 : Softwaremodule ohne Distributed Objects´Technologie
Abb. 39 : Softwaremodule mit Distributed Objekts´Technologie
In den obigen Abbildungen ist deutlich die Abgrenzung der einzelnen Module zu erkennen und in wieweit diese zusammenarbeiten. Die Kommunikation zwischen den Modulen findet über den Messaging-Mechanismus der Objektiv-C Technologie[25] statt. Die symbolische Ausgabe der HTML-Seiten vom Kommunikationsschnittstellen-Modul erfolgt über das Protokoll der CGI-Schnittstelle.
Siehe Grundlagen "2.6.7: Distributed Objects".
[24] Code-Name Rhapsody
[25] siehe Anhang 1: "Die Basics der Programmiersprache Objective-C".