wircom
Goto Top

Konzeptionierung der Kommunikation zwischen Benutzeroberfläche und Anwendung

Liebe Community,
als neuer Ansatz einer für mich höchst interessante Aufgabe ergaben sich folgende Fragen, bei denen ich mir ein wenig Brainstorming erhoffe. Sorry für die vielen Infos vorab, aber ich denke mehr ist in dem Fall besser als zu wenig.

Gleiches Thema, anderer Ansatz wie Artikel: https://www.administrator.de/contentid/190885

Am Beispiel einer „Haussteuerung“ mit sehr vielen Sensoren und Aktoren. Sehr viel ist eine Größenordnung im tausender Bereich. Beispiel: Licht an/aus, Temperatur, Stellung und Steuerung der Jalousien. So was in etwa.

Hier existiert eine Software die teilweise in C++, Delphi und auch Java entwickelt und auch produktiv verwendet wird. Alles aus einem Guss (pro Entwickler), d.h. kein Trennung zwischen Dienst und Anwendung.
Warum das so entstanden ist? Weil quasi jede Abteilung, sagen wir mal Etagenweise selbst was entwickelt hat, was auch problemlos und gut funktioniert.
Auch hier hat die Globalisierung kein Halt gemacht und die Etagen sollen miteinander reden und gemeinsam Ressourcen bündeln. Und vor allen Dingen sollen die Anwendungen auch von den Oberflächen getrennt werden, wie auch Microsoft das empfiehlt. Es soll eine gemeinsame Entwicklungsfortschrift erstellt werden, die für jeden Entwickler bindet ist.
Die Abteilung sollen jeweils für sich Ihre Sensoren und Aktoren weiter betreuen und programmieren und „was weiß ich noch alles für komische Sachen damit machen“. Jeder für sich, in der Programmiersprache die der Programmierer vorzieht.
Allerdings möchte man eine GUI, sprich Oberfläche haben die gemeinsam entwickelt wird oder werden kann, in den gleichen Strukturen herrschen (Etagenübergreifend).
Somit soll man die Oberfläche irgendwie an die Anwendung anflanschen können, nach Möglichkeit Programmiersprachen unabhängig. Plattformunabhängig muss aber nicht sein. Damit könnte man sich über die Oberfläche den Status der hinterlegten Sensoren/Aktoren abfragen und ggf. auch aktiv eingreifen. (Jalousien hoch fahren, Heizung einschalten/ausschalten)…..
Ebenfalls möchte die IT gerne wissen, wann beispielsweise irgendwelche Temperaturen aus dem Ruder laufen, ob jemand im Serverraum das Licht vergessen hat auszumachen usw., als Monitoring Dienst.

Der globale Ansatz der dafür in Betracht kommt ist das SOA Service Orientierte Architektur.
Die Abteilungsleiter (der Etagen) würde ich dann mit der SOA-Governance definieren.
Die anderen Geschäftsprozesse, die im SOA beschrieben sind müssten dann natürlich aufgeschrieben und definiert werden, damit man eine allgemeingültige Vorschrift hat, an die sich jeder zu halten hat.

Anschließend Orchestriert man jeweils für die Oberfläche als auch für den Dienst einen Prozessablaufplan. Die Kopplung der beiden Prozesse, die das ganze miteinander verbindet, überwacht und auch kontrolliert wäre die Choreografie.
Das zum Strukturellen Aufbau (allgemein gesprochen)

Jetzt zum how to…
Ich möchte Dienst und GUI trennen. Ich möchte gerne den Dienst durch die IT Monitoren lassen. (Nagios oder so) Ich möchte eine Programmiersprachenunabhängige Kopplung haben, die einfach wie einen Adapter anflanschen kann durch irgendeine Bibliothek oder sonst irgendwie.
Der Kern der Frage zielt auf die Choreografie, oder das oben beschrieben „irgendwie“. Welches Protokoll bietet sich dafür an, dass sowohl den Dienst in C++, Delphi als auch Java unterstützt (denn die fertigen Produkte müssen beibehalten werden) Wie definiere ich den Adapter und Übertragungsprotokoll.
Hat da jemand eine Idee?
Meine favorisierte Idee ist einfach die Anbindung beider Prozesse an das SNMP Protokoll mit der MIB als Baumstruktur. Die nachfolgend definierten OID Werten schlüsseln mir genau auf, welche Lampe gerade welchen Status hat (Bezogen auf mein Beispiel der Haussteuerung).

Durch die send, get Befehle könnte ich dann jede Information übertragen als auch setzen. Die Trap Funktion würde mich sogar über „nicht angefragte“ Änderungen informieren. Sicherheit…müsste dann via SNMP V3 implementiert werden.
Das wie beschrieben meine Favorisierte Idee, ich bin für Gegenvorschläge offen und lasse mir auch gerne Sagen was für einen quatsch ich mir da überlegt habe…Dann würde ich euch aber um eine konkrete Antwort bitten.
Das Lösung Szenario muss nicht SNMP / MIB / OID heißen.
Falls jemand etwas anderes kennet, gerne, Kostenpflichtig ist hier KEIN „no go“. Sprich, wenn es eine fast fertige Lösung gibt kann man verhandeln ;)

Grüße
WirCom

Content-Key: 191034

Url: https://administrator.de/contentid/191034

Ausgedruckt am: 19.03.2024 um 03:03 Uhr