Business Object Exchange: Unterschied zwischen den Versionen
(Einleitung beendet) |
(Einführung verschiedener Typen / Klassen von BO) |
||
| Zeile 9: | Zeile 9: | ||
Um die lose Struktur innerhalb von VcA zu berücksichtigen, sollte auf dieser Kommunikationsebene [[ChoreographyOrchestration|Choreography anstelle von Orchestration]] als Form der Organisation eingesetzt werden.<ref name="nikaj2016rest" /><ref name="nikaj2016restChoreo" /> 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. | Um die lose Struktur innerhalb von VcA zu berücksichtigen, sollte auf dieser Kommunikationsebene [[ChoreographyOrchestration|Choreography anstelle von Orchestration]] als Form der Organisation eingesetzt werden.<ref name="nikaj2016rest" /><ref name="nikaj2016restChoreo" /> 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 | 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 [[:Datei:User-drops-waves.png|Abbildung 1]]). | ||
=== Selektion der Daten === | |||
[[Datei:Bo-types.png|mini|Typisierung der Business Objects im Kontext des RESTful Webservices.]] | |||
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 [[:Datei:User-drops-waves.png|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 Pool<sup>2</sup>. 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 Pool<sup>2</sup> wird mittels des [[Shared_Session|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''. | |||
== Referenzen == | == Referenzen == | ||
Version vom 27. April 2017, 08:10 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.
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.
