Business Object Exchange: Unterschied zwischen den Versionen
K (Todo) |
(Einleitung beendet) |
||
| Zeile 1: | Zeile 1: | ||
== Business Object Exchange == | == Business Object Exchange == | ||
[[Datei:User-drops-waves.png|mini|RESTful Übertragung eines Nutzers aus Drops nach Waves.]] | |||
RESTful Webservices werden | 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.<ref name="dragoni" /> 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.<ref name="rodriguez" /> | ||
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.<ref name="rodriguez" /> | |||
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, was wiederum bedeutet, dass dieser Nutzer im Drops-System verwaltet und persistiert wird. Waves kann die Nutzer für diesen Zweck von Drops abfragen und nutzt dafür RESTful Webservices (siehe [[:Datei:User-drops-waves.png|Abbildung 1]]). | |||
== Referenzen == | == Referenzen == | ||
Version vom 27. April 2017, 07:33 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, was wiederum bedeutet, dass dieser Nutzer im Drops-System verwaltet und persistiert wird. Waves kann die Nutzer für diesen Zweck von Drops abfragen und nutzt dafür RESTful Webservices (siehe Abbildung 1).
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.
