Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabh\u00e4ngigen vertikalen Modulen aufzubauen. Diese k\u00f6nnen (weitgehend) unabh\u00e4ngig voneinander deployed und betrieben werden und ben\u00f6tigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt \u00fcber leichtgewichtige Protokolle wie etwa REST.<\/p>\n
Dieser Architekturstil erlaubt es, ganze Anwendungslandschaften nach Gesch\u00e4ftsf\u00e4higkeiten zu segmentieren. Die resultierenden Teilfunktionalit\u00e4ten k\u00f6nnen dann in Form von Microservices implementiert und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem H\u00f6chstma\u00df an Unabh\u00e4ngigkeit entwickelt und gewartet werden k\u00f6nnen.<\/p>\n
Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von R\u00e4umen, Praktika, Veranstaltungen, Projekten, Pr\u00fcfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.<\/p>\n
Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gew\u00e4hren, w\u00e4re ein Architektur-Blueprint f\u00fcr Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine gro\u00dfe Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.<\/p>\n
Ziel des Projekts ist es, f\u00fcr die Applikationslandschaft \u201eCampus Gummersbach\u201c einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.<\/p>\n
Dieses Konzept soll am Beispiel der Projektb\u00f6rse Campus GM<\/strong> pilotiert und iterativ-inkrementell erarbeitet werden.<\/p>\n In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierf\u00fcr eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Im SS 18 wurde in einem Guided Project mit der eigentlichen Implementierung der Projektb\u00f6rse begonnen, erste Microservices wurden umgesetzt und n\u00f6tige Infrastruktur geschaffen.<\/p>\n Die Teams des folgenden Guided Projects \u00fcbernehmen die Verantwortung f\u00fcr einzelne (bereits bestehende) Microservices und k\u00fcmmern sich sowohl um Weiterentwicklung\/Betrieb der Services als auch der Entwicklungs- und Ausf\u00fchrungsinfrastruktur. Je nach Bedarf werden neue Microservices entwickelt, Umsysteme eingebunden und die Infrastruktur verfeinert. Die entwickelten Microservices basieren dabei auf dem Spring Boot Framework (Java).<\/p>\n Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu verfeinern, zu validieren und offene Fragen zu identifizieren.<\/p>\n Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die Teams werden hierbei durch wissenschaftliche Mitarbeiter in der Rolle des Scrum Masters betreut. Die agilen Teamprozesse werden gem\u00e4\u00df Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierw\u00f6chige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.<\/p>\n –<\/p>\n","protected":false},"excerpt":{"rendered":" Problembeschreibung Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabh\u00e4ngigen vertikalen Modulen aufzubauen. Diese k\u00f6nnen (weitgehend) unabh\u00e4ngig voneinander deployed und betrieben werden und ben\u00f6tigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt \u00fcber leichtgewichtige Protokolle wie etwa REST. Dieser Architekturstil erlaubt es,… <\/a><\/p>\n","protected":false},"author":39,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[50732],"tags":[9887,21843,50751],"class_list":["post-1770","post","type-post","status-publish","format-standard","hentry","category-eigene-gps","tag-agil","tag-micro-service","tag-prox"],"acf":[],"_links":{"self":[{"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/posts\/1770","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/comments?post=1770"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/posts\/1770\/revisions"}],"predecessor-version":[{"id":1771,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/posts\/1770\/revisions\/1771"}],"wp:attachment":[{"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/media?parent=1770"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/categories?post=1770"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gm.fh-koeln.de\/bente\/wp-json\/wp\/v2\/tags?post=1770"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Projektmethodik<\/h3>\n
Learning Outcomes<\/h3>\n
\n
Voraussetzungen<\/h3>\n
\n
Externe Projektpartner<\/h3>\n