Was sind die wichtigsten Vorgaben für die Requestbearbeitung auf den Servern?

1. Es darf kein Request "verloren gehen":
   • Alle Requests müssen angenommen und bearbeitet werden.
   • Wenn die "ordentliche" Bearbeitung - aus welchem Grunde auch immer - scheitert, muss dennoch eine "ordentliche" Reaktion erfolgen. So gut es eben geht.
2. Eingetroffene "asynchrone" und "synchrone" Requests werden möglichst gleich behandelt:
   • Bei der Rückgabe der Ergebnisse wird vom Requesthandler nicht unterschieden, ob der Request synchron oder asynchron eingetroffen ist. Erst die Mimik, die den Requesthandler aufgerufen hat, wickelt die Requests unterschiedlich ab.
3. Gestartete "asynchrone" werden IMMER erst in einer Warteschlange abgelegt:
   • Dabei wird unterschieden, ob es sich um "interne" Requests (auf dem gleichen Server abzuarbeiten) oder "externe" Requests handelt. Letztere werden erst abgeschickt, wenn alle internen Requests abgearbeitet wurden und das Ergebnis zum (externen) Aufrufer zurückgemeldet wurde.
4. Server-interne Requests werden vorrangig abgearbeitet:
   • Erst wenn alle internen Requests (normaler Priorität) abgearbeitet wurden, werden externe Requests abgearbeitet.
5. Die Bearbeitungszeit für Requests ist begrenzt:
   • Aus technischen Gründen kann die zur Requestbearbeitung verfügbare Rechenzeit oder Laufzeit begrenzt sein. Daher werden bei Erreichen einer Begrenzung alle noch unbearbeiteten Requests gespeichert.
6. Gespeicherte Requests werden vorrangig abgearbeitet:
   • Die Reihenfolge der ausgegebeben Requests soll bei der Bearbeitung eingehalten werden (first in - first out -Prinzip). Beim Start der Requestbearbeitung werden alle gespeicherten Requests in den laufenden Prozess geholt und in die aktuellen Warteschlangen übertragen. Es muss dafür gesorgt werden, dass nur ein einziger Prozess die gespeicherten Requests holt und bearbeitet.
7. Bei der Adressierung der Kommunikationspartner wird nach Release und Version unterschieden.
   • Bei neueren System-Versionen können andere Datenformate oder Regeln gelten, die bei älteren Versionen zu Problemen führen können. Der "Übertragungsweg" bzw. das Übertragungsprotokoll (z. B. "http://") wird NICHT in der Adressierung der Requests vermerkt. Dies ist Sache der "technischen Kommunikation" zwischen den Kommunikationspartnern (Servern).
8. ...

Wie ist der grundsätzliche Bearbeitungsablauf für Requests im Server?

Die eintreffenden http(s)-Requests müssen analysiert werden, von welcher Art sie sind. Dann werden sie "artspezifisch" bearbeitet:

1. Falls ein "legales" und formal korrektes WIM-"PACKAGE" (mit WIM-Requests darin) eingetroffen ist:
   • Prüfkriterien:
     • Es muss ein http(s)-"POST" -Request mit Datenangaben eingetroffen sein.
       • Die PACKAGE-Daten können mit CGI-Codierung eintreffen.
         Sie beginnen dann mit z.B. der Zeichenfolge "PACKAGE=%" und enthalten die Angabe des "PACKAGE"-Parameters mit dem cgi-codierten Inhalt des übermittelten PACKAGE. Dieser Inhalt muss decodiert werden und sieht danach aus, wie die Daten eines direkt gesendeten Paketes.
       • Direkt gesendetes PACKAGE. Die eingetroffenen Daten beginnen mit "<PACKAGE ".
       • Bei beiden Übermittlungsarten werden die Daten als Liste von "Bytes" (oder "Octets") und NICHT als UTF-8 codierte Zeichen (Liste von "Ordnungszahlen" mit 1 oder mehr Byte großem Speicher- /Übertragungsbedarf pro Zeichen) transportiert. Daher müssen die eingetroffenen Octets noch in einen ordentlichen UTF-8 -String zurückgewandelt werden, bevor sie weiterverarbeitet werden können.
     • Der Request muss von einem akzeptablen Sender kommen.
       • Backend-Server nehmen nur PACKAGEs von "ihren" Frontend-Servern oder ihren alternativen Backend-Servern an.
       • Frontend-Server nehmen PACKAGEs von den WIM-Apps (der Internetbrowser) ihren Backend-Servern oder anderen Fronted-Servern an. Die anderen Frontend-Server verhalten sich dabei ähnlich wie WIM-Apps.
     • Wenn bei einem PACKAGE fehlende oder unakzeptable Basisangaben oder enthaltene Requests mit unakzeptabler Syntax festgestellt werden, wird es (mit STATUS-Meldung) zurückgewiesen und nicht inhaltlich bearbeitet.
     • Wenn der Server "heruntergefahren" wird oder "außer Betrieb" gesetzt wurde, werden entsprechende Antwort-PACKAGEs generiert und zurückgeschickt.
   • Für ein eingetroffenes "ordentliches" PACKAGE mit Requests:
     1. Falls das PACKAGE einen synchronen Request enthält:
        • Synchrone Requests werden SOFORT abgearbeitet.
        • Weitere WIM-Requests dürfen im PACKAGE nicht enthalten sein, sonst wird es als ganzes zurückgewiesen.
        • Aus den Rückgabewerten der Bearbeitung des synchronen Aufrufs wird ein PACKAGE zur Rückgabe an den Aufrufer für die Rücksendung bereitgestellt.
        • Es erfolgt an dieser Stelle keine Folgebearbeitung etc., nur die unveränderte Ergebnis-Weitergabe.)
        • Bei der Bearbeitung des Requests können interne oder externe asynchrone Requests generiert werden. Diese werden zunächst in den Warteschlangen des Arbeitsspeichers abgelegt und am Ende entweder vom Daemon-Subprozess bearbeitet oder im Hintergrundspeicher abgelegt.
     2. Ansonsten die asynchronen Requests des PACKAGE bearbeiten:
        1. Falls noch unbearbeitete Requests warten, diese zur Bearbeitung vom Hintergrundspeicher in die aktuellen Warteschlangen rüberschieben.
           • WICHTIG: Die Reihenfolge der bearbeiteten Requests kann bei diesem Verfahren nicht gewährleistet werden. Vom Requesthandler ist daher ggf. zu checken, ob der Request z. B. "überholt" ist /wurde. Dieses ist vorzugsweise bei der Änderung von Daten der Fall.
        2. Die eingegangenen Requests werden gemäß der Reihenfolge im PACKAGE zu den aktuellen Warteschlangen (verschiedener Prio) hinzugefügt.
        3. Die Requests aus den Warteschlangen werden nun einer nach dem anderen abgearbeitet:
           • Dabei können neue server-interne und -externe Requests generiert werden. Sie werden in den Queues für die interne oder externe Bearbeitung abgelegt.
           • Anliegende interne Requests werden so lange abgearbeitet, wie kein Abbruchkriterium (Rechenzeit- oder Laufzeit-Begrenzung, ...) eintritt.
           • Von den Requests an andere Server werden nur die (synchronen) CALL-Requests sofort bearbeitet. Der Rest bleibt in den Queues für ihre Zielsysteme und wird erst nach Beendigung des aktuellen http(s) -Requests verschickt, da der Versand zeitaufwändig werden kann und die Bearbeitung des anliegenden PACKAGE unnötig ausbremsen würde.
           • Es wird als http(s)-Antwort ein zurückzumeldendes "PACKAGE" zusammengestellt, dass möglichst alle anstehenden Requests an den Aufrufer enthält.
             • Falls das zurückzuschickende PACKAGE größer zu werden droht, wie vom Empfänger als verkraftbar angegeben, wird nur der erste Teil der zurückzuschickenden Requests in dieses PACKAGE eingetragen. Der Rest wird später in eigenständigen PACKAGEs separat geschickt.
