Wiederverwendung – das Anti-Pattern am „Edge“

Gerne nutzt man etwas, was man bereits hat mehrfach. So haben wir bei unseren Entwicklungen auch einen Versuch aufgebaut, bei dem der Füllstand eines Speichers (State of Charge) mittels einer DID referenziert wird. Dieser Prozentwert ändert sich alle Minuten, je nachdem ob und wie viel verbraucht wird und ob und wie viel geladen werden kann. Obwohl wir alle Bedingungen aus den beiden vorhergehenden Kapiteln beachtet hatten, wollte dieser Versuch nicht stabil laufen.

Die Ursachenforschung ergab, dass wir im Falle der Ladung des Autos von Alice immer neue DIDs angelegt hatten, allerdings hatten wir für den Endzählerstand den Datensatz auf Seite des Stromzählers immer wieder aktualisiert, bis dieser letztendlich zum Endzählerstand wurde (Ende des Ladevorgangs). Im Wirkbetrieb hätte dies uns das Genick gebrochen, wenn wir den Versuchsaufbau mit dem Speicherfüllstand nicht gemacht hätten.

Was ist genau schiefgelaufen? Alle Überprüfungen auf Gültigkeit eines Datensatzes funktionieren, selbst wenn eigentlich ein neuer Datensatz genutzt werden soll, denn eine echte Versionierung existiert nicht. Im Klartext, jeglicher Programmcode auf Seiten von Alice kann mit veralteten Werten arbeiten, ohne dies mitzubekommen. Zur Lösung dieser Herausforderung existieren mehrere Strategieen.

Die erste Strategie ist, den jeweils nächsten DID bereits als leeren DID (ohne Daten dahinter) anzulegen und zum Bestandteil des aktuellen DIDs zu machen. Der Algorithmus könnte nun lauten: Sobald ein DID aufgelöst werden kann (der Neue), ist der Vorhergehende nicht mehr gültig. Die Herausforderung ist, dass bei diesem Vorgehen theoretisch wieder ein endloses „Warten“ im Code entstehen kann, wenn in der Kommunikation es zu einer Unterbrechung kommt.

Die zweite Strategie erweitert die Erste um einen Zeitpunkt, an der spätestens das nächste DID mit Daten verfügbar sein muss. Trifft dieser Zeitpunkt ein und das nächste DID ist nicht verfügbar, so kann das weitere Warten beendet werden. Auch diese Strategie muss noch verbessert werden, da sie bedeutet, dass auf Seite von Alice selbständig über das Ende der Ladung „entschieden“ wird und ein Konsens mit dem Stromzähler nicht abgestimmt ist. Blöd, wenn der Stromzähler lückenlos die Ladevorgänge protokollieren soll.

Die eleganteste Lösung ist jedoch, dass man für die Kommunikation zwischen zwei Parteien einem Protokoll folgt, welches eine klare Trennung zwischen Kontrollnachrichten und Nutzdaten vorsieht. In der Energiewirtschaft wird, wie bereits erwähnt, nach dem EDIFact Standard die Nutzdaten in der sogenannten Marktkommunikation ausgetauscht. Zusätzlich zu den Nutzdaten schreibt EDIFact allerdings auch Servicenachrichten vor, die sogenannten APERAK und CONTRL Nachrichten. Mit Hilfe dieser Herangehensweise kann man auch in unserem Projekt ID-Ideal das Versionenproblem lösen, weshalb unser Wallet-Service auch CONTRL und APERAK kennt.

Abstraktionsebenen, der Hochflug vor dem Tiefflug

Bei unserem Vorhaben in ID-Ideal nutzen wir nicht nur viel Open-Source Entwicklungen, um darauf aufzubauen, wir haben auch bislang mehrere tausend Zeilen Code veröffentlicht. Der ganz große Vorteil für uns ist, dass wir nicht nur unsere Fragen beantwortet bekommen, sondern auch direkt Fragen an uns gestellt werden, die helfen, die Implementierung auf Anforderungen abzustimmmen. Die Herausforderung, die in der Koordination entsteht, ist dass jeder eine andere Flughöhe bei dem Blick auf den Code und die Nutzung hat.

