Nach Fertigstellung einiger Module, die die Kommunikation zwischen Komponenten auf Dateiebene unterstützen, werde ich versuchen, verschiedene Interaktionsmetaphern bzw. Kommunikationsstrategien aus anderen datenflussgetriebenen Systemen in dWb+ nachzuvollziehen, um die Effizienz der Implementierung und die Vor- und Nachteile ihrer Anwendung diskutieren zu können.

Ich habe mehrere Module fertiggestellt, die in Workspaces die Arbeit mit Dateien erlauben. Da wäre zunächst ein DirectoryWatcher, der das Auftauchen von Dateien eines bestimmten Namensschemas in einem gewählten Verzeichnis an seinem Ausgang meldet. Weiterhin wurde ein Modul erstellt, das Dateien in eine gewähltes Zielverzeichnis kopiert. Auf Wunsch des Anwenders wird die Quelldatei dabei gelöscht. Daneben existiert noch ein Modul, das nur dem Löschen von Dateien dient. Schließlich wurde noch ein Modul entwickelt, das auf Empfang eines Dateinamens an seinem Eingang eine leereDatei gleichen Namens plus angehängtem, frei wählbarem Suffix erzeugt. Dies schließt den Kreis zu dem ersten genannten Modul: Dieses hatte ja die Aufgabe, auf die Erzeugung einer Datei hin den Namen dieser Datei weiterzumelden. Wenn aber das nächste Modul mit den Inhalten dieser Datei arbeiten möchte ist die Datei eventuell noch gar nicht fertig geschrieben, da ja das Anlegen der Datei detektiert wird - und das geschieht bereits mit Schreiben des ersten Datenbytes. Daher detektiert das Modul Dateien mit einem bestimmten Suffix - beispielsweise "trig". Findet es eine solche Datei, testet es, ob es eine Datei gibt die bis auf den Suffix denselben Namen trägt und meldet dann diesen Namen weiter. So kann man erst in aller Ruhe eine Datei namens "riesige Datei.mp4" schreiben und erst wenn man daneben eine Datei namens "riesige Datei.mp4.trig" anlegt, erkennt dWb+ das und beginnt mit der Arbeit an der Datei.

Weiterhin werde ich eine Kommunikationsstrategie testen, die - sozusagen als Seiteneffekt - automatisch einen Kontext für jede versendete Botschaft mitbringt. Dies ist ein Feature, das ich erst kürzlich zu dWb+ in seiner nativen Kommunikationsstrategie integriert habe. Die neue Interaktionsstrategie besteht nicht in einer neuen Implementierung, sondern baut auf der bestehenden nativen Strategie auf, interpretiert jedoch ihre Semantik neu: Es existiert pro Modul nur jeweils ein Eingang und eine beliebige Anzahl Ausgänge. Alle Daten, die zwischen Modulen ausgetauscht werden, haben denselben Typ - Arbeitstitel: HashMapMessage. Die Idee ist, dass jedes Modul, wenn es eine Message erhält, darin nach geeigneten Daten sucht und seine Ergebnisse in diese Message packt und sie dann weitersendet. Damit ist der Context automatisch da: die Message gestattet es nicht, Informationen wegzunehmen - es können nur immer neue dazu hinzugefügt werden. Das Problem dabei ist natürlich, dass es schwerer ist, damit Module zu bauen, die beliebig mit anderen kombiniert werden können- Aus Sicht von dWb+ können alle diese Module beliebig kombiniert werden. Das trifft auch dann zu, wenn ein Modul, das Bilder von einem Framegrabber an seinem Ausgang in die versendeten Messages packt, mit einem verbunden wird, das EMails versendet und daher eine Empfängeradresse in der empfangenen Message sucht. Nichtsdestotrotz existieren aber Szenarien, in denen diese Kommunikationsstrategie Vorteile bietet - speziell durch den nicht löschbaren und jederzeit nachvollziehbaren Kontext jeder Message. Man könnte sogar noch dafür sorgen, dass durch das System Audittrails an die Botschaften engehängt werden - etwa die Zeitpunkte der Übergabe zwischen den Modulen und die Module, die die Message bisher passiert hat.

Im Zuge der Umsetzung dieser Kommunikationsstrategie wird auch eine Möglichkeit prototypisch integriert, eine solche Funktionalität in die Verbindungen unabhängig von der Kommunikationsstrategie zu implementieren.

Weiterhin wird eine Möglichkeit untersucht werden, die Kommunikation zu entkoppeln - bisher funktioniert die Kommunikation direkt zwischen Modulen. Dazu werden immer PropertyChangeEvents benutzt. Lösungen zur Verteilung von Workspaces über mehrere Knoten werden immer innerhalb eines Moduls abgewickelt - sei es remoting, ejbs oder explizite Kommunikation übers Netzwerk. In Zukunft soll es möglich sein, für diese Kommunikation zwischen Modulen verschiedene Strategien, bzw. Implementierungen anzubieten.