Business Object Exchange: Unterschied zwischen den Versionen
(Beginne Beschreibung Lebenszyklen) |
K (timestamp) |
||
| Zeile 62: | Zeile 62: | ||
Während das Attribut <code>sender</code> den Microservice identifiziert, der das jeweilige Objekt hält, beschreibt <code>action</code> die verändernde Operation. <code>action</code> kann dabei drei verschiedene Werte annehmen: | Während das Attribut <code>sender</code> den Microservice identifiziert, der das jeweilige Objekt hält, beschreibt <code>action</code> die verändernde Operation. <code>action</code> kann dabei drei verschiedene Werte annehmen: | ||
<code>delete</code>, <code>update</code> oder <code>deactivated</code>. Im Unterschied zu <code>deactivated</code> beschreibt <code>delete</code> die vollständige Entfernung des Objekts aus dem Datenbestand. Es kann somit nie wieder abgerufen werden. <code>deactivated</code> hingegen ist ein Objekt dann, wenn es noch in der Datenbank gehalten wird, aber nicht mehr aktiv verwendet werden soll. Beispielsweise könnte ein Supporter <code>deactivated</code> sein, nachdem der Nutzer seinen Account gelöscht hat. Dies hat den Vorteil, dass der Supporter im Kontext vergangener Interaktion noch repräsentiert werden kann (etwa als verantwortlicher Ansprechpartner zu einer Aktion). Das Attribut <code>object</code> identifiziert das betroffene Objekt eindeutig mittels einer UUID. <code>type</code> unterstützt die Kontextualisierung des Objekts und beschreibt den Typ (die Klasse) des Objekts. | <code>delete</code>, <code>update</code> oder <code>deactivated</code>. Im Unterschied zu <code>deactivated</code> beschreibt <code>delete</code> die vollständige Entfernung des Objekts aus dem Datenbestand. Es kann somit nie wieder abgerufen werden. <code>deactivated</code> hingegen ist ein Objekt dann, wenn es noch in der Datenbank gehalten wird, aber nicht mehr aktiv verwendet werden soll. Beispielsweise könnte ein Supporter <code>deactivated</code> sein, nachdem der Nutzer seinen Account gelöscht hat. Dies hat den Vorteil, dass der Supporter im Kontext vergangener Interaktion noch repräsentiert werden kann (etwa als verantwortlicher Ansprechpartner zu einer Aktion). Das Attribut <code>object</code> identifiziert das betroffene Objekt eindeutig mittels einer UUID. <code>type</code> unterstützt die Kontextualisierung des Objekts und beschreibt den Typ (die Klasse) des Objekts. Der mitgelieferte <code>timestamp</code> gibt Auskunft darüber, wann die Operation ausgeführt wurde und wird als Unix Timestamp (fortlaufender ganzzahliger Wert) abgebildet. | ||
'''TODO: Müssen andere Services über Änderungen / Löschungen informiert werden (Kaskadierung von Änderungen via PULL / PUSH / Webservice Mechanismen)?''' | '''TODO: Müssen andere Services über Änderungen / Löschungen informiert werden (Kaskadierung von Änderungen via PULL / PUSH / Webservice Mechanismen)?''' | ||
Version vom 28. April 2017, 10:35 Uhr
Business Object Exchange
Ein Microservice übernimmt die Verantwortung für (mehrere) Business Objects (BO). Diese müssen gegebenenfalls an andere Microservices weitergegeben werden, da die Services zusätzliche Informationen zur Durchführung der bereitgestellten Operationen benötigen. Das vorliegende Konzept beschreibt den Austausch der BOs basierend auf RESTful Webservices, welche häufig in Microservice Architekturen verwendet werden.[1] REST bildet die HTTP Verben auf Basisoperationen des CRUD-Prinzips (Create, Read, Update and Delete) ab. Somit wird für die Erstellung von Instanzen einer Entität POST verwendet, für das Abrufen GET, die Aktualisierung ist durch PUT gekennzeichnet (ebenso die gleichzeitige Erstellung mehrerer Instanzen) und der Löschvorgang wird mittels DELETE eingeleitet.[2]
RESTful Webservices werden durch wenige Haupteigenschaften charakterisiert. Erstens sind sie zustandslos: Requests enthalten alle nötigen Informationen, um die Anfrage zu beantworten und Responses können Links auf andere Ressourcen beschreiben. Zudem können die Responses auf eine Anfrage gecached werden. Zweitens nutzen Webservices URIs mit dem Aufbau einer Verzeichnisstruktur: Eine Hierarchie von (Sub)Pfaden erweitert einen primären Wurzelknoten und Query Strings sollten vermieden werden. Außerdem werden die Daten in einem vom Menschen lesbaren Format beschrieben, wie etwa XML, JSON oder beides parallel.[2]
Um die lose Struktur innerhalb von VcA zu berücksichtigen, sollte auf dieser Kommunikationsebene Choreography anstelle von Orchestration als Form der Organisation eingesetzt werden.[3][4] Auf diese Weise benötigt die Kommunikation zwischen zwei Services auch nur die beiden Services und einen Kommunikationskanal zwischen diesen. Somit kann ein Netzwerk von Microservices entstehen, in dem die einzelnen Services nur abhängig von den Services sind, mit denen sie auch kommunizieren müssen.
Der Microservice Waves erlaubt die Verwaltung von Aktionen. Um eine Aktion anzulegen muss ein Ansprechpartner (ASP) hinterlegt werden können. Ansprechpartner ist in diesem Kontext eine Rolle, die ein Nutzer im System einnehmen kann. Nutzer werden jedoch im Drops-System verwaltet und persistiert. Waves kann die durch die Nutzer repräsentierten Supporter für diesen Zweck von Drops abfragen und nutzt dafür RESTful Webservices (siehe Abbildung 1).
Selektion der Daten
Eine Herausforderung für den Entwickler eines Microservices besteht darin zu entscheiden welche Daten für die Übertragung bereitgestellt werden sollen. Dafür lassen sich die BOs anhand der Grafik aus Abbildung 2 klassifizieren. Grundsätzlich sind die BOs in zwei Kategorien zu trennen: Erstens gibt es die Owned BO, also BO die durch den Microservice selbst gehalten und verwaltet werden und zweitens die Pulled BO, also BOs die von anderen Microservices bezogen werden. Hier interessiert uns nur die erste Kategorie. Diese lässt sich ebenfalls in die Kategorien der Pushed BO und der Internal BO aufteilen. Während die Pushed BO eben genau die BOs umfasst, die an andere Microservices weitergegeben werden sollen, dienen Internal BO alleine der Verarbeitung durch den vorliegenden Microservice und werden nicht weitergegeben.
Als Beispiel soll an dieser Stelle der Nutzer des Systems dienen. Die Verwaltung der Nutzer obliegt dem Drops Microservice. Der Nutzer selbst ist dabei kein BO, sondern ein Objekt der Software Pool2. Der durch den Nutzer repräsentierte Supporter ist hingegen ein BO. Inwiefern unterscheiden sich Supporter und Nutzer des Systems? Ein Nutzer umfasst stets einen Supporter, bildet aber zusätzlich die Möglichkeit zur Authentifizierung mittels eines zusätzlichen Passworts. Zur Identifikation des Nutzers wird die Email-Adresse verwendet, die auch den Supporter eindeutig identifiziert. Somit ist der Supporter ein Owned BO, während der Nutzer gar kein BO ist (Authentifizierung der Nutzer innerhalb des Pool2 wird mittels des Shared Session Konzepts realisiert). Ob der Supporter als Pushed BO oder Internal BO vom Drops-Entwickler betrachtet werden sollte hängt davon ab, ob der Supporter auch für andere Microservices relevant sein könnte. Da dies in Fall des Supporters gegeben ist, handelt es sich bei einem Supporter um ein Pushed BO.
Zu beachten ist der Sonderfall, dass zusätzliche Informationen zu einem Pulled BO in einem Service erzeugt und verarbeitet werden. Es stellt sich natürlich die Frage, ob derartige Erweiterungen der BOs auch nach außen transparent zur Verfügung gestellt werden sollen. Hier greift die später beschriebene #Eskalationsrichtlinie, nach der ein BO im Netzwerk nur vollständig aus einer Quelle bezogen werden kann. Somit werden solche Erweiterungen im einfachen Fall nicht nach außen bereitgestellt und werden somit als Internal BO betrachtet. Diese Überlegung wird in Abbildung 3 visualisiert.
Eskalationsrichtlinie
Wie bereits im Abschnitt #Selektion der Daten beschrieben, müssen Regeln für die Veränderung von Pushed BOs (und Pulled BOs) festgesetzt werden. Die folgende Tabelle soll für die verschiedenen Fälle das jeweilige Vorgehen und jeweils eine Begründung dazu liefern:
Legende: Haltender MS beschreibt den Microservice, der das BO für andere Microservices bereitstellt. Beziehender MS meint den Microservice, der das BO über die RESTful Schnittstelle abfragt.
| Fall | Regel | Begründung |
|---|---|---|
| Ein Pushed BO wird erweitert | Erweiterung kann vorgenommen werden und steht unter einer neuen Versionsnummer zur Verfügung. Vorherige Beschreibung der Daten bleibt unter einer vorherigen Versionsnummer verfügbar. | Konflikte im Umgang mit den empfangenen Daten sollen möglichst vermieden werden. Hierfür ist es sinnvoll den Entwicklern der Microservices selbst die Verantwortung für die Robustheit ihres Systems zu übergeben, was durch die Verfügbarkeit der verschiedenen Versionen der Datenformate ermöglicht wird. |
| Eigenschaften eines Pushed BO werden verändert (beispielsweise der Typ) | Veränderung kann vorgenommen werden und steht unter einer neuen Versionsnummer zur Verfügung. Vorherige Beschreibung der Daten bleibt unter einer vorherigen Versionsnummer verfügbar. | Konflikte im Umgang mit den empfangenen Daten sollen möglichst vermieden werden. Hierfür ist es sinnvoll den Entwicklern der Microservices selbst die Verantwortung für die Robustheit ihres Systems zu übergeben, was durch die Verfügbarkeit der verschiedenen Versionen der Datenformate ermöglicht wird. |
| Eigenschaften eines Pushed BO werden entfernt | Entfernung kann vorgenommen werden und steht unter einer neuen Versionsnummer zur Verfügung. Vorherige Beschreibung der Daten bleibt unter einer vorherigen Versionsnummer verfügbar. | Konflikte im Umgang mit den empfangenen Daten sollen möglichst vermieden werden. Hierfür ist es sinnvoll den Entwicklern der Microservices selbst die Verantwortung für die Robustheit ihres Systems zu übergeben, was durch die Verfügbarkeit der verschiedenen Versionen der Datenformate ermöglicht wird. |
| Ein Pulled BO wird erweitert | Initiierung eines Abstimmungsvorgangs mit anderen Microservice Entwicklern. Wird diese Erweiterung auch durch andere Services benötigt oder abgebildet? Falls ja: Als Anforderung an den haltenden MS. Falls nein: Abbildung als Internal BO im beziehenden MS. | Kommunikation auf technischer Ebene soll möglichst einfach und überschaubar bleiben. Daher sollen BO nicht auf verschiedene Microservices verteilt werden. |
| Eigenschaften eines Pulled BO müssen verändert werden (beispielsweise der Typ) | Initiierung eines Abstimmungsvorgangs mit anderen Microservice Entwicklern. Wird die Veränderung durch alle Entwickler-Teams befürwortet: Anforderung an den haltenden MS. Falls die Veränderung nur durch den beziehenden MS benötigt wird, sollte dort eine Lösung gefunden werden (bspw. Typkonvertierung). Wenn nur ein Teil der Entwickler-Teams die Veränderung befürwortet, muss eine Lösung auf Seiten des haltenden MS gefunden werden, welche alle Varianten über die verschiedenen Versionen hinweg bereitstellt. | Auf diese Weise kann sichergestellt werden, dass jede benötigte Form der BOs bezogen werden kann, ohne dadurch einige Microservices auf den Zugriff auf alte Versionen zu beschränken (und damit von zukünftigen Entwicklungen auszuschließen). |
| Eigenschaften eines Pulled BO werden nicht benötigt | Siehe Lösung zuvor (Eigenschaften eines Pulled BO müssen verändert werden) | Siehe Begründung zuvor (Eigenschaften eines Pulled BO müssen verändert werden) |
Lebenszyklen - Business Object Event System
Verändern sich die gehaltenen Daten in Microservices, müssen andere Microservices gegebenenfalls darauf reagieren können. Beispielsweise werden in Waves zu jeder Aktion verantwortliche Supporter assoziiert. Löscht oder deaktiviert ein solcher Supporter nun aber den eigenen Account, ist es sinnvoll, wenn Waves dies registrieren kann, den Nutzer aus der Assoziation entfernt und eventuell andere Nutzer über diesen Vorgang informiert.
Damit ein Microservice die Anderen über Veränderungen seines Datenbestands informieren kann, führen wir eine zusätzliche Kommunikationsebene ein. Dieses Kommunikationssystem zwischen den Microservice wird Business Object Event System (BOES) genannt und basiert auf dem bestehenden Kommunikationsnetzwerk zwischen den Microservices. Das BOES implementiert einen Nachrichtenaustausch nach dem PUSH-Prinzip. Das bedeutet, dass ein Microservice nach einer Änderung an einem BO allen anderen Microservices, die mit ihm aufgrund Business Object Exchange verbunden sind, eine Nachricht schickt. Diese Nachricht umfasst dabei die Information wann welches Objekt verändert wurde und welche Art der Veränderung vorgenommen wurde (löschen oder ändern). Beziehende Microservices können anschließend das Objekt neu beziehen (bei Veränderung) oder alle Referenzierungen auf das Objekt entfernen. Auch hier wird die Verantwortung den Entwicklern des jeweiligen Microservices überlassen, um eine möglichst freie Gestaltung des Umgangs mit derartigen Ereignissen zu erlauben.
Die Nachrichten haben daher folgendes Format:
{
"sender": "microservice-uuid",
"action": "action-id",
"object": "object-uuid",
"type": "object-type",
"timestamp": 123456789
}
Während das Attribut sender den Microservice identifiziert, der das jeweilige Objekt hält, beschreibt action die verändernde Operation. action kann dabei drei verschiedene Werte annehmen:
delete, update oder deactivated. Im Unterschied zu deactivated beschreibt delete die vollständige Entfernung des Objekts aus dem Datenbestand. Es kann somit nie wieder abgerufen werden. deactivated hingegen ist ein Objekt dann, wenn es noch in der Datenbank gehalten wird, aber nicht mehr aktiv verwendet werden soll. Beispielsweise könnte ein Supporter deactivated sein, nachdem der Nutzer seinen Account gelöscht hat. Dies hat den Vorteil, dass der Supporter im Kontext vergangener Interaktion noch repräsentiert werden kann (etwa als verantwortlicher Ansprechpartner zu einer Aktion). Das Attribut object identifiziert das betroffene Objekt eindeutig mittels einer UUID. type unterstützt die Kontextualisierung des Objekts und beschreibt den Typ (die Klasse) des Objekts. Der mitgelieferte timestamp gibt Auskunft darüber, wann die Operation ausgeführt wurde und wird als Unix Timestamp (fortlaufender ganzzahliger Wert) abgebildet.
TODO: Müssen andere Services über Änderungen / Löschungen informiert werden (Kaskadierung von Änderungen via PULL / PUSH / Webservice Mechanismen)?
Sicherheit
TODO: Siehe Konzept zur Intra-Microserves authentication
Referenzen
- ↑ N. Dragoni et al., “Microservices: yesterday, today, and tomorrow.” Cornell University, 2017.
- ↑ 2,0 2,1 A. Rodriguez, “RESTful Web services: The basics,” 2008. [Online]. Available: https://www.ibm.com/developerworks/library/ws-restful/. [Accessed: 17-Mar-2017].
- ↑ A. Nikaj and M. Weske, “Formal Specification of RESTful Choreography Properties,” in Web Engineering. ICWE 2016. Lecture Notes in Computer Science, 2016, pp. 365–372.
- ↑ A. Nikaj, S. Mandal, C. Pautasso, and M. Weske, “From Choreography Diagrams to RESTful Interactions,” in Service-Oriented Computing – ICSOC 2015 Workshops. ICSOC 2015. Lecture Notes in Computer Science, vol 9586, 2016, pp. 3–14.