Konkretes Beispiel ist die Übertragung des Zählerstandes an Alice. Auf der untersten Ebene gibt es ein physikalisches Medium (Kabel, Luft, …), dann das erste Protokoll (zum Beispiel TCP/IP) usw… . Jede Ebene legt dabei Spielregeln fest und jede Ebene hat bestimmte „Service Levels“, auf die man sich verlassen kann. So wird bei TCP (aus TCP/IP) die Reihenfolge der einzelnen Datenpakete garantiert, sowie deren tatsächliche Übermittlung bis zur Gegenstelle. UDP, das Schwesterprotokoll von TCP, kennt keine Übermittlungsbestätigung. IP, das Protokoll unter TCP und UDP kennt keine Reihenfolgengarantie.

Meistens kann einem die Service-Levels von Protokollen ziemlich egal sein. Aber, sobald man weiter nach „oben“ steigt, wird es diffiziler und die Herausforderungen am „Edge“ sind auf den eher unteren Ebenen. In einem Rechenzentrum gibt es kaum Verbindungsabbrüche, keine schwankende Mobilfunkanbindung und auch kaum ein doppelt empfangenes Signal. Im Projektalltag klammert man diese Herausforderungen aus, stolpert allerdings blind-links auf höheren Ebenen in eine Falle, die es bei jedem Projekt gibt. Nur weil ein bestimmtes Protokoll auf einer Ebene zum Einsatz kommt, bedeutet es noch lange nicht, dass zwei Systeme miteinander Daten austauschen können. Wenn der Zähler morsen kann und Alice auch, so bedeutet dies noch lange nicht, dass sie hinsichtlich der Abrechnung von Ladevorgängen kompatibel zueinander sind.

Protokolle sind eigene Sprachen, die eine Regel besitzen, wie etwas zu etwas anderem steht. Jedes Protokoll definiert einen Payload (Nutzlast), was die eigentlich zu übermittelnde Information beinhaltet. Bei TCP zum Beispiel die „Nummer“ (in der Reihenfolge) des Paketes, die Nutzlast sind die Daten, die gesendet werden. Jede Ebene hat ihr Protokoll. Es kann mehre Ebenen geben, die ähnliche Dinge erledigen, aber auf der obersten Ebene (der „Anwendung“) gibt es nur noch ein Protokoll, mit Nutzlast, was sich dann Geschäftsprozess nennt (vergl. OSI Schichtenmodell).

Wir hatten uns gefragt, wo und wie wir die Daten verschlüsseln? Jede Ebene in der Kommunikation zwischen Alice und dem Stromzähler bietet die Möglichkeit, doch man erkauft sich hierbei Abhängigkeiten, wenn der Payload (Nutzlast) zum Konsens gegenüber Dritten benötigt wird, denn entweder muss man dann entschlüsseln und erneut verschlüsseln, oder ein Verfahren zum Schlüsselmanagement auf dieser Ebene implementieren. Nach vielen Irrungen und auch etlichen Zeilen Code, die verworfen wurden, sind wir nun auf der obersten Ebene angelangt. In der Open-Source-Community ist dies von unschlagbarem Vorteil, da wir kleine Code-Schnipsel (Snippets) einfach zeigen können, um ein Problem zu beschreiben.

Die Sache mit dem Ebenen und Protokollen hat in unserer Erfahrungen bei „Edge“ Entwicklungen noch viel größere Auswirkungen bei der Behandlung von Ausnahmen (Exceptions). Kritische Situationen, die abgefangen und behandelt werden soll. Mit einem einfachen Weiterwurf nach „Oben“ kommt man heute meist gut zurecht, aber bei den „Edge“ Kommunikationen kommt es auf allen Ebenen um etwa 100 bis 1000 mal häufiger zu Schwierigkeiten. Wiederholen, weil eine Verbindung unterbrochen wurd – führt zum Endloswarten, wenn physikalisch die Verbindung überhaupt nicht mehr existiert (zum Beispiel, weil Alice zu weit von der Wifi Schnittstelle des Zählers entfernt ist). Kommt dies oft vor, so werden diese Prozess „für immer“ warten und auf das Ergebnis aufbauende Transaktionen „in der Schwebe“ bleiben. Bislang haben wir hierfür noch nicht wirklich ein gutes „Pattern“ oder Strategie gefunden, bei der man wirklich nichts übersieht.

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Inhalt nicht verfügbar.
Bitte erlauben Sie Cookies, indem Sie auf Übernehmen Sie auf das Banner