Implementation

Das Remote-Management ist im CommunityMirror im Paket org.sociotech.cmf3.remote umgesetzt. Dabei wird zwischen zwei hauptsächlich relevanten Komponenten unterschieden:

1. Den (Remote-)Functionalities, welche fachliche Methoden definieren, die von außerhalb aufgerufen werden können, zu finden unterhalb von org.sociotech.cmf3.remote.functionality
2. Den Connectors, welche verschiedene technische Möglichkeiten für den entfernten Zugriff implementieren, zu finden in org.sociotech.cmf3.remote.connectors

Über die Konfiguration kann vor dem Start des CM die Remote-Erreichbarkeit eingeschaltet und ein Connector (oder mehrere) ausgewählt werden. Je nach Connector sind evtl. weitere Konfigurationsparameter benötigt. Dies kann im einfachsten Fall z.B. so aussehen:

# settings for remote management
mirror.remote.enable = true
mirror.remote.interface = SimpleHttp
mirror.remote.port = 8080

Mit diesen Einstellungen startet der RemoteManager einen lokalen HTTP-Server, der im Browser unter http://localhost:8080/ erreicht werden kann.

Es ist möglich, mehrere Connectors in der Konfiguration anzugeben (Komma-getrennt). In dem Fall ist die Remote-Schnittstelle dieser CM-Instanz über mehrere Wege verfügbar. Parameter für die einzelnen Connectors können in diesem Fall im Config-Namensraum nach Connector-Name differenziert werden (z.B. "mirror.remote.simplehttp.port").

Wir gehen grundsätzlich davon aus, dass der Client die für ihn nötigen Schnittstellen bereits zur Entwicklungszeit kennt, die Remote-Schnittstelle ist also üblicherweise nicht interaktiv explorierbar. Es bleibt den einzelnen Connectors jedoch überlassen, wie die Darstellung der Functionalities jeweils passiert - ein Index der aktuell verfügbaren Functionalities und ihrer Methoden könnte durchaus nützlich sein. Ein Connector, der ein vollumfängliches Management-Web-Interface anbietet, wäre für die Zukunft denkbar.

Functionalities

Die Remote-Functionalities sind der interessante/fachliche Teil des Remote-Managements. Hier sind die Schnittstellen für abfragbare Informationen und anstoßbare Aktionen definiert. Eine Functionality-Einheit sollte inhaltlich verwandte Schnittstellen sinnvoll bündeln und sich an die API-Konventionen halten.

Application

In dieser Functionality sind Schnittstellen verortet, die sich auf die CM-Anwendung als Ganzes beziehen (etwa entsprechend der Klasse CommunityMirror). Sie bietet Zugriff auf die Konfiguration der Anwendung und erlaubt einen Neustart des Views.

Runtime

Die Runtime-Functionality erlaubt den Zugriff auf Informationen zur Java-Laufzeitumgebung. Beispielsweise kann hier die Java-Version, die Systemumgebungsvariablen oder das Kompilierdatum der laufenden CM-Anwendung abgefragt werden. Auch Angaben zum Speicherverbrauch finden sich hier.

FlowView

Hier sind Funktionen zu finden, die sich spezifisch auf die FlowView-Klasse beziehen, z.B. kann die Anzahl der aktuell angezeigten Flow-Elemente abgefragt werden.

OperatingSystem

In dieser Functionality ist eine Schnittstelle für ein externes Tool definiert, welches für das Management von Windows-Rechnern verwendet werden kann. Hiermit ist es dem CMF möglich, Windows neu zu starten oder herunterzufahren, sowie den Bildschirm in den Standby-Modus zu versetzen.

Hierfür muss nircmd.exe in die Ressourcen der Java-Anwendung eingebunden und als Teil der jar-Datei ausgeliefert werden. Vorsicht: Die Präsenz des Programms kann Virenscanner verwirren.

API-Konventionen für Functionalities

Jede öffentliche ("public") Methode der Functionality ist Teil der Schnittstelle nach außen und sollte entsprechend einen sinnvoll gewählten Namen haben.

get*-Methoden dienen der reinen Abfrage von Informationen. Eine solche Methode sollte keine Änderungen an der laufenden Anwendung vornehmen und sollte mit möglichst wenig Rechenzeit bearbeitbar sein.

do*-Methoden lösen Aktionen aus, die in der laufenden Anwendung eine Zustandsänderung bewirken. Diese muss nicht notwendigerweise im laufenden Betrieb sichtbar sein (z.B. Neuladen von Caches).

Es gibt derzeit noch keine Möglichkeit zur Übergabe von Parametern und entsprechend auch noch keine set-Methoden.

Connectors

Im CMF-Hauptprojekt sind die folgenden Connectors verfügbar. In Anwendungsprojekten können weitere mitgeliefert werden.

SimpleHttp