2. Aufrufe von unakzeptabler /unautorisierter Seite und andersartige (nicht-POST) müssen anders bearbeitet (ggf. auch abgeblockt) werden.
   • "GET"-, "HEAD"-, ... Requests enthalten keine WIM-Requests und sind generell anders zu bearbeiten (z.B. Beschaffung der angefragten nicht gefundenen Grafik, ...).
   • Hier unterscheiden sich Frontend- und Backend-Server teileise (siehe =>tbd).
3. Die Antwort auf den http(s)-Request wird ausgegeben.
   • Das kann ein "PACKAGE" aus der WIM-Request-Bearbeitung sein.
   • Das kann der Inhalt einer gesuchten Image-Datei sein (mit dem passenden MIME-Typ !)
   • ...
4. Falls noch abzuarbeitende Requests anliegen und nicht bereits ein (Daemon-) Prozess damit beschäftigt ist, wird ein Subprozess als neuer Daemon-Prozess gestartet.
   1. Zunächst werden alle INTERNEN Requests abgearbeitet:
      • Dabei können sowohl neue interne als auch externe Requests entstehen.
      • Falls ein Abbruch-Kriterium (Rechenzeit-Limit, Sicherheitsbegrenzungen für Laufzeit oder Anzahl der bearbeiteten Requests, ...) erfüllt wird, wird die Bearbeitung der Requests abgebrochen.
   2. Falls die Bearbeitung nicht abgebrochen wurde:
      • Alle wartenden externen Requests werden nacheinander abgeschickt.
        • Dies geschieht Adressat für Adressat mit jeweils einem PACKAGE, dass die zu sendenden Requests enthält.
          • Dabei werden ggf. noch im Hintergrundspeicher wartende Requests an die jeweiligen Adressaten vorangestellt.
        • Würde die maximal akzeptierte PACKAGE-Größe des Empfängers überschritten, werden die Requests auf mehrere PACKAGEs aufgeteilt, die nacheinander abgeschickt werden.
        • Beim Versand der PACKAGEs können Verzögerungen entstehen, weil der Empfänger die erhaltenen Requests erst abarbeiten und dann eine (ggf. leere?tbd?) Antwort auf das PACKAGE schicken.
        • Aus z.B. Sicherheitsgründen kann der Versand abgebrochen werden.
        • Wenn alle Requests an externe Empfänger gemäß internen Queues versandt wurden, werden für einen Empfänger nach dem anderen die noch wartenden Requests aus dem Hintergrundspeicher geholt und versandt.
   3. Alle ggf. noch im Arbeitsspeicher wartenden Requests werden im Hintergrundspeicher abgelegt.
   4. Die "Daemon"-Aktivität /-Blockierung wird beendet.
   5. Falls die Arbeit des Daemon-Prozesses wegen Rechenzeit-Überschreitung abgebrochen wurde, wird ein "Pseudo-PACKAGE" an die eigene Adresse geschickt und dadurch ein neuer Daemon-Prozess getriggert.
   6. Der Ex-Daemon-Prozess wird beendet.
5. Ansonsten werden alle ggf. noch im Arbeitsspeicher wartenden Requests im Hintergrundspeicher abgelegt.
6. Der Prozess wird beendet. Der ggf. erzeugte Daemon-Subprozess läuft weiter.