Vorbemerkungen:

Das gesamte openWIM-System ist (möglichst) darauf ausgerichtet, nach den "Promise"- und fallweise dem "Connection"-Prinzip zu interagieren. Dieses gilt innerhalb von openWIM -"Instanzen" wie dem Server, dem Service-Worker sowie dem Browser. 

Die eben genannten Instanzen interagieren untereinander über den Austausch von "Messages", die einem einheitlichen Grund-Standard folgen (müssen). Die Grundprinzipien der "Promise"- und "Connection"-Verfahren werden im Austausch der Messages abgebildet.

Zum "Promise"-Verfahren:

Beim Promise-Verfahren wird eine Funktion aufgerufen, die kein sofortiges inhaltliches Ergebnis zurückliefert, sondern (intern) lediglich das "Versprechen" (= "promise"), das Ergebnis zu liefern, sobald es verfügbar ist. Die Verarbeitung innerhalb der aufgerufenen Funktion ist gegen irreguläre Ereignisse (Abstürze etc.) "abgesichert", die im Fall des Falles mit einen alternativen "catch"-Aufruf aufgefangen werden können.

Der Aufruf einer mit "Promise" arbeitenden Funktion kann beispielsweise wie folgt aussehen:

aufrufbareFunktion( Parameter1, Parameter2 /* etc. */ )
.then( ( Ergebniswerte ) => { /* Verarbeitungscode für das gelieferte Ergebnis */ } )
.catch( ( Err ) => { /* Verarbeitungscode für den gemeldeten Ausnahmefall */ } )
.finally( ( Arg ) => { /* optional; falls nach then oder catch noch was zu tun ist */ } );

Eine aufgerufene Funktion sieht im Prinzip wie folgt aus:

function aufrufbareFunktion( Parameter1, Parameter2 ){
  return new Promise( ( Resolve, Reject ) => {
    /* Hier steht der Ausführungscode der Funktion */
    /* mittels */ Resolve( responseParams ); /* wird das Ergebnis an den Aufrufer übergeben */
    /* mittels */ Reject( errorHints ); /* wird ein unvorgesehener Abbruch zurückgemeldet */
    } ) }

Anmerkung: Dieses ist nur eine stark vereinfachte Darstellung des Verfahrens, die nur diejenige Funktionalität hervorhebt, die im hier zu beschreibenden Kontext besonders relevant ist.

Zum "Connection"-Verfahren:

Für einige Verarbeitungsformen reicht der Promise-Mechanismus nicht aus, denn er erlaubt zu jedem Funktionsaufruf immer nur exakt eine einzige Reaktion (entweder "then" oder "catch") möglich. Für beispielsweise die "Abonnements" von Obj-Daten oder Umfeld-Parametern, die sich im Laufe der Bearbeitung ändern können und dann immer wieder in aktualisierter Form gemeldet werden sollen, sind wiederholte "Rückrufe" (Callbacks) notwendig.

Der Aufruf einer "Connection"-Funktion kann beispielsweise wie folgt aussehen:

startConnectionFunktion( Parameter1, Parameter2,
  ( Ergebniswerte ) => { /* Verarbeitungscode für die gelieferten Ergebnisse */ },
  ( Err ) => { /* Verarbeitungscode für den gemeldeten Ausnahme (=Abbruch)-Fall */ } );

Die Anforderungs-Parameterwerte für die Connection-Funktion können während seiner Laufzeit geändert werden. Dazu werden die geänderten Parameterwerte in einem "Promise"-Verfahren übermittelt:

modifyConnectionFunktion( ServiceId, Parameter1, Parameter2 )
.then( ( Feedbackwerte ) => { /* Verarbeitungscode für das gelieferte Feedback */ } )
.catch( ( Err ) => { /* Verarbeitungscode für den gemeldeten Ausnahmefall */ } );

Umsetzung der obigen Verfahren für die Kommunikation zwischen Instanzen der openWIM

Kommunikation mittels "Messages":

Weil aus technischen Gründen kein unmittelbarer Aufruf von Funktionen über Instanzen hinweg möglich ist, werden "Messages" für den Austausch der Daten zwischen diesen Instanzen eingesetzt. Dabei ist zu bedenken, dass nach dem "Versand" einer Message eine unbestimmte Zeit vergehen kann, bevor die Message beim Adressaten eintrifft, dort bearbeitet wird und dann die zurückgesandte Antwort bei der initiierenden Instanz eintrifft. Auch ist es leider möglich, dass mindestens einer der Übertragungswege kurzzeitig bis sehr lange unterbrochen wird und damit innerhalb einer Frist keine Antwort zurückgemeldet wird. Die Aktivität einer beauftragenden Instanz darf daher während der Wartezeit auf die Rückmeldung nicht gestoppt werden.

Eine Message wird als JSON-Datensatz übermittelt. Eine "Message" wird dabei innerhalb des Programms durch ein JavaScript-Objekt dargestellt. Die Eigenschaften dieses Objektes stellen die Parameterwerte dar. Die Eigenschaft ohne Namen enthält dabei die Bezeichnung für den Typ der Message ( message= { "": "messageTyp", Param1:"WERT", /* usw. */ }; ). Art und Anzahl der der Parameter (/Objekt-Eigenschaften) hängen vom Typ der Message ab.

Da es auch bei der Übertragung der Messages oder ihrer Verarbeitung zu unvorhergesehenen Ereignissen kommen kann, kommenVerfahren, die sich an das Promise-Verfahren anlehnen, zum Einsatz. Bei Messages, die von einer Service-Instanz an eine Client-Instanz (zurück- ?)gesendet werden, wird zur Vereinfachung daher derzeit eine "Klasse" einer Message definiert. Der CLASS-Parameter einer Message enthält ein entsprechendes Schlüsselwort wie beispielsweise "RESPONSE" oder "RE JEC TION".

Kommunikation mittels "Messages":

Die Typbezeichnungen der Messages sollen einem definierten System folgen. Das ist sinnvoll, damit bei Störungen von den Übertragungsfunktionen in Vertretung der nicht erreichbaren Service-Instanz Meldungen innerhalb der Client-Instanz generiert und verarbeitet werden können. Gleiches gilt für die umgekehrte Richtung - also der hilfsweisen Erzeugung (und Verarbeitung) von Client-Messages innerhalb der Service-Instanz.

Eine Anforderung eines Clients namens "xxXxxx" an einen Service wird immer entweder mit einer Message namens  xxXxxxResolved oder mit xxXxxRejected xxXxxxResponse beantwortet.

• Dabei werden mit der xxXxxxResolved-Message alle im Prinzip vorgesehenen Antworten (sowohl die Erfüllung der Anforderung als auch die Nichterfüllung der Anforderung möglichst einschließlich Hinweis auf den Grund /Anlass der Nichterfüllung) vermeldet.
   
• Eine xxXxxxRejected-Message wird im Client-Bereich generiert, wenn eine nicht vorhergesehene Situation aufgetreten ist, die nicht in eine reguläre Situation umgewandelt werden konnte, zum Abbruch der regulären Verarbeitung geführt hat. Die Bearbeitung der Anforderung ist damit beendet. Auch bei einer Connection ist diese ebenfalls als beendet /abgebrochen anzusehen.
   
• Wenn ein Request aus irgendeinem Grund  zurückgewiesen oder nicht erfolgreich bearbeitet werden kann, sollte in der Antwort-Message ein ERR-Parameter enthalten sein. Der Parameter sollte einen Record enthalten dessen Typbezeichnung die Ursache des Problems bezeichnet. Weitere Parameter zur Fehlerbeschreibung oder -Analyse können enthalten sein. Auch kann wiederum ein ERR-Parameter enthalten sein, der ein auslösendes Problem einer aufgerufenen Funktion beschreibt. Beispiel: message= { "":xxXxxxRejected", ERR:{ "":"istGescheitert", ID:"me", ERR:{ "":"crashed" }, /* ... */ }, /* ... */ }

Wenn eine Service-Instanz einen Service-Prozess beendet hat (Auftrag abschließend bearbeitet, wegen Störung abgebrochen, etc.) wird die Message an den Client mit ein Terminated=true -Parameterwert ergänzt.

Mit einer xxXxxxEnd -Message fordert ein Client bei einem Service die Beendigung einer Connection an und erwartet eine xxXxxxTerminated-Antwort. Wenn beispielsweise der Kontakt zu einem Client zu lange unterbrochen ist, wird service-intern eine xxXxxxAbort -Message generiert und verarbeitet. Hier erfolgt keine Quittierung durch eine xxXxxxTerminated-Message.

Über die Dauer einer funktionierenden Connection können Messages verschiedenen spezifischen Typs ausgetauscht werden. Auch hier folgt die Namensgebung (also die Typbezeichnung der Messages) den vorstehenden Regeln.