Dieser Connector benutzt com.sun.net.httpserver.HttpServer um Remote-Zugriff via HTTP zu erlauben. Auf dem gleichen Rechner via localhost, z.B. während der Entwicklung von neuen Functionalities, sollte dies immer funktionieren. Jedoch gibt es keine Möglichkeiten zur Authentisierung oder Zugriffsbeschränkung, weshalb der Server standardmäßig nur auf lokale Anfragen lauscht. Wird in der Konfiguration mirror.remote.allowExternal auf true gesetzt, dann erlaubt der Server auch Zugriffe über andere Rechner im Netzwerk bzw. Internet. Dies funktioniert jedoch auch dann nur, wenn keine Firewall oder NAT im Weg ist.

SimpleHTTP zeigt unter http://localhost:8080/_index eine Liste aller aktiven Functionalities an. Jede davon entspricht einem HTTP-"Verzeichnis". Die jeweiligen Methoden tauchen dann im Pfad als "Datei" auf, z.B. http://localhost:8080/Application/getFPS. Auch hier ist eine Liste der möglichen Methoden unter "_index" verfügbar.

HttpMessageGateway

Hierbei handelt es sich um eine abgewandelte Version von SimpleHttp, welche in Situationen eingesetzt werden kann, in denen ein lokaler HTTP-Server aus netzwerktechnischen Gründen nicht betrieben werden kann odern nicht erreichbar wäre. Statt die Functionalities über einen eigenen Server anzubieten, wird in der Konfiguration ein statischer Drittserver angegeben, welcher als Medium zwischen Client und CommunityMirror fungiert. Sowohl Client als auch CM sind hier HTTP-Clients im technischen Sinne, d.h. dieser Connector sollte in quasi jedem Netzwerk funktionieren, in dem der CM Internet-URLs aufrufen kann.

Im Hintergrund gibt es eine URL auf dem externen Server, die vom CM alle paar Sekunden nach anstehenden Anfragen abgefragt wird. Deshalb ist diese "Notlösung" normalerweise deutlich langsamer als ein direkterer Weg.

Auf dem Server muss ein passendes Programm laufen, welches die Nachrichtenweiterleitung im passenden Format übernimmt. Das Gegenstück zur Java-Seite ist in diesem Fall in PHP implementiert.

Anforderungen / To Do

Es folgt eine Reihe von denkbaren Ergänzungen/Verbesserungen des Remote-Managements. Auch jenseits von diesen Punkten kann noch vieles ergänzt werden.

Log-Zugriff

Es wäre hilfreich, per Remote-Schnittstelle auf die Log-Einträge der derzeit laufenden Anwendung zugreifen zu können, in etwa so wie sie lokal im Konsolenfenster bzw. in Eclipse angezeigt werden. log4j bietet keinen Zugriff auf vergangene Log-Einträge des aktuellen Prozesses, deshalb müssen die entsprechenden Logger-Events im Hintergrund mitprotokolliert werden. In log4j-Jargon ausgedrückt muss hierfür ein eigener Appender geschrieben werden (siehe z.B. hier) oder es müssen bereits bestehende log4j-Schnittstellen, etwa der Syslog-Appender, über die Remote-Schnittstelle nutzbar gemacht werden.

Hardware-Functionality

Java ist "by design" von der konkreten Hardware abstrahiert und bietet keinen genauen Zugriff auf Informationen oder Aktionen zur Hardware. Jedoch gibt es die Möglichkeit, externe Windows-Tools einzubinden und vom Java-Code aus aufzurufen - für die Sprachausgabe in UrbanLife+ wurde das schon mal so gemacht.

Eine neue Functionality zum Thema Hardware könnte ein externes Tool einbauen, das die Abfrage von Hardware-Parametern erlaubt, z.B. welcher Prozessor ist verbaut (Hersteller, Modell, Geschwindigkeit), welche Grafikkarte ist im Einsatz und welcher Bildschirm (ebenfalls Hersteller und Modell). Weiterhin könnte ein externes Tool uns die Möglichkeit bieten, den Bildschirm aus der Ferne in den Energiesparmodus zu versetzen und wieder aufzuwecken.

Falls dies umgesetzt wird, könnten einige Methoden aus der Runtime-Functionality (z.B. Gesamtgröße Arbeitsspeicher) hierher wandern.

Mashup-Functionality

Es gibt bisher noch keine Möglichkeit zum (View-unabhängigen) Zugriff auf das lokale Mashup. Hier wären Möglichkeiten zur Abfrage von Informationen zu Objekten interessant, sowie auch das Neuladen aller Inhalte oder Neustart des Mashups insgesamt.

Sicherheitskonzept

Die bestehenden Connectors erlauben noch keine vernünftige Zugangsbeschränkung oder Verschlüsselung. Hier sollte mittelfristig ein tragbares Konzept her.

• Kommunikation nur über HTTPS? (bei lokalem Server schwierig, bei HttpMessageGateway bereits möglich)
• Authentifizierung über Passwort (das in Konfiguration definiert ist) oder Zertifikat?

Push-Events

Es soll möglich sein automatisch Events zu verschicken, wenn bestimmte Ereignisse eintreten:

• Speicherbelegung über X
• Frames/Second unter X
• ...

Dafür gibt es derzeit noch keinen geeigneten Rahmen.