Ich hatte schon mehrfach überlegt das komplette SHC noch einmal neu in Java auf zu bauen. Diese Idee aber aufgrund des Aufwandes erst einmal wieder verworfen.
Nachdem ich nun angefangen habe die neuen Funktionen für Version 2.4 zu programmieren. Musste ich immer wieder feststellen das, dass aktuelle Konzept zu schwerfällig geworden ist. Also vor allem was Erweiterungen angeht, aber auch was die Performance angeht.
Aktueller Stand ist wie die meisten ja wissen das der Scheduler recht instabil wird sobald man ein paar mehr Funktionen einstellt. Nach langem überlegen und einigen Tests musste ich nun auch zu der Erkenntnis kommen das der Java Scheduler da auch nicht viel daran ändern kann. Da das Konzept darunter schon nicht perfekt passt.
Diese und einige weitere Erkenntnisse haben mich nun doch dazu bewegt noch einmal eine neue Basis auf zu bauen, diese möchte ich euch jetzt einmal kurz Vorstellen.
Das ganze Projekt wird weitestgehend in Java geschrieben sein, das macht es auch für mich einfacher. Allerdings werden eigene Erweiterungen schwieriger.
Voraussetzung ist dann Java 8.
Das ganze ist dann so aufgeteilt das es einen Server gibt der eine JSON Schnittstelle bereitstellt, aber selbst keine Grafikoberfläche. Über diese JSON Schnittstelle wird es mehrere Clients geben welche die Anzeige auf bestimmten Systemen übernehmen.
Das komplette Projekt SHC wird in mehrere eigenständige Module zerlegt:
SHC_Core:
Der Core bildet die Basisdaten des SHC ab (z.B.: Benutzer, schaltbare Elemente, Sensoren, ...) enthält aber keine Geschäftslogik.
SHC_Application_Server:
Der Application Server bildet das neue Herz. Er wird sich um die Abarbeitung der Aufgaben kümmern (die Funktionen des jetzigen Schedulers). Zudem wird er die komplette Datenhaltung verwalten. Im Gegensatz zum jetzigen Zustand das für jede Aufgabe alle Daten aus der Datenbank geholt, verarbeitet und geschrieben werden, wird der Server alle Daten selbst verwalten und in der Datenbank nur zyklisch ein Abbild ablegen. Dieses Abbild dient dann nur dazu das nach einem Neustart die Daten wieder geladen werden können. Das hat zum einen den Vorteil das sehr viel weniger Datenbankoperationen durchgeführt werden müssen. Zum anderen auch das die Daten an einem Ort immer aktuell sind.
Der Application Server nutzt die Daten des Core als Basis und Stellt eine umfangreiche Json Schnittstelle über einen eingebetteten HTTP-Server zur Verfügung.
(Der Application Server besitzt keine eigene Grafikoberfläche und wird über die Kommandozeile bedient)
SHC_Switch_Server:
Übernimmt die Funktionen des jetzigen Switch Servers. Das Dezentrale konzept des SHC bleibt also erhalten.
[u]SHC_Sensor_Transmitter:
[/u]Übernimmt die Funktionen des jetzigen Sensor Transmitters. Die HTTP Schnittstelle zum Empfangen der Sensordaten bleibt gleich, die URL wird sich aber ein wenig ändern.
SHC_CLI_Client:
Der CLI Client ermöglicht es die Funktionen des SHC über die Kommandozeile zu schalten.
SHC_Desktop Client:
Der Desktop Client bildet die neue Haupoberfläche, es können also alle Schaltfunktionen und Verwaltungsfunktionen genutzt werden. Für die Grafikoberfläche ist geplant JavaFX 8 zu verwenden, dafür wird Java 8 mit mindestens Update 40 benötigt. Das bedeutet aber auch das diese Oberfläche nicht auf dem Raspberry Pi selbst läuft (zumindest vorerst), da soweit ich weiß Oracle Java 8 Update 40 noch nicht für den RPi erschienen ist.
SHC_Android_Client:
Der Android Client wird wie der Desktop Client vollen Funktionsumfang erhalten und von der Programmierung etwas effizienter aufgebaut sein als die aktuelle App.
SHC_Web_Client:
Der Web Client wird die Oberfläche zum schalten von SHC Funktionen für den Browser als Desktop und Mobile Webseite bereitstellen. Der Web Client wird vorerst keine Verwaltungsfunktionen erhalten.
Release und Funktionsumfang:
Die Einzelnen Module (ausgenommen dem SHC_Core) werden dann mit jedem Release als einzelne ausführbare Jar Dateien ausgeliefert, was auch den Release stabiler machen sollte. Es wird also nicht mehr mit "git clone" gearbeitet was ohnehin nicht so funktioniert hat wie ich mir das vorgestellt hatte.
Geplant ist der Release mit dem Funktionsumfang wie ich ihn für Version 2.4 vorgesehen hatte.
-> https://github.com/agent4788/SHC_Application_Framework
Bei Fragen, Anregungen, Kritik usw. immer raus damit.
Nachdem ich nun angefangen habe die neuen Funktionen für Version 2.4 zu programmieren. Musste ich immer wieder feststellen das, dass aktuelle Konzept zu schwerfällig geworden ist. Also vor allem was Erweiterungen angeht, aber auch was die Performance angeht.
Aktueller Stand ist wie die meisten ja wissen das der Scheduler recht instabil wird sobald man ein paar mehr Funktionen einstellt. Nach langem überlegen und einigen Tests musste ich nun auch zu der Erkenntnis kommen das der Java Scheduler da auch nicht viel daran ändern kann. Da das Konzept darunter schon nicht perfekt passt.
Diese und einige weitere Erkenntnisse haben mich nun doch dazu bewegt noch einmal eine neue Basis auf zu bauen, diese möchte ich euch jetzt einmal kurz Vorstellen.
Das ganze Projekt wird weitestgehend in Java geschrieben sein, das macht es auch für mich einfacher. Allerdings werden eigene Erweiterungen schwieriger.
Voraussetzung ist dann Java 8.
Das ganze ist dann so aufgeteilt das es einen Server gibt der eine JSON Schnittstelle bereitstellt, aber selbst keine Grafikoberfläche. Über diese JSON Schnittstelle wird es mehrere Clients geben welche die Anzeige auf bestimmten Systemen übernehmen.
Das komplette Projekt SHC wird in mehrere eigenständige Module zerlegt:
SHC_Core:
Der Core bildet die Basisdaten des SHC ab (z.B.: Benutzer, schaltbare Elemente, Sensoren, ...) enthält aber keine Geschäftslogik.
SHC_Application_Server:
Der Application Server bildet das neue Herz. Er wird sich um die Abarbeitung der Aufgaben kümmern (die Funktionen des jetzigen Schedulers). Zudem wird er die komplette Datenhaltung verwalten. Im Gegensatz zum jetzigen Zustand das für jede Aufgabe alle Daten aus der Datenbank geholt, verarbeitet und geschrieben werden, wird der Server alle Daten selbst verwalten und in der Datenbank nur zyklisch ein Abbild ablegen. Dieses Abbild dient dann nur dazu das nach einem Neustart die Daten wieder geladen werden können. Das hat zum einen den Vorteil das sehr viel weniger Datenbankoperationen durchgeführt werden müssen. Zum anderen auch das die Daten an einem Ort immer aktuell sind.
Der Application Server nutzt die Daten des Core als Basis und Stellt eine umfangreiche Json Schnittstelle über einen eingebetteten HTTP-Server zur Verfügung.
(Der Application Server besitzt keine eigene Grafikoberfläche und wird über die Kommandozeile bedient)
SHC_Switch_Server:
Übernimmt die Funktionen des jetzigen Switch Servers. Das Dezentrale konzept des SHC bleibt also erhalten.
[u]SHC_Sensor_Transmitter:
[/u]Übernimmt die Funktionen des jetzigen Sensor Transmitters. Die HTTP Schnittstelle zum Empfangen der Sensordaten bleibt gleich, die URL wird sich aber ein wenig ändern.
SHC_CLI_Client:
Der CLI Client ermöglicht es die Funktionen des SHC über die Kommandozeile zu schalten.
SHC_Desktop Client:
Der Desktop Client bildet die neue Haupoberfläche, es können also alle Schaltfunktionen und Verwaltungsfunktionen genutzt werden. Für die Grafikoberfläche ist geplant JavaFX 8 zu verwenden, dafür wird Java 8 mit mindestens Update 40 benötigt. Das bedeutet aber auch das diese Oberfläche nicht auf dem Raspberry Pi selbst läuft (zumindest vorerst), da soweit ich weiß Oracle Java 8 Update 40 noch nicht für den RPi erschienen ist.
SHC_Android_Client:
Der Android Client wird wie der Desktop Client vollen Funktionsumfang erhalten und von der Programmierung etwas effizienter aufgebaut sein als die aktuelle App.
SHC_Web_Client:
Der Web Client wird die Oberfläche zum schalten von SHC Funktionen für den Browser als Desktop und Mobile Webseite bereitstellen. Der Web Client wird vorerst keine Verwaltungsfunktionen erhalten.
Release und Funktionsumfang:
Die Einzelnen Module (ausgenommen dem SHC_Core) werden dann mit jedem Release als einzelne ausführbare Jar Dateien ausgeliefert, was auch den Release stabiler machen sollte. Es wird also nicht mehr mit "git clone" gearbeitet was ohnehin nicht so funktioniert hat wie ich mir das vorgestellt hatte.
Geplant ist der Release mit dem Funktionsumfang wie ich ihn für Version 2.4 vorgesehen hatte.
-> https://github.com/agent4788/SHC_Application_Framework
Bei Fragen, Anregungen, Kritik usw. immer raus damit.