Business Object Exchange
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
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:
| 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) | TODO | TODO |
| Eigenschaften eines Pushed BO werden entfernt | TODO | TODO |
| Ein Pulled BO wird erweitert | TODO | TODO |
| Eigenschaften eines Pulled BO müssen verändert werden (beispielsweise der Typ) | TODO | TODO |
| Eigenschaften eines Pulled BO werden nicht benötigt | TODO | TODO |
Lebenszyklen
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.